这最近让我疯了......
什么是重构？
代码重构是重组现有计算机代码的过程 - 更改分解 - 而不更改其外部行为。
我们如何确保在重构过程中不会破坏任何内容？
在重构一段代码之前，需要一组可靠的自动单元测试。这些测试用于证明在重构之前模块的行为是正确的。
好的。但是，如果我在单元测试中找到代码气味，我该怎么办？说，一个做太多的测试方法？如何在重构单元测试时确保不破坏任何内容？
我需要某种元测试吗？它一直是单元测试吗？
或者单元测试是不是遵循正常的重构规则？
答案 0 :(得分：6)
根据我的经验，有two reasons to trust tests：
这些都是在编写测试时发生的活动。如果你保持测试不可变，你可以继续信任它们。
每次修改测试时，它都会变得不那么值得信赖。
通过重复上述过程，您可以稍微缓解该问题：查看测试的更改，并暂时更改受测系统（SUT），以便您可以看到测试失败按预期。
修改测试时，保持SUT不变。测试和生产代码相互控制，因此改变一个而保持另一个锁定是最安全的。
答案 1 :(得分：6)
尊重这是一篇较旧的帖子，我在帖子中引用了in a comment TDD in practice。所以经过审核，我想投入两分钱。
主要是因为我觉得accepted answer发表了声音：
每次修改测试时，它都会变得不那么值得信赖。
我对 modify 这个词有疑问。关于重构，像更改这样的词，修改等通常会被避免，因为它们会带来与重构相关的含义。
如果您修改 传统意义的测试，则存在引入更改的风险，这使得测试不那么值得信赖。
但是，如果您修改 重构意义中的测试，那么测试应不低于值得信赖。
这让我回到原来的问题：
如何重构单元测试？
非常简单，与任何其他代码一样 - 孤立。
因此，如果您想重构测试，请不要更改代码，只需更改测试。
我是否需要测试我的测试？
不。事实上，Kent Beck在他的Full Stack Radio interview中解决了这个问题：
您的代码是测试的测试
Mark Seemann还在his answer中注意到了这一点：
测试和生产代码互相控制，因此在保持另一个锁定的同时改变一个是最安全的。
最后，这不是关于如何重构测试，而是一般的重构。同样的原则也适用，即重构代码重构而不改变其外部行为。如果你不改变外部行为，那么就不会失去信任。
答案 2 :(得分：3)
如何在重构单元测试时确保不破坏任何内容？
将旧测试作为参考。
详细说明：具有良好覆盖率的单元测试在结果中值得重视。你没有让他们保持惊人的程序结构或缺乏重复;它们本质上是有用的输入/输出对的数据集。
因此，当“重构”测试时，使用新集测试的程序显示相同的行为才真正重要。每个差异都应该仔细，人工检查，因为可能找到了新的程序错误。
重构时，您可能还会意外减少覆盖率。这很难找到，需要专门的覆盖率分析工具。
答案 3 :(得分：0)
你不知道你不会破坏任何东西。避免“谁来测试我们的测试？”的问题你应该尽可能简单地测试，以减少出错的可能性。
当您重构测试时，您总是可以使用自动重构或其他“可信”方法，如方法提取等。
您还经常使用现有的测试框架。他们是由他们的创作者测试的。所以当你开始构建自己的（甚至简单的）框架，复杂的辅助方法等时，你总是可以测试它