如何重构单元测试？

Question

最近我都快疯了..。

重构是什么？

代码重构是重组现有的计算机代码-更改保理-而不改变其外部行为的过程。

我们如何确保在重构过程中不破坏任何东西？

在重构一段代码之前，需要一组完整的自动单元测试。测试是用来证明在重构之前模块的行为是正确的。

好吧好吧。但是，如果我在单元测试中发现代码气味，我该如何进行呢？比如说，测试方法做得太多了吗？如何确保在重构单元测试时不破坏任何东西？

我需要做什么元测试吗？是单位测试一直下去吗？

还是单元测试根本不遵守正常的重构规则？

Answer 1

根据我的经验，有信任测试的两个原因

• 回顾
• 你已经看到它失败了

这两者都是在编写测试时发生的活动。如果你保持测试是不变的，你可以继续相信他们。

每次修改测试时，它都会变得不那么值得信任。

通过重复上面的过程，您可以在一定程度上缓解这个问题:检查对测试的更改，并临时更改tests下的系统(SUT)，以便您可以看到测试按照预期的失败。

在修改测试时，请保持SUT不变。测试和生产代码相互制约，所以在保持另一个锁定的的同时改变一个是最安全的。

Answer 2

恕我直言，这是一个较旧的帖子，它是引用在评论中在我的帖子关于TDD在实践中。所以回顾一下，我想再加两分钱。

主要是因为我觉得接受答案说的话有些滑溜溜的：

每次修改测试时，它都会变得不那么值得信任。

我对“修改”这个词有异议。对于重构，通常避免使用更改、修改等词语，因为它们的含义与重构相反。

如果您修改了传统意义上的测试，那么引入的更改会降低测试的可信度。

但是，如果您在重构意义的中修改了测试，那么测试应该是而不是值得信任的。

这使我回到原来的问题：

如何重构单元测试？

非常简单，与任何其他代码相同--单独使用。

因此，如果您想重构您的测试，不要更改代码，只需更改测试。

我需要考试吗？

No.事实上，肯特·贝克在他的全叠广播采访中回答了这个问题，他说：

您的代码是测试的测试。

Mark在他的回答中也注意到了这一点

测试和生产代码相互制约，因此在保持另一个锁的同时改变一个是最安全的。

最后，这与其说是关于如何重构测试，不如说是一般的重构。同样的原则也适用，即重构代码而不更改其外部行为。如果不改变外部行为，那么就不会失去信任。

Answer 3

如何确保在重构单元测试时不破坏任何东西？

保留旧的测试作为参考。

详细说明:具有良好覆盖率的单元测试在结果中是值得的。您不会将它们保存在令人惊奇的程序结构或缺少重复；它们本质上是一个有用的输入/输出对的数据集。

因此，当“重构”测试时，真正重要的是用新集合测试的程序表现出相同的行为。每个差异都应该小心，手动检查，因为可能已经发现了新的程序错误。

您还可能意外地减少了重构时的覆盖率。这很难找到，并且需要专门的覆盖率分析工具。