我对Ruby on Rails中各种测试设备的用途感到困惑。 我已经使用这个框架大约6个月了，但我从来没有理解它的测试部分。 我唯一使用过的测试是Java中的JUnit3，而且只用了很短的时间。
我读到的所有关于测试的内容仅仅展示了测试验证。Rails中的验证不应该只是起作用吗？这似乎更像是测试框架而不是测试您的代码。为什么需要测试验证呢？
此外，测试似乎对代码的任何更改都非常脆弱。因此，如果您更改模型中的任何内容，就必须更改测试和固定数据以匹配。这不违反了DRY原则（不要重复自己）吗？
第三，编写测试代码似乎需要很多时间。这正常吗？难道刷新浏览器并查看是否有效不是更快吗？我已经必须测试我的应用程序，以确保其正常流动并确保我的CSS没有出错。为什么手动测试不足够呢？
我曾经问过这些问题，但我得到的回答都只有“自动化测试是自动化的”。我足够聪明，可以理解自动化任务的优点。我的问题是编写测试的成本似乎与获得的好处相比过高。话虽如此，任何详细的回答都受欢迎，因为我可能会错过一两个好处。
validates_numericality_of调用"。这是真的吗？每个开发人员是否总是记得首先编写它？每个开发人员是否从未因粘贴时出现错误而意外删除了一行？在我个人看来，你不需要测试Rails验证帮助程序的每一个组合，但你需要一行代码来测试它是否存在并传递了正确的值，以防将来某个淘气鬼在没有恰当考虑之前更改它。测试代码和应用程序代码密切相关，它们就像硬币的两面一样。你不会想要一个只有正面而没有背面的硬币，或者只有背面而没有正面的硬币。良好的测试代码强化了优秀的应用程序代码，反之亦然。它们一起用于理解你试图解决的整个问题。同时，编写良好的测试代码是文档 - 它展示了如何使用应用程序代码。
其次，编写测试代码似乎需要花费很多时间。这很正常吗？难道不直接在浏览器中刷新查看效果更快吗？我已经要在我的应用程序中进行操作以查看是否正确流转，并确保我的 CSS 没有出现问题。为什么手动测试不够呢？
你可能只在非常小的项目上工作过，对于这些项目来说，该测试方式可能足够。然而，当你在一个由多个开发人员、包含数千或数万行代码、与 web 服务、第三方库、多个数据库进行集成、需要几个月的开发和需求变更等因素的项目上工作时，其他因素才显得重要。手动测试是远远不够的。在任何真正复杂的项目中，一个地方的更改经常会导致其他地方出现无法预料的结果。适当的架构有助于缓解这个问题，但自动化测试也有帮助（并有助于识别可以改进架构的点），它可以识别一个地方的更改是否会影响其他地方。
我的问题是编写测试的成本相比好处似乎非常高。话虽如此，欢迎任何详细的回答，因为我可能漏掉了某些好处。
我将列举一些其他好处。
如果你先进行测试（测试驱动开发），那么你的代码可能会更好。我还没有遇到过一个程序员，他们认真尝试后不是这种情况。首先进行测试可以强制你思考问题并真正设计出解决方案，而不是胡乱编写代码。此外，它会迫使你充分了解问题领域，以便在必须胡乱编写代码时，你知道你的代码在你定义的限制范围内工作。
如果你有完整的测试覆盖率，你可以无风险地进行重构。如果软件问题非常复杂（再次说明，持续几个月的真实项目往往很复杂），那么你可能希望简化先前编写的代码。因此，你可以编写新代码来替换旧代码，如果它通过了所有测试，那么就完成了。它与旧代码相比在测试方面的功能完全相同。对于计划使用敏捷开发方法的项目，重构绝对是必不可少的。变化总是需要进行。
总之，自动化测试，特别是测试驱动开发，基本上是一种管理软件开发复杂性的方法。如果你的项目不是非常复杂，则成本可能超过收益（尽管我怀疑）。然而，真实世界的项目往往非常复杂，测试和TDD的结果说明了一切：它们有效。
（如果你好奇，我认为丹·诺斯（Dan North）在行为驱动开发方面的文章非常有帮助：http://dannorth.net/introducing-bdd）
测试应该验证您的应用程序逻辑。就个人而言，我认为最重要的测试是在Selenium中运行的测试。它们检查浏览器中显示的内容是否与我期望看到的内容相同。但是，如果那是我全部拥有的，那么我会发现很难调试 - 还需要更低级别的测试以及集成、功能和单元测试都是有用的工具。单元测试可以让您检查模型的行为是否符合您的预期（这意味着每种方法，而不仅仅是验证）。验证肯定会正常工作，但只有当您正确使用它们时才会如此。如果您使用错误，则它们将正常工作，但不会按照您的预期方式。编写几行测试比以后调试更快。
像http://wiseheartdesign.com/2006/01/16/testing-rails-validations上的简单示例只检查单元测试中的验证。O'Reilly文章http://www.oreillynet.com/pub/a/ruby/2007/06/07/rails-testing-not-just-for-the-paranoid.html?page=1更加详细（尽管仍然相当基本）。
自动化测试在回归测试中特别有用，其中您更改某些内容并运行一组测试来检查是否没有其他任何问题。
测试是重复的一种形式，但它们不违反DRY原则，因为它们以不同的方式表达事物。测试说“我做了X，所以应该发生Y”。代码说“X发生了，现在我需要做Z，这恰好导致Y发生”。即测试刺激原因并检查效果，而代码响应原因并产生效果。