BDD with RSpec and Steak (via a real example)(timeless.judofyr.net)
timeless.judofyr.net
BDD with RSpec and Steak (via a real example)
http://timeless.judofyr.net/bdd-with-rspec-and-steak
8 comments
I'd really love to see this article accompanied with a video of you actually working (no narration necessary). I think it would be very helpful to see what the real work flow is like.
That is an awesome idea. For me, the power of BDD (it's really still just TDD but let's not open that can of worms further...) is in the process.
I'm not a fan of RSpec; however, I also find Steak just a little too minimalist for me.
Occasionally, I want very badly to be able to render my Scenarios to plain text for communication with customers and other developers. I need the individual steps for that as well.
Where the example here maintains the steps (eg., Given, when, and then) as comments, I prefer them in the code.
So I wrote Coulda (http://coulda.tiggerpalace.com/) a bit over a year ago. Yes, it uses Test::Unit. While I am in the minority, I still prefer Test::Unit. It scales well.
When I say that, I mean in the sense that I can write almost any test using just "assert" and then add an error message for when the assert fails. I don't limit myself to using solely "assert"; however, when I'm not sure how to write an assertion, and neither shoulda nor Test::Unit gives it to me, it's easy to build it using "assert" and then wrapping it in a method (making it a helper).
And I still find Test::Unit code readable enough. Maybe that's just a matter of taste.
Dare I add: RSpec, although cleaner with the release of RSpec 2.0, is still a very complicated swiss army knife. Miniunit, included in Ruby 1.9.1 but also available as a gem for older Ruby installs, is the basis for Test::Unit as Ruby moves forward. That is, Test::Unit inherits from Miniunit in Ruby 1.9.
And Miniunit is far far simpler than RSpec.
Update: I'll consider rolling a screencast of how I TDD w/ Coulda as a basis for comparison.
I'm not a fan of RSpec; however, I also find Steak just a little too minimalist for me.
Occasionally, I want very badly to be able to render my Scenarios to plain text for communication with customers and other developers. I need the individual steps for that as well.
Where the example here maintains the steps (eg., Given, when, and then) as comments, I prefer them in the code.
So I wrote Coulda (http://coulda.tiggerpalace.com/) a bit over a year ago. Yes, it uses Test::Unit. While I am in the minority, I still prefer Test::Unit. It scales well.
When I say that, I mean in the sense that I can write almost any test using just "assert" and then add an error message for when the assert fails. I don't limit myself to using solely "assert"; however, when I'm not sure how to write an assertion, and neither shoulda nor Test::Unit gives it to me, it's easy to build it using "assert" and then wrapping it in a method (making it a helper).
And I still find Test::Unit code readable enough. Maybe that's just a matter of taste.
Dare I add: RSpec, although cleaner with the release of RSpec 2.0, is still a very complicated swiss army knife. Miniunit, included in Ruby 1.9.1 but also available as a gem for older Ruby installs, is the basis for Test::Unit as Ruby moves forward. That is, Test::Unit inherits from Miniunit in Ruby 1.9.
And Miniunit is far far simpler than RSpec.
Update: I'll consider rolling a screencast of how I TDD w/ Coulda as a basis for comparison.
This may not be real/actual work enough for you (it's still an example), and it's not exactly the same as this BDD workflow, but this brief screencast still may be of some interest to some folks: http://blog.extracheese.org/2010/01/string-calculator-kata-i...
(I recommend embiggening the video player.)
(I recommend embiggening the video player.)
I will consider that a feature request for part II. :)
I'd also like to plug my own rspec extensions, Saki:
https://github.com/ludicast/saki
It lets you write your specs with "smart contexts" so you can do stuff like:
https://github.com/ludicast/saki
It lets you write your specs with "smart contexts" so you can do stuff like:
with_existing :user do
that_has_an :article do
that_has_a :comment do
with_existing :user do
on_visiting edit_user_path do
it { should let_me_edit(@user) }
end
end
The only problem that I see with this is the same that I see with vanilla RSpec or shoulda: state is accumulated through nested blocks.
This is why I tend to prefer the Given-When-Then style with reusable "macros" (class methods) that provide niceties such as "given_a :user", "when_i_visit root_path", etc.
Assuming that you are writing automated acceptance test, any test of more than trivial length would then be nested several levels deep.
This is why I tend to prefer the Given-When-Then style with reusable "macros" (class methods) that provide niceties such as "given_a :user", "when_i_visit root_path", etc.
Assuming that you are writing automated acceptance test, any test of more than trivial length would then be nested several levels deep.
That's a reasonable argument but doesn't bother me because
1) I don't like the given/when/then syntax anymore (a personal thing, but I do see the advantages (Uncle Bob has a great article about it))
2) I don't mind the nesting as long as each context is making explicit what it does.
Of course it's a "different strokes" thing. I could see this not fitting in with everybody's style but for me it has DRYed up the parts of a test that should be DRY (imho).
1) I don't like the given/when/then syntax anymore (a personal thing, but I do see the advantages (Uncle Bob has a great article about it))
2) I don't mind the nesting as long as each context is making explicit what it does.
Of course it's a "different strokes" thing. I could see this not fitting in with everybody's style but for me it has DRYed up the parts of a test that should be DRY (imho).
Hey guys, this is my first post to Timeless. judofyr and I are going to switch off Sundays from now on.
Overall, I feel pretty good about this, but commentary is always welcome. I'm still getting used to the nooks and crannies of MongoMapper, but I felt that leaving some awkward parts in was better than pretending that everything always goes perfectly when you're doing test-first development.
Overall, I feel pretty good about this, but commentary is always welcome. I'm still getting used to the nooks and crannies of MongoMapper, but I felt that leaving some awkward parts in was better than pretending that everything always goes perfectly when you're doing test-first development.