Test with Ruby not Cucumber(afewgoodlines.com)
afewgoodlines.com
Test with Ruby not Cucumber
http://afewgoodlines.com/post/1077316188/integration-testing-retrospective-part-i
4 comments
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.
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.
You can also use Steak:
http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-f...
http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-f...
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.
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.
Cue religious debate about testing frameworks...
[deleted]
This vegetarian prefers Bacon.
http://github.com/chneukirchen/bacon/
http://github.com/chneukirchen/bacon/
+1 Steak is a wonderful alternative.
FYI. I have updated the post with an image describing my customer's feature development process.
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.