[LRUG] Writing readable feature tests with RSpec

[Paul Battley]

On 30 July 2014 17:32, Sam Livingston-Gray <geeksam at gmail.com> wrote:
> You don't need to use @variables.  Okay, technically, you need to use *one*,
> but it can be something like @shared_state = {}, and then everything else
> can be more explicit about how it interacts with that shared state.  Making
> it a Hash allows you to use the marvelous Hash#fetch for exploding as soon
> as things aren't as you expect (e.g., step A sets @color = 'fff' and step E
> asks for @colour), rather than returning a nil that will *eventually*
> explode.  ("Nobody expects the Spanish Inqui...NoMethodError!  Our primary
> weapon is whiny nil!")

That's an excellent idea. I've already implemented it.

>> 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.
>
> Really?  That's far better than the gyrations RSpec originally went through
> to make the #should method available on literally everything in the system
> (and even then, it still didn't work everywhere).

To be clear, it's not the expect() part (that seems right and proper
and I'm glad they implemented it), but the "to be true" type of thing.
Intellectually, I know that a b c d is the same as a(b(c(d))), but it
doesn't feel idiomatic to me.

Paul