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