TDD中一个好的测试要求你去修改代码，从而使它能够按照想要的方式工作，这一点要胜于强迫你去反映现在的真实情况或者一个非逻辑要求的渴望的结果。例如，当1＋1返回0时就意味着测试失败。这个简单的例子和这种情况是相似的，在练习中，如果现在的需求是在工作的，测试应该可以反映你所期待的结果，然后你可以调整现在代码的情况去通过这个测试。
作为一个规则，一个已经调通的测试不应该被移除掉，因为这个测试在维护工作中可以用于恢复测试。他们在你改变代码时用来确定你没有损害到现在已经工作的函数。这就是为什么你不应该修改那些已经通过的测试，除非是一些很小的修改，例如增加它的可读性（换句话说，分解测试）。
当一个测试非正常失败? 有时你可能遇到失败的测试，而这时你对代码的改变是完全合理的。这通常是因为你遇到了冲突的需求。一般来说，可能是一个新的需求（一个改变的特性）与一个旧的可能已经不再有效的需求发生了冲突。这有两种可能：
1.?在旧的需求或者无效或者在别处测试的情况下删除被验证本质上不再有效的失败的测试
2.?改变旧的测试使你可以测试新的要求（本质上使用新的测试），然后在新的设置下（测试的逻辑状态相同，但是初始功能函数可能有所不同）测试旧的需求。
而有时候一个测试在使用不完整的技术去完成任务的时候也是有效的，例如，你有一个成员类带有一个FOO方法，它表现为某几种行为，它已经经由Test在X年前测试完成，然后现在一些其他的需求加了进来，方法的逻辑增强了，从而可以去处理一些类似于在获取数据时丢失一些参数的异常处理。但这时，突然Test X失败了，虽然在测试这个函数的时候只是使用了同样的类。这个测试的失败是因为在调用方法之前丢失了一些初始处理步骤。这并不意味着你需要移除Test X，你将丢失对于一些重要功能的测试，这时你应该去关心那些初始化时的问题，而不是改变类的创建以用来适应你新的意图。
文章来源于领测软件测试网 https://www.ltesting.net/
