Ruby on Rails - 为什么要使用测试？

我对Ruby on Rails中的各种测试设备的用途感到困惑.我已经使用该框架大约6个月,但我从来没有理解它的测试部分.我使用的唯一测试是Java中的JUnit3,而且只是简单的.

我读过的所有内容都只显示了测试验证.轨道中的验证不应该起作用吗？看起来更像测试框架而不是测试代码.为什么需要测试验证？

此外,对于代码中的任何更改,测试似乎都非常脆弱.因此,如果您更改模型中的任何内容,则必须更改测试和灯具以匹配.这不违反DRY原则吗？

第三,编写测试代码似乎需要很多时间.这是正常的吗？刷新我的浏览器并看它是否有效会不会更快？我已经不得不玩我的应用程序只是为了看它是否正确流动并确保我的CSS没有爆炸.为什么手动测试不够？

我之前已经问过这些问题而且我没有得到"自动化测试自动化".我足够聪明,可以找出自动化任务的优势.我的问题是,与好处相比,编写测试的成本似乎非常高.也就是说,任何详细的回复都是受欢迎的,因为我可能错过了一两个好处.

轨道中的验证不应该起作用吗？看起来更像测试框架而不是测试代码.为什么需要测试验证？

Rails中的验证确实有效 - 事实上,Rails代码库中有单元测试来确保它.当您测试模型的验证时,您正在测试验证的细节:长度,可接受的值等.您确保代码是按预期编写的.一些验证是简单的帮助,您可以选择不测试"没有人可以搞乱validates_numericality_of电话" 的概念.真的吗？每个开发人员总是记得首先编写它吗？每个开发人员都不会意外删除坏复制粘贴上的一行吗？在我个人看来,您不需要为Rails的验证助手测试每个值的最后组合,但是您需要一行来测试它是否通过了正确的值,

此外,其他验证更复杂,需要大量自定义代码 - 它们可能需要更彻底的测试.

此外,对于代码中的任何更改,测试似乎都非常脆弱.因此,如果您更改模型中的任何内容,则必须更改测试和灯具以匹配.这不违反DRY原则吗？

我不相信它违反DRY.他们正在沟通(这就是编程,沟通)两个截然不同的事情.测试说代码应该做点什么.代码说明它实际上做了什么.当这些东西之间断开连接时,测试非常重要.

显然,测试代码和应用程​​序代码密切相关.我认为它们是硬币的两面.你不会想要没有背部的前部,或没有前部的背部.良好的测试代码强化了良好的应用程序代码,反之亦然.这两者一起用于理解您试图解决的整个问题.而且写得很好的测试代码的文档-它显示了如何将应用程序代码应该被使用.

第三,编写测试代码似乎需要很多时间.这是正常的吗？刷新我的浏览器并看它是否有效会不会更快？我已经不得不玩我的应用程序只是为了看它是否正确流动并确保我的CSS没有爆炸.为什么手动测试不够？

你只参与过很小的项目,测试可以说是足够的.但是,当您使用多个开发人员,数千或数万行代码,与Web服务的集成点,第三方库,多个数据库,数月的开发和需求更改等工作时,还有很多其他发挥作用的因素.手动测试是不够的.在任何真正复杂的项目中,一个地方的变化往往会在其他地方产生无法预料的结果.适当的体系结构有助于缓解这一问题,但通过识别一个地方的变化何时破坏另一个地方,自动化测试也有助于(并帮助确定可以改进体系结构的点).

我的问题是,与好处相比,编写测试的成本似乎非常高.也就是说,任何详细的回复都是受欢迎的,因为我可能错过了一两个好处.

我会列出一些好处.

如果您先测试(测试驱动开发),您的代码可能会更好.我还没有见过一个程序员给了他一个坚实的镜头,但事实并非如此.测试首先迫使您考虑问题并实际设计您的解决方案,而不是将其解决.此外,它会强迫您充分理解问题域,如果您必须将其破解,您知道您的代码在您定义的限制范围内工作.

如果您有完整的测试覆盖率,您可以无风险地进行重构.如果软件问题非常复杂(同样,持续数月的现实世界项目往往很复杂),那么您可能希望简化先前编写的代码.因此,您可以编写新代码来替换旧代码,如果它通过了所有测试,那么您就完成了.它完全与旧代码在测试方面所做的完全相同.对于计划使用敏捷开发方法的项目,重构绝对必不可少.总是需要做出改变.

总而言之,自动化测试,尤其是测试驱动开发,基本上是一种管理软件开发复杂性的方法.如果您的项目不是很复杂,那么成本可能会超过收益(尽管我对此表示怀疑).然而,现实世界的项目往往非常复杂,测试和TDD的结果不言自明:它们起作用.

(如果你很好奇,我发现Dan North关于行为驱动开发的文章非常有助于理解测试中的许多价值:http: //dannorth.net/introducing-bdd)