Cucumber 是否不需要编写单元测试? [英] Does cucumber do away with the need to write unit tests?

问题描述

我对 Ruby/ROR 可用的测试框架数量之多感到有点困惑.

I am a little confused by the sheer number of testing frameworks available for Ruby/ROR.

我最近观看了 Cucumber Railscasts 并发现它们非常有趣.所以我开始玩游戏，然后努力想从概念上看我应该把各种测试放在哪里.

I have recently watched the Cucumber Railscasts and found them very interesting. So I started having a play and then struggled to see conceptually where I would put various tests.

似乎可以在 Cucumber 中完成单元测试中可以完成的所有工作，所以我是否需要编写单元测试，还是应该只编写我的功能定义并专注于提供尽可能好的覆盖范围开始使用它.

It would seem to be quite possible to do everything that can be done in unit tests within Cucumber, so do I need to write unit tests or should I just write my feature definitions and concentrate on providing as good a coverage as I can get using that.

我应该使用 Rspec 还是 Test:Unit 创建我的单元测试?当我测试 Ajax 功能时，我应该使用 Selenium 还是 Watir?

Should I create my Unit tests using Rspec or Test:Unit? When I'm testing Ajax functionality should I use Selenium or Watir?

这里似乎有很多选择，我正在努力了解要使用哪些工具以及边界在哪里.

There seem to be so many options here I am struggling to see which tools to use and where the boundaries are.

其他人对 Cucumber 的体验是什么，以及如何在编写 Cucumber 集成测试和 Test:Unit 和/或基于 Rspec 的单元和功能测试之间划清界限.有没有人知道关于这个主题的一篇很好的文章，建议在测试方法和各种工具的优点和缺点之间划清界限.

What are other peoples experiences of Cucumber and where to draw the line between writing Cucumber Integration tests and Test:Unit and/or Rspec based unit and functional tests. Is anyone aware of a good write-up on this subject suggesting where to draw lines between testing methods and the strengths and weaknesses of the various tool.

我理解其中一些是主观的，但欢迎使用常见的方法来解决这个问题.

I appreciate that some of this is subjective but common approaches on how to attack this issue would be welcomed.

推荐答案

在较高级别使用 Cucumber 来描述用户应该能够看到和执行的操作.使用 RSpec、Test:Unit、Shoulda 等编写单元测试.直接来自马嘴:

Use Cucumber at a high level to describe what a user should be able to see and do. Use RSpec, Test:Unit, Shoulda, etc. to write unit tests. Straight from the horse's mouth:

当您决定要添加新功能或修复错误时，请先编写描述该功能应如何工作的新功能或场景.不要写任何代码(暂时).

When you decide you want to add a new feature or fix a bug, start by writing a new feature or scenario that describes how the feature should work. Don’t write any code (yet).

...

这是您开始编写代码的时候.首先编写几行代码来解决您从 Cucumber 获得的失败.再次运行黄瓜.重复并冲洗，直到您对自己的功能感到满意为止.当您深入了解细节时，请降低一个抽象级别并使用 RSpec 或任何 Ruby 测试框架为您的类编写一些规范/测试.

This is when you start writing code. Start by writing a couple of lines of code to address the failure you got from Cucumber. Run cucumber again. Repeat and rinse until you’re happy with your feature. When you get down to nitty gritty details, drop down one abstraction level and use RSpec, or any Ruby testing framework, to write some specs/tests for your classes.

Cucumber 用于测试您的整个堆栈，而不是单元".

Cucumber is made to test your whole stack, together, as opposed to 'units'.

您需要决定在哪里划线，但黄瓜测试可能无法涵盖很多幕后的东西.假设在注册时，我填写了一个表单，包括我的姓名、电子邮件、电话号码等.单元测试可能会检查新的 User 是否也会创建一个新的 TelephoneNumber.从用户的角度来看，他们并不真正关心它是否创建了一个新的TelephoneNumber，他们关心的是一旦他们注册，他们就有了一个帐户并且可以看到他们的电话号码.

You need to decide where to draw the line, but a lot of under the hood stuff probably wouldn't be covered in a cucumber test. Say when signing up, I fill out a form, with my name, email, phone number, etc. A unit test might check to see that a new User will also create a new TelephoneNumber. From the user's perspective, they don't really care that it creates a new TelephoneNumber, they care that once they've signed up, they have an account and can see their telephone number.

我没有太多编写黄瓜测试的经验(还没有)，但我希望这会有所帮助.

I don't have too much experience writing cucumber tests (not yet), but I hope this helps a bit.

这篇关于Cucumber 是否不需要编写单元测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！