根据我的理解,在TDD中你必须首先编写一个失败的测试,然后编写代码使其通过,然后重构.但是,如果您的代码已经考虑了您要测试的情况怎么办？
例如,假设我是TDD的排序算法(这只是假设).我可能会为几个案例编写单元测试:
输入= 1,2,3
输出= 1,2,3
输入= 4,1,3,2
输出= 1,2,3,4
等...
为了让测试通过,我最终使用了一个快速的肮脏的泡泡排序.然后我重构并用更有效的合并排序算法替换它.后来,我意识到我们需要它是一个稳定的类型,所以我也为此编写了一个测试.当然,测试永远不会失败,因为merge-sort是一种稳定的排序算法!无论如何,我仍然需要这个测试,因为有人再次重构它以使用不同的,可能不稳定的排序算法.
这是否打破了始终编写失败测试的TDD口头禅？我怀疑有人会建议我浪费时间来实现一个不稳定的排序算法,只是为了测试测试用例,然后重新实现merge-sort.你经常遇到类似的情况,你做了什么？
我在解决方案文件中有许多项目,这些项目都为它们编写了单元测试,我希望将它们设置为由我们的持续集成服务器运行.但是,由于许多测试写得不好而且没有经常运行,因此有许多测试失败了.
我目前没有时间修复所有测试,但我相信现有测试运行是有价值的.处理失败的单元测试的最佳方法是什么？
我目前正在做的是将每个失败的测试标记为Explicit并留下TODO评论.
[Test, Explicit] //TODO: Rewrite this test because it fails
有没有更好的方法呢？或者我应该在将它们包含在CIS运行的测试之前修复所有测试吗？