[rspec-users] Cucumber - step negating another expecting step

Mark Anderson manderson at drillinginfo.com
Mon Apr 20 17:18:43 EDT 2009


> > I've been doing something similar. I think the benefit of having half
> > the steps(each can be negated) wins over the small impact it has on step
> > readability. Personally I started adding stuff like this(perhaps not as
> > DRY but simple enough):
> >
> > Then /^the correspondence should (not )?have inclusions$/ do |negate|
> >   if negate
> >     @outcorr.inclusions.should be_empty
> >   else
> >     @outcorr.inclusions.should_not be_empty
> >   end
> > end
> 
> What's the advantage of having half the steps?
> They should be grouped in a nice way in files anyway.
> 
> This one's quite readable, though.

[snip]

> If you go with this kind of abstraction, this solution and the topmost
> in this mail at least do not introduce extra methods to deal with the
> should/should not. more methods to have fewer steps can not be an
> advantage,
> I think.
> 
> But the readbility of
> 
>   Then /^I should see the people search form$/ do
>     response.should have_tag('form#peopleSearch')
>   end
> 
>   Then /^I should not see the people search form$/ do
>     response.should_not have_tag('form#peopleSearch')
>   end
> 
> is higher for me, as I only need to think what the have_tag means,
> but do not have to parse the should/not, send, underscore and to_sym.
> 
> The difference in readability is from about 2 seconds to at least
> 10 seconds. That's a disadvantage that I'm not willing to pay for
> any advantage of having "fewer steps".

I use the first method for negating steps - when I need it.  The advantage
is DRY ("Don't Repeat Yourself").  While your method - having two separate
step matchers - may be a little easier to comprehend, my worry would be
maintainability.  If another user (perhaps just future-me) comes along and
adds another step matcher between those two without noticing that they
negate each other, and then a third user (perhaps future-future-me) comes
along and changes one step matcher but not the other, we no longer truly
have negation.

There is definitely a balancing act.  Hopefully future-me is less likely to
change one branch of my negating step matcher without mirroring the change
in the other half, it is even less likely in some of the one-line solutions
that are more difficult to quickly comprehend.

If you value comprehension and are confident that you'll remember to update
both cases together, then your solution is ideal.  If you value
idiot-proofing and don't mind slower comprehension, then a one-line solution
may be ideal.  I worry about everything and therefore take the middle of the
road solution.

					/\/\ark
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4022 (20090420) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 




More information about the rspec-users mailing list