4 ms·

Test with Ruby not Cucumber

27 points by ryandotsmith 16y ago

swombat 16y ago
You can also use Steak: http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-for-vegetarians/ http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-f...
- ryandotsmith 16y ago
  +1 Steak is a wonderful alternative.
- cageface 16y ago
  That has got to be one of the least usable blog layouts I've ever seen. It's all flash over substance, which is rather fitting because you can say the same thing about a lot of these testing libraries. Factories are better than fixtures, I'll admit. All this other cruft that's grown up around Rails testing can be trivially replaced with Test::Unit with no real loss in readability and great improvements in overall simplicity. If Test::Unit is good enough to keep Rails itself on track it's certainly good enough to keep your app under control.
  - swombat 16y ago
    Cue religious debate about testing frameworks...
  - deleted 16y ago
    [deleted]
- jamesbritt 16y ago
  This vegetarian prefers Bacon. http://github.com/chneukirchen/bacon/ http://github.com/chneukirchen/bacon/
ryandotsmith 16y ago
FYI. I have updated the post with an image describing my customer's feature development process.
zach 16y ago
I think it's great to start (design) high-level tests in human language - in a chart, in a spreadsheet, in lines or paragraphs. Of course, in Cucumber you use structured English in a slightly inflexible way. But the code should be something that you can walk through when you are running tests. This is what Cucumber is not great at. You want tests that tell a story, but the code is all in a phrasebook. After some initial experience with Cucumber, I think I will switch to an old-school low-tech approach that I've used many times -- design in conversational English steps, convert those lines to comments, and write code in-between (in this case, using Steak). The flexibility seems like a much bigger advantage than the automation Cucumber provides.
oomkiller 16y ago
I think you're missing the point of Cucumber (at least as I see it). While it's great if customers write cucumber scenarios and send them to you (we have one that does), that's not the main reason for it. Cucumber facilitates communication between product design and product development/engineering. Cucumber allows the people with much more domain knowledge than you look at your specs and tell you if something is awry. I think this is the biggest win with Cucumber. One of our clients was dead set on having "functional specs" for every feature we implemented. With Cucumber, they can read our "functional specs" or write their own and send them to us. Then, we can use those functional specs for actual testing, rather than them just gathering dust somewhere on a wiki. Finally, I do agree that some people overuse Cucumber. Cucumber should really only be used when adding new features, or when something needs the addition of communication with stakeholders. Otherwise, you should fall back to unit testing, or just normal integration testing with RSpec stories or Steak. For example, I think it's overkill to write a Cucumber test in the case of a bug. At most, you should have a Steak/RSpec story that reproduces the issue.
- mwood3 16y ago
  So are you saying that if a customer expects a desired result to a scenario and when they test the scenario (manual testing) and the desired result isn't there then a cucumber test should not be written?

27 points by ryandotsmith 16y ago

You can also use Steak: http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-for-vegetarians/ http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-f...

ryandotsmith 16y ago
+1 Steak is a wonderful alternative.
cageface 16y ago
That has got to be one of the least usable blog layouts I've ever seen. It's all flash over substance, which is rather fitting because you can say the same thing about a lot of these testing libraries. Factories are better than fixtures, I'll admit. All this other cruft that's grown up around Rails testing can be trivially replaced with Test::Unit with no real loss in readability and great improvements in overall simplicity. If Test::Unit is good enough to keep Rails itself on track it's certainly good enough to keep your app under control.
- swombat 16y ago
  Cue religious debate about testing frameworks...
- deleted 16y ago
  [deleted]
jamesbritt 16y ago
This vegetarian prefers Bacon. http://github.com/chneukirchen/bacon/ http://github.com/chneukirchen/bacon/

ryandotsmith 16y ago

FYI. I have updated the post with an image describing my customer's feature development process.

zach 16y ago

I think it's great to start (design) high-level tests in human language - in a chart, in a spreadsheet, in lines or paragraphs. Of course, in Cucumber you use structured English in a slightly inflexible way. But the code should be something that you can walk through when you are running tests. This is what Cucumber is not great at. You want tests that tell a story, but the code is all in a phrasebook. After some initial experience with Cucumber, I think I will switch to an old-school low-tech approach that I've used many times -- design in conversational English steps, convert those lines to comments, and write code in-between (in this case, using Steak). The flexibility seems like a much bigger advantage than the automation Cucumber provides.

oomkiller 16y ago

I think you're missing the point of Cucumber (at least as I see it). While it's great if customers write cucumber scenarios and send them to you (we have one that does), that's not the main reason for it. Cucumber facilitates communication between product design and product development/engineering. Cucumber allows the people with much more domain knowledge than you look at your specs and tell you if something is awry. I think this is the biggest win with Cucumber. One of our clients was dead set on having "functional specs" for every feature we implemented. With Cucumber, they can read our "functional specs" or write their own and send them to us. Then, we can use those functional specs for actual testing, rather than them just gathering dust somewhere on a wiki. Finally, I do agree that some people overuse Cucumber. Cucumber should really only be used when adding new features, or when something needs the addition of communication with stakeholders. Otherwise, you should fall back to unit testing, or just normal integration testing with RSpec stories or Steak. For example, I think it's overkill to write a Cucumber test in the case of a bug. At most, you should have a Steak/RSpec story that reproduces the issue.

mwood3 16y ago
So are you saying that if a customer expects a desired result to a scenario and when they test the scenario (manual testing) and the desired result isn't there then a cucumber test should not be written?