Rog*_*son 7 tdd refactoring unit-testing
代码不断发展,如果没有修剪,它也会衰减,在这方面有点像花园.修剪意味着重构以使其实现其不断发展的目的.
如果我们有良好的单元测试覆盖率,重构会更安全.测试驱动的开发迫使我们在生产代码之前首先编写测试代码.因此,我们无法测试实现,因为没有.这使得重构生产代码变得更加容易.
TDD周期是这样的:编写测试,测试失败,编写生产代码直到测试成功,重构代码.
但是从我所看到的,人们重构生产代码,而不是测试代码.随着测试代码的衰减,生产代码将变得陈旧,然后一切都走下坡路.因此,我认为有必要重构测试代码.
问题在于:如何确保在重构时不破坏测试代码？
(我已经采用了一种方法,https://thecomsci.wordpress.com/2011/12/19/double-dabble/,但我认为可能有更好的方法.)
显然有一本书,http://www.amazon.com/dp/0131495054,我还没有读过.
还有一个关于此的Wiki页面http://c2.com/cgi/wiki?RefactoringTestCode,它没有解决方案.
重构测试是一个两步过程。简单地说：首先，您必须使用正在测试的应用程序，以确保重构时测试通过。然后，在重构的测试通过后，您必须确保它们会失败。然而，要正确做到这一点需要一些特定的步骤。
为了正确测试重构的测试，您必须更改被测应用程序以导致测试失败。只有该测试条件才会失败。这样，您可以确保测试除了通过之外还正确失败。您应该努力争取单个测试失败，但在某些情况下这是不可能的（即不是单元测试）。但是，如果您正确重构，重构的测试中将会出现单个失败，而其他失败将存在于与当前重构无关的测试中。需要了解您的代码库才能正确识别此类级联故障，并且此类故障仅适用于单元测试以外的测试。