[LRUG] Writing readable feature tests with RSpec

[Tom Stuart]

On 28 Jul 2014, at 14:26, Graham Ashton <graham at effectif.com> wrote:
> Why did so many bright people, for whom I have a lot of respect, continue to use and promote Cucumber, while I found it to be an utter waste of time (and therefore money)?
> 
> Maybe scenarios gave them confidence that they were solving the right problem, a feeling that they’d otherwise been missing?
> 
> I do my “discovery" long before I get near an editor. I sit down with stakeholders, sketch things on paper, ask lots of questions and do everything I can to find out where their expectations don’t tally with mine. Then I write story cards (not in the limiting “As a potato...” form - in proper English, like a grown up) that describe *why* we’re building what we’re building. I if I can’t explain the why, I haven’t asked enough questions.

A meta-point: this is one of the things that frustrates me about conversations on these topics.

People who are sceptical about X (RSpec, Cucumber, TDD generally, Ruby, etc) will say “I don’t know what’s going on with these X people. I just do the eminently sensible thing Y, and that works for me” — the implication being that the people in question are doing themselves and their clients a disservice by using the inferior X as an ersatz substitute for the superior Y.

It invariably then turns out that everybody already agrees that Y is good and (hopefully) is already doing it anyway, and the people doing X are just using it as some kind of multiplier on Y, so no real understanding is transferred in either direction.

To take this email as an example: “I do discovery with stakeholders, on paper, away from the computer”. Me too! That bit’s really important! And then when I’ve done that, I find it useful to take what I’ve learned and write it down again in a more formal way so that it can be seen by the computer and by other developers. Writing it down again is useful. The computer can automatically check what I’ve written as part of a continuous integration process. Other developers can check what I’ve written and quickly understand what’s actually important about the software (the “why”) rather than the details of its operation (the “what”). It takes time to write it down again, but the benefits outweigh the costs.

Another common example: “I actually think about a problem before I write code”. Me too! That bit’s really important! And then when I’ve thought about it, I find it useful to take those thoughts and write them down in a more formal way so that they can be seen by the computer and by other developers. Writing them down is useful. It frees me from the cognitive load of holding all my implementation decisions in my head at once. It gives me a simple and repeatable way to make safe, incremental, hand-over-hand progress by “locking in” the easy parts of the solution and pushing gradually outward to the more difficult parts. It gives me proper concrete feedback on whether the design that seemed good in my head is actually sensible when transferred to a computer. It makes it dramatically easier to understand my earlier thought process when I come back to it later. It takes time to write these thoughts down, but the benefits outweigh the costs.

And so on.

I don’t have a solution to this; I don’t expect my descriptions of the above techniques to convince anyone who doesn’t already believe they’re useful. But I wanted to acknowledge the problem even if I don’t yet have a way to write its solution down.

Cheers,
-Tom