[LRUG] Writing readable feature tests with RSpec

Paul Battley pbattley at gmail.com
Wed Jul 30 07:51:52 PDT 2014


I've just had a go at doing this on a couple of gnarly RSpec feature
files that were doing a poor job of justifying themselves. It's made
them clearer whilst being an easier (and less controversial!)
transition than moving them straight to Cucumber.

So far, I really like being able to put everything in the same file,
especially as a starting step: it makes it really easy to extract the
bits into explanatory methods and to see duplication within that file.
It also frees me from having to think about duplication across
features. I might change my mind here, but that seems nice. State
within one feature feels a lot easier to deal with than hidden state
in @variables across different definition files. It makes me wonder
if, when using Cucumber, I'd be happier if steps were feature-specific
by default. (Is that a thing that can be achieved in Cucumber?)

I found myself ordering steps so that I could reuse them without
aliasing them to deal with given/and then/and when/and, which feels
like a bad motivation. That led me to think that perhaps I could
create no-op given/when/then/and methods (i.e. given_i_do_something ->
given i_do_something) - except, of course, that all but one of those
is a reserved word in Ruby. given_/when_/then_/and_, perhaps? Or
precondition/action/outcome? That feels like a step along the
dangerous path to precedence hacks and pseudo-English Ruby - I already
feel that RSpec is a bit too far that way, and every time I see
something like "expect(foo).to be true" I'm a little surprised that it
works.

So far, though, it seems like a useful discipline for cleaning up
complicated features. It might even be a good step towards moving them
to Cucumber, but for now it lets me defer that bikeshed-in-a-minefield
for another day.

Paul.



More information about the Chat mailing list