2

目前，我的开发流程是这样的：

  1. 我将预期的行为描述为使用 WebRat 的集成测试
  2. 我编写了 Ruby on Rails 代码来提供这种行为，因此通过了测试
  3. 我重构，确保测试在过程结束时仍然通过
  4. 我编写下一个集成测试

在我看来，根据定义，我的集成测试正在测试我可以创建的每个模型、控制器和视图。实际上，我是否也因为不编写单元测试而遗漏了什么？

4

3 回答 3

8

我其实很同情你在这里的观点。我喜欢 Cucumber ，也喜欢 RSpec——我同时使用它们，但并不总是在同一个代码上。例如，这些天我很少为 Rails 控制器编写 RSpec 示例，而且我几乎从不编写视图规范。我的大多数控制器都非常相似，并且与“库存”控制器模式没有太大的差异——Rails 自己的单元测试已经很好地测试了这种模式。再次验证相同的行为并不会因为它花费的时间和模拟所有模型的麻烦而获得太多收益。在集成级别使用 Cucumber，我可以跳过该模拟并获得我正在寻找的基本验证。大多数时候，在 Cucumber 中，视图测试的处理也更加透明。（然后我应该看到“foo”

但这并不是说我没有在 Rails 中广泛使用 RSpec。我将它用于我的逻辑所在的地方：模型、控制器过滤器和视图助手。我还有几个项目几乎都是业务逻辑，例如针对复杂第三方接口的库或 API 适配器。对于那些我通常发现自己只使用 RSpec 而跳过 Cucumber 的人。

作为一种启发式方法，我建议您在以下任何问题都可以回答“是”时强烈考虑编写单元测试：

  • 我正在编写的代码是否非常复杂？
  • 这段代码的存在主要是为了给其他代码提供答案吗？
  • 这是我正在重构的现有代码（还没有单元测试）吗？
  • 我在这段代码中发现了一个错误吗？（如果是这样，在修复它之前编写一个单元测试，这样它就不会再次潜入。）
  • 我是否必须思考十多秒才能以最优雅的方式实现此代码？
  • 我的蜘蛛侠感觉刺痛吗？

如果以上都不是真的，那么也许你可以只做集成测试就可以了。同样，在很多情况下这是合理的。但是，如果您以后确实遇到了问题，请准备好付出代价——如果需要的话，这个代价应该包括随时编写单元测试。

于 2009-10-20T02:29:19.567 回答
3

集成测试有助于验证代码的不同部分是否集成良好。它们可能涉及所有层并涵盖所有代码，但是......当集成测试失败时，它会告诉您错误所在的位置吗？我可能错了，但我不这么认为。这只会告诉你某处有问题。另一方面，当真正的单元测试（使用模拟或存根单独编写）失败时，您确切地知道问题位于哪个单元（这实际上是单元测试的目的，验证一个单元是否实现了预期的行为） . 换句话说，单元测试和集成测试都是有用的，但它们有不同的目的。

于 2009-10-14T00:58:16.247 回答
2

你有任何 rake 任务吗？自定义 capistrano 代码？克朗方法？一个API？猴子补丁？flex 或 iPhone 应用程序集成怎么样？职业跑者？

在一个典型的 Rails 应用程序中，有很多代码没有被 HTML UI 使用。所以不，除非你的应用程序非常简单，否则 webrat 测试是不够的。

于 2009-10-13T23:03:11.117 回答