我正在尝试学习TDD和单元测试的概念，并且看到了我的口头禅：“红色，绿色，重构”。我很好奇为什么测试通过后您应该重构代码？
这对我来说毫无意义，因为如果测试通过，那为什么还要弄乱代码呢？我还看到TDD的口号，例如“只写足够的代码以使测试通过。”
我能想到的唯一原因是，如果要使测试通过绿色，您只是草率地编写任何旧代码。您只需共同制定解决方案即可获得通过测试。那么显然代码是一团糟，因此您可以清理它。
编辑：
我在另一个stackoverflow帖子上找到了此链接，我认为这证实了我提出的唯一原因，即“通过”测试的原始代码可以非常简单，甚至可以硬编码：http://blog.extracheese.org/2009/11/how_i_started_tdd.html
最佳答案
通常，即使不是一团糟，代码的第一个工作版本仍然可以改进。因此，您可以对其进行改进，使其更加整洁，可读性强，删除重复项，查找更好的变量/方法名称等。这就是重构。并且由于有了测试，因此可以安全地进行重构，因为测试将显示是否意外损坏了某些东西。
请注意，通常您不是从头开始编写代码，而是修改/扩展现有代码以添加/更改功能。并且现有的代码可能尚未准备好无缝地容纳新功能。因此，新功能的第一个实现可能看起来笨拙或不便，或者您可能会发现很难进一步扩展。因此，您可以改进设计，以最简单，最简洁的方式合并所有现有功能，同时仍要通过所有测试。
您的问题是对“如果有效，请不要解决”的古老说法。但是，正如Martin Fowler在“重构”中解释的那样，可以用许多不同的方式来破坏代码。即使它通过所有测试，也很难理解，因此很难扩展和维护。而且，如果它看起来草率，那么将来的程序员将更加不注意保持它整洁，因此它会更快地恶化，并最终退化为完全无法维护的混乱。为了防止这种情况，我们重构为始终保持代码尽可能整洁。如果我们（或我们的前任）已经让它变得一团糟，那么重构是一项巨大的努力，对管理层和利益相关者没有明显的直接好处。因此很难说服他们在实践中支持大规模重构。因此，在每次代码更改后，我们都将以很小甚至很简单的步骤进行重构。
关于unit-testing - 红色，绿色，重构-为什么要重构？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5750366/