

BDD with RSpec and Steak (via a real example) - steveklabnik
http://timeless.judofyr.net/bdd-with-rspec-and-steak

======
nerdyworm
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.

~~~
sleight42
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._

------
ludicast
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:

    
    
      with_existing :user do
        that_has_an :article do
          that_has_a :comment do
    

or

    
    
      with_existing :user do
        on_visiting edit_user_path do
          it { should let_me_edit(@user) }
        end
      end
    

I'm obviously biased, but I think this sort of testing kicks ass. I initially
wrote them as extensions to Steak, but then ripped them out to use with
vanilla rspec.

~~~
sleight42
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.

~~~
ludicast
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).

------
steveklabnik
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.

