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