我有一个Rails项目，但我忽略了为其构建测试(可耻！)，并且代码库已经变得很大。我的一个朋友说RSpec很难使用，除非我们从一开始就使用它。这是真的？他会怎么说呢？

因此，考虑到可用的测试套件以及代码库已经存在的事实，使此东西可测试的最佳方法是什么？它与一开始就真的有很大不同吗？

解决方案

也许从模型开始？它们应该可以孤立地进行测试，这应该使它们成为悬念最少的果实。

然后选择一个模型，并开始编写说明其功能的测试。在进行过程中，请考虑其他方法来测试代码是否存在一些不确定的情况？编写测试并查看模型的行为。在开发测试时，我们可能会发现代码中的区域不像以前那样整洁和重复数据删除(DRY)。现在有了测试，就可以重构代码，因为我们知道自己不会影响行为。除非我们进行了适当的测试，否则请不要尝试开始改进设计。

固定模型后，向上移动。

那是一种方式。替代方案可能是从视图或者控制器开始的，但我们可能会发现从端到端事务测试开始并在逐步发展的过程中变得越来越容易。

这个问题最近出现在RSpec邮件列表中，我们通常给出的建议是：

• 除非我们要对其进行更改，否则不要费心尝试将规范改编为现有的，有效的代码-这很累，并且除非需要更改代码，否则毫无意义。
• 从现在开始开始为我们所做的任何更改编写规格。错误修复是一个特别好的机会。
• 尝试将自己训练成一种纪律，即在接触代码之前，首先编写一个失败的示例(= spec)来驱除更改。

我们可能会发现，没有被代码示例或者单元测试淘汰的代码设计使编写测试或者规范变得很尴尬。这也许是朋友所暗示的。几乎可以肯定，我们将需要学习一些关键的重构技术来打破依赖关系，以便可以独立于规范来练习每个类。迈克尔·费瑟斯(Michael Feathers)的绝妙著作《有效地使用旧版代码》(Legacy Code)有效地提供了一些很好的材料，可以学习这一精湛的技能。

我也鼓励我们使用内置的spec：rcov rake任务来生成代码覆盖率统计信息。当我们开始对代码库进行测试时，看到这些数字增加是非常令人高兴的。

接受的答案是很好的建议，尽管在某些情况下不切实际。我最近在我的一些应用程序上遇到了这个问题，因为我需要对现有代码进行测试。根本没有其他解决办法。

我开始进行所有单元测试，然后转到功能上。

养成为任何新代码编写失败测试的习惯，或者每当我们要更改系统的一部分时就养成这种习惯。我发现这有助于我在进行过程中获得更多的测试知识。

使用rcov衡量进度。

祝你好运！

为现有代码编写测试可能会发现代码中的错误。这些测试将迫使我们查看现有的代码，因此我们可以查看为了通过测试而需要编写的测试，并且可能会看到一些可能写得更好的代码，或者现在已经无用了。

另一个技巧是在遇到错误时编写测试，以使它永远都不会发生，这称为回归测试。

改装规格并不是一个坏主意。我们从工作代码转到具有已知属性的工作代码，这使我们能够了解将来的任何更改是否会破坏任何东西。目前，如果我们需要进行更改，那么我们如何知道它将产生什么影响？

人们说很难在现有代码中添加测试/规范的意思是，难以测试的代码通常高度耦合，这使得编写低级隔离测试变得困难。

一种想法是从使用RSpec故事运行程序之类的东西开始进行全栈测试开始。然后，我们可以从"外部"进行工作，隔离在低级隔离测试中可以实现的功能，并逐渐解开较难的代码。