通过集成测试练习 BDD——我还需要单元测试吗?

发布于 2024-08-08 06:12:01 字数 232 浏览 3 评论 0原文

目前,我的开发流程是这样的:

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

在我看来,根据定义,我的集成测试正在测试我可以创建的每个模型、控制器和视图。事实上,我是否因为不编写单元测试而错过了任何东西?

At present, my development process flows like this:

  1. I describe the expected behaviour as an integration test using using WebRat
  2. I write the Ruby on Rails code to provide that behaviour, so passing the test
  3. I refactor, ensuring the tests still pass at the end of the process
  4. I write the next integration test

It seems to me that by definition, my integration tests are testing every model, controller and view that I can create. In reality, am I missing anything by not writing unit tests too?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

零時差 2024-08-15 06:12:01

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

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

作为一种启发,我建议您在任何时候可以回答“是”的问题时强烈考虑编写单元测试:

  • 我正在编写的代码是否非常复杂?
  • 这段代码的存在主要是为了给其他代码提供答案吗?
  • 这是我正在重构的现有代码(尚未进行单元测试)吗?
  • 我在这段代码中发现了错误吗? (如果是这样,请在修复它之前编写一个单元测试,这样它就不会再次潜入。)
  • 我是否需要花十多秒钟的时间思考实现此代码的最优雅的方法?
  • 我的蜘蛛感应有刺痛感吗?

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

I'm actually pretty sympathetic to your point of view here. I love Cucumber and I love RSpec -- and I use them both, but not always on the same code. For instance, I rarely write RSpec examples for Rails controllers these days, and I almost never write view specs. Most of my controllers are very similar and don't deviate much from the "stock" controller pattern -- which is already well-tested by Rails's own unit tests. Verifying the same behavior again doesn't gain much for the time it takes and the hassle of mocking all the models. With Cucumber at an integration level I can skip that mocking and get the essential verification I'm looking for. View testing is handled much more transparently in Cucumber most of the time as well. (Then I should see "foo" and so forth.)

But that isn't to say I don't use RSpec extensively in Rails. I use it for the places where my logic lives: models, controller filters, and view helpers. I also have a couple of projects that are almost all business logic, e.g. libraries or API adapters against complex third-party interfaces. For those I usually find myself using RSpec exclusively and skipping Cucumber.

As a heuristic, I'd suggest that you should strongly consider writing a unit test any time any of the following questions can be answered "Yes":

  • Is the code I'm writing more than trivially complicated?
  • Does this code exist primarily to give answers to other code?
  • Is this existing code that I'm refactoring (that doesn't already have a unit test)?
  • Have I found a bug in this code? (If so, write a unit test before fixing it so it never sneaks in again.)
  • Do I have to think for more than ten seconds about the most elegant way to implement this code?
  • Is my Spidey Sense tingling?

If none of the above is true, then maybe you can get away with just doing integration testing. Again, there are a lot of cases where that's reasonable. But if you do run into problems later, be prepared to pay the price -- and that price should include writing unit tests at any moment if they seem called for.

莫言歌 2024-08-15 06:12:01

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

Integration tests are useful to verify that different parts of code are well integrated. They may involve all layers and cover all code but... when an integration test fails, will it tell you where the bug is located? I may be wrong but I don't think so. This will just tell you that there is a problem somewhere. On the other hand, when a real unit tests (written in isolation using mocks or stubs) fails, you know exactly in which unit the problem is located (this is actually the purpose of unit testing, verifying that a unit implements the expected behavior). In other words, unit tests and integration tests are both useful but they have different purposes.

離人涙 2024-08-15 06:12:01

你有任何耙子任务吗?自定义 Capistrano 代码?克朗方法?一个API?猴子补丁? Flex 或 iPhone 应用程序集成怎么样?一个工作跑步者?

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

Do you have any rake tasks? Custom capistrano code? Cron methods? An API? Monkeypatches? How about flex or iPhone app integration? A job runner?

In a typical Rails application, there's lots of code that isn't exercised by the HTML UI. So no, unless your app is incredibly simple, webrat tests won't be sufficient.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文