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

ste*_*ble 2 bdd ruby-on-rails webrat cucumber

目前,我的开发过程如下:

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

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

SFE*_*ley 8

我实际上非常同情你的观点.我喜欢Cucumber ,我喜欢RSpec - 我使用它们,但并不总是使用相同的代码.例如,我现在很少为Rails控制器编写RSpec示例,而且我几乎从不编写视图规范.我的大多数控制器非常相似,并且不会偏离"库存"控制器模式 - 这已经过Rails自己的单元测试的良好测试.再次验证相同的行为并不会花费很多时间和模拟所有模型的麻烦.由于Cucumber处于集成级别,我可以跳过这种模拟,并获得我正在寻找的基本验证.在大多数情况下,Cucumber中的视图测试处理得更加透明.(然后我应该看到"foo"等等.)

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

作为一种启发式方法,我建议您在以下任何一个问题都可以回答"是"的时候强烈考虑编写单元测试:

  • 我写的代码是不是很复杂?
  • 此代码是否主要用于为其他代码提供答案?
  • 这是我正在重构的现有代码(还没有单元测试)吗?
  • 我在这段代码中发现了一个错误吗?(如果是这样,在修复它之前写一个单元测试,这样它就不会再次进入.)
  • 关于实现此代码的最优雅方式,我是否需要思考超过十秒钟?
  • 我的蜘蛛侠感觉刺痛吗?

如果以上都不是真的,那么也许你可以通过集成测试来逃避.同样,在很多情况下这是合理的.但如果你以后遇到问题,请准备付出代价 - 而且如果他们需要的话,那个价格应该包括随时编写单元测试.