Rails中的验证确实有效--事实上,Rails代码库中有单元测试来确保其有效。当你测试一个模型的验证时,你在测试验证的具体细节:长度、接受的值等。你要确保代码按照预期编写。一些验证是简单的帮助程序,你可以选择不对它们进行测试,因为"没有人会搞砸一个
validates_numericality_of
调用"。这是真的吗?每个开发人员是否总是记得首先编写它?每个开发人员是否从未因粘贴时出现错误而意外删除了一行?在我个人看来,你不需要测试Rails验证帮助程序的每一个组合,但你需要一行代码来测试它是否存在并传递了正确的值,以防将来某个淘气鬼在没有恰当考虑之前更改它。
此外,其他验证更复杂,需要大量自定义代码,可能需要更彻底的测试。
此外,测试似乎对代码中任何更改都很脆弱。如果你在模型中改变任何东西,你必须改变你的测试和固定装置以匹配。这难道不违反了DRY原则吗?
我不认为这违反了DRY原则。它们传达了(这就是编程,通信)两种非常不同的东西。测试说代码
应该做某事。而代码则说明它
实际上做了什么。当这两个方面之间存在不一致时,测试非常重要。
测试代码和应用程序代码密切相关,它们就像硬币的两面一样。你不会想要一个只有正面而没有背面的硬币,或者只有背面而没有正面的硬币。良好的测试代码强化了优秀的应用程序代码,反之亦然。它们一起用于理解你试图解决的整个问题。同时,编写良好的测试代码是文档 - 它展示了如何使用应用程序代码。
其次,编写测试代码似乎需要花费很多时间。这很正常吗?难道不直接在浏览器中刷新查看效果更快吗?我已经要在我的应用程序中进行操作以查看是否正确流转,并确保我的 CSS 没有出现问题。为什么手动测试不够呢?
你可能只在非常小的项目上工作过,对于这些项目来说,该测试方式可能足够。然而,当你在一个由多个开发人员、包含数千或数万行代码、与 web 服务、第三方库、多个数据库进行集成、需要几个月的开发和需求变更等因素的项目上工作时,其他因素才显得重要。手动测试是远远不够的。在任何真正复杂的项目中,一个地方的更改经常会导致其他地方出现无法预料的结果。适当的架构有助于缓解这个问题,但自动化测试也有帮助(并有助于识别可以改进架构的点),它可以识别一个地方的更改是否会影响其他地方。
我的问题是编写测试的成本相比好处似乎非常高。话虽如此,欢迎任何详细的回答,因为我可能漏掉了某些好处。
我将列举一些其他好处。
如果你先进行测试(测试驱动开发),那么你的代码可能会更好。我还没有遇到过一个程序员,他们认真尝试后不是这种情况。首先进行测试可以强制你思考问题并真正设计出解决方案,而不是胡乱编写代码。此外,它会迫使你充分了解问题领域,以便在必须胡乱编写代码时,你知道你的代码在你定义的限制范围内工作。
如果你有完整的测试覆盖率,你可以无风险地进行重构。如果软件问题非常复杂(再次说明,持续几个月的真实项目往往很复杂),那么你可能希望简化先前编写的代码。因此,你可以编写新代码来替换旧代码,如果它通过了所有测试,那么就完成了。它与旧代码相比在测试方面的功能完全相同。对于计划使用敏捷开发方法的项目,重构绝对是必不可少的。变化总是需要进行。
总之,自动化测试,特别是测试驱动开发,基本上是一种管理软件开发复杂性的方法。如果你的项目不是非常复杂,则成本可能超过收益(尽管我怀疑)。然而,真实世界的项目往往非常复杂,测试和TDD的结果说明了一切:它们有效。
(如果你好奇,我认为丹·诺斯(Dan North)在行为驱动开发方面的文章非常有帮助:http://dannorth.net/introducing-bdd)