我有一个Rails项目,我忽略了构建测试(为了羞耻!)并且代码库已经变得非常大.我的一个朋友说除非你从一开始就使用它,否则RSpec是一种痛苦.这是真的?是什么让他这么说?
因此,考虑到可用的测试套件以及代码库已经存在的事实,使这个东西可测试的最佳方法是什么?它真的与从一开始就做的那么大不同吗?
这个问题最近出现在RSpec邮件列表中,我们通常给出的建议是:
不要试图将规范改编为现有的,工作的代码,除非你要改变它 - 这是令人筋疲力尽的,除非代码需要改变,否则毫无意义.
从现在开始为您所做的任何更改开始编写规范.错误修复是一个特别好的机会.
尝试训练自己进入触摸代码之前的规则,首先写一个失败的例子(= spec)来驱逐变化.
您可能会发现代码示例或单元测试没有驱动的代码设计使编写测试或规范变得尴尬.这可能是你朋友所暗示的.您几乎肯定需要学习一些关键的重构技术来分解依赖关系,这样您就可以独立于规范来运用每个类.Michael Feathers的优秀着作"有效地使用遗留代码"有一些很棒的材料可以帮助你学习这种微妙的技巧.
我还鼓励您使用内置规范:rcov rake任务来生成代码覆盖率统计信息.当您开始对代码库进行测试时,观看这些数字会非常有意义.