使用集成测试练习BDD - 我是否也需要单元测试？

Question

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

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

在我看来，通过DEFI我的集成测试正在测试我可以创建的每个模型，控制器和视图。实际上，我是否因为不写单元测试而错过任何东西？

Answer 1

你有任何rake任务吗？自定义capistrano代码？克龙方法？一个API？ Monkeypatches？如何Flex或iPhone应用程序集成？一个工作跑步者？

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

Answer 2

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

Answer 3

我其实非常同情你的观点。我喜欢黄瓜和我喜欢RSpec - 并且我都使用它们，但并不总是使用相同的代码。例如，我现在很少为Rails控制器编写RSpec示例，并且几乎从不写视图规范。我的大多数控制器非常相似，并且不会偏离“库存”控制器模式 - 这已经通过Rails自己的单元测试进行了充分测试。再次验证同样的行为对于所花费的时间和嘲笑所有模型的麻烦并没有太大的帮助。通过集成级别的Cucumber，我可以跳过这个嘲讽并获得我正在寻找的基本验证。大多数情况下，在黄瓜中查看测试的处理也要透明得多。 （然后我看到“富”等等。）

但是，这并不是说我不Rails中广泛使用RSpec的。我将它用于我的逻辑所在的地方：模型，控制器过滤器和视图助手。我也有几个项目几乎都是全部商业逻辑，例如，库或API适配器对付复杂的第三方接口。对于那些我通常只使用RSpec并跳过黄瓜的人。

作为一种启发式的，我建议你应该强烈考虑编写一个单元测试，任何时候任何的以下问题可以回答“是”：

• 是我写的代码比平凡复杂？
• 此代码是否存在主要用于解答其他代码？
• 这是我重构（还没有单元测试）的现有代码吗？
• 我在这段代码中发现了一个错误吗？ （如果是这样，请在修复之前编写一个单元测试，以免它再次潜入。）
• 我是否必须考虑超过十秒才能实现此代码的最优雅方式？
• 我的Spidey感是否刺痛？

如果以上都不是，那么也许你可以逃脱只是做集成测试。再次，有很多情况下，这是合理的。但是，如果您稍后遇到问题，请准备付出代价 - 并且该价格应包括在任何时候编写单元测试（如果他们似乎需要）。