rspec users - Apr 2009 - Cucumber - step negating another expecting step

On 16 Apr 2009, at 11:22, Joaquin Rivera Padron wrote:
> at the moment I do it this way, hiding the complexity out of the  
> steps:
>
> Then /^I should see the people search form$/ do
>   people_search_form_exists
> end
>
> Then /^I should not see the people search form$/ do
>   people_search_form_exists "not"
> end
>
> and then the method:
>
> def people_search_form_exists negation = ""
>   neg = "_not" unless negation.blank?
>   response.send "should#{neg}".to_sym,
have_tag(''form#frmSearch'')
> end
>
> this is a simple case, but what do you think about this? any blog  
> post or so
Yeah this is an annoying one isn''t it. I sometimes get around it by  
going old-skool and pulling out the Test::Unit assertion methods  
instead:

     Then /^I (should|should not) see the people search form$/ do | 
maybe|
       has_matching_tags =
current_dom.css(''form#frmSearch'').length > 0
       assert has_matching_tags == (maybe == "should")
     end

I think that would work. It''s shorter, but is it much easier to  
understand?

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

On 16 Apr 2009, at 14:06, Joaquin Rivera Padron wrote:
> thanks matt,
> yes, the regexp in the step matcher is a good one to dry it up
>
> So I end up with this one:
>
> Then /^I (should|should not) see the people search form$/ do |maybe|
>   people_search_form_should_exist maybe == "should"
> end
>
> and the method:
>
> def people_search_form_should_exist it_should_exist
>   _not = "_not" unless it_should_exist
>
>   response.send "should#{_not}".to_sym,
have_tag(''form#frmSearch'')
> end
>
> only because I find it easier to read (when I don''t need to jump
to
> the method), but yours maybe faster (shorter it is), I could come  
> back to it later and benchmark both
If you don''t mind using the #send (I was trying to help you get rid of
it) then just do this:

Then /^I (should|should not) see the people search form$/ do |maybe|
   response.send maybe.underscore.to_sym,
have_tag(''form#frmSearch'')
end

> thanks again,
> joaquin
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

> 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.
>> yes, the regexp in the step matcher is a good one to dry it up
>>
>> So I end up with this one:
>>
>> Then /^I (should|should not) see the people search form$/ do |maybe|
>>  people_search_form_should_exist maybe == "should"
>> end
should ... exist ...  maybe... should

Unreadable?
>> and the method:
>>
>> def people_search_form_should_exist it_should_exist
>>  _not = "_not" unless it_should_exist
>>
>>  response.send "should#{_not}".to_sym,
have_tag(''form#frmSearch'')
>> end
Convoluted.
>> only because I find it easier to read (when I don''t need to
jump to
>> the method), but yours maybe faster (shorter it is), I could come back 
>> to it later and benchmark both
>>
>> If you don''t mind using the #send (I was trying to help you
get rid of
>> it) then just do this:
>>
>>
>> Then /^I (should|should not) see the people search form$/ do |maybe|
>>  response.send maybe.underscore.to_sym,
have_tag(''form#frmSearch'')
>> end
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".

Bye,
Kero.
___
How can I change the world if I can''t even change myself?
  -- Faithless, Salva Mea

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

On Thu, Apr 16, 2009 at 10:35 AM, Matt Wynne <matt at mattwynne.net>
wrote:
>
> On 16 Apr 2009, at 14:06, Joaquin Rivera Padron wrote:
>
>> thanks matt,
>> yes, the regexp in the step matcher is a good one to dry it up
>>
>> So I end up with this one:
>>
>> Then /^I (should|should not) see the people search form$/ do |maybe|
>> ?people_search_form_should_exist maybe == "should"
>> end
>>
>> and the method:
>>
>> def people_search_form_should_exist it_should_exist
>> ?_not = "_not" unless it_should_exist
>>
>> ?response.send "should#{_not}".to_sym,
have_tag(''form#frmSearch'')
>> end
>>
>> only because I find it easier to read (when I don''t need to
jump to the
>> method), but yours maybe faster (shorter it is), I could come back to
it
>> later and benchmark both
>
> If you don''t mind using the #send (I was trying to help you get
rid of it)
> then just do this:
>
> Then /^I (should|should not) see the people search form$/ do |maybe|
> ?response.send maybe.underscore.to_sym,
have_tag(''form#frmSearch'')
> end
I''m definitely on the "clarity trumps DRY" side of the fence
here. But
that doesn''t deny that there is a problem to solve. This solution gets
close but is still takes me some extra time to grok. What extracting
that to a method like this:

Then /^I (should|should not) see the people search form$/ do
|should_or_should_not|
  expect_that(response, should_or_should_not,
have_tag(''form#frmSearch''))
end

def expect_that(target, should_or_should_not, matcher)
  target.send should_or_should_not.underscore.to_sym, matcher
end

I definitely don''t see this in Cucumber, BTW as "should" and
"should
not" are not the only way to express positive and negative
expectations even in English, let alone other languages that might not
deal w/ negation in such clean and consistent ways.

And it''s not the least number of characters you can type. But
it''s
grok-able IMO. And DRY. And cute, to boot.

Of course, if anybody can come up with one word other than "maybe"
(damn you Ben Mabey for f''ing up my ability to type that word) to
express should_or_should_not more succinctly, that might help reduce
the typing. "Maybe" doesn''t work for me because it implies
lack of
precision rather than choice (to me).

Don''t know how helpful this is, but it''s fun to explore.

David
>
>
>> thanks again,
>> joaquin
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> Matt Wynne
> http://blog.mattwynne.net
> http://www.songkick.com
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

David Chelimsky wrote:
> On Thu, Apr 16, 2009 at 10:35 AM, Matt Wynne <matt at mattwynne.net>
wrote:
>   
>> On 16 Apr 2009, at 14:06, Joaquin Rivera Padron wrote:
>>
>>     
>>> thanks matt,
>>> yes, the regexp in the step matcher is a good one to dry it up
>>>
>>> So I end up with this one:
>>>
>>> Then /^I (should|should not) see the people search form$/ do
|maybe|
>>>  people_search_form_should_exist maybe == "should"
>>> end
>>>
>>> and the method:
>>>
>>> def people_search_form_should_exist it_should_exist
>>>  _not = "_not" unless it_should_exist
>>>
>>>  response.send "should#{_not}".to_sym,
have_tag(''form#frmSearch'')
>>> end
>>>
>>> only because I find it easier to read (when I don''t need
to jump to the
>>> method), but yours maybe faster (shorter it is), I could come back
to it
>>> later and benchmark both
>>>       
>> If you don''t mind using the #send (I was trying to help you
get rid of it)
>> then just do this:
>>
>> Then /^I (should|should not) see the people search form$/ do |maybe|
>>  response.send maybe.underscore.to_sym,
have_tag(''form#frmSearch'')
>> end
>>     
>
> I''m definitely on the "clarity trumps DRY" side of the
fence here. But
> that doesn''t deny that there is a problem to solve. This solution
gets
> close but is still takes me some extra time to grok. What extracting
> that to a method like this:
>
> Then /^I (should|should not) see the people search form$/ do
> |should_or_should_not|
>   expect_that(response, should_or_should_not,
have_tag(''form#frmSearch''))
> end
>
> def expect_that(target, should_or_should_not, matcher)
>   target.send should_or_should_not.underscore.to_sym, matcher
> end
>
> I definitely don''t see this in Cucumber, BTW as "should"
and "should
> not" are not the only way to express positive and negative
> expectations even in English, let alone other languages that might not
> deal w/ negation in such clean and consistent ways.
>
> And it''s not the least number of characters you can type. But
it''s
> grok-able IMO. And DRY. And cute, to boot.
>
> Of course, if anybody can come up with one word other than
"maybe"
> (damn you Ben Mabey for f''ing up my ability to type that word) to
>   
LOL... I seem to have that effect on people. :)  But, think how I feel.  
Do you know how many "witty" people I have met who tell some
"maybe"
joke and think they are the first person to ever make it?  Well, I can 
tell you that it does, in fact, get very old. :)
> express should_or_should_not more succinctly, that might help reduce
> the typing. "Maybe" doesn''t work for me because it
implies lack of
> precision rather than choice (to me).
>   
Back on topic...  I like this proposal the best.  Having the  
"should_or_should_not" makes it very clear what is happening.  To
reduce
typing I suppose you could call it "expectation" in the step 
definition... and you could possibly even abbrevaite that more.  But I 
wold probably stick with the more verbose "should_or_should_not".  I 
also agree that this is something that shouldn''t be part of Cucumber 
itself but I''ll probably play around with it in my own projects.

-Ben *Mabey*


> Don''t know how helpful this is, but it''s fun to explore.
>
> David
>
>   
>>     
>>> thanks again,
>>> joaquin
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>       
>> Matt Wynne
>> http://blog.mattwynne.net
>> http://www.songkick.com
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>     
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Thu, Apr 23, 2009 at 9:39 AM, Ben Mabey <ben at benmabey.com>
wrote:
> David Chelimsky wrote:
>>
>> On Thu, Apr 16, 2009 at 10:35 AM, Matt Wynne <matt at
mattwynne.net> wrote:
>>
>>>
>>> On 16 Apr 2009, at 14:06, Joaquin Rivera Padron wrote:
>>>
>>>
>>>>
>>>> thanks matt,
>>>> yes, the regexp in the step matcher is a good one to dry it up
>>>>
>>>> So I end up with this one:
>>>>
>>>> Then /^I (should|should not) see the people search form$/ do
|maybe|
>>>> ?people_search_form_should_exist maybe == "should"
>>>> end
>>>>
>>>> and the method:
>>>>
>>>> def people_search_form_should_exist it_should_exist
>>>> ?_not = "_not" unless it_should_exist
>>>>
>>>> ?response.send "should#{_not}".to_sym,
have_tag(''form#frmSearch'')
>>>> end
>>>>
>>>> only because I find it easier to read (when I don''t
need to jump to the
>>>> method), but yours maybe faster (shorter it is), I could come
back to it
>>>> later and benchmark both
>>>>
>>>
>>> If you don''t mind using the #send (I was trying to help
you get rid of
>>> it)
>>> then just do this:
>>>
>>> Then /^I (should|should not) see the people search form$/ do
|maybe|
>>> ?response.send maybe.underscore.to_sym,
have_tag(''form#frmSearch'')
>>> end
>>>
>>
>> I''m definitely on the "clarity trumps DRY" side of
the fence here. But
>> that doesn''t deny that there is a problem to solve. This
solution gets
>> close but is still takes me some extra time to grok. What extracting
>> that to a method like this:
>>
>> Then /^I (should|should not) see the people search form$/ do
>> |should_or_should_not|
>> ?expect_that(response, should_or_should_not,
have_tag(''form#frmSearch''))
>> end
>>
>> def expect_that(target, should_or_should_not, matcher)
>> ?target.send should_or_should_not.underscore.to_sym, matcher
>> end
>>
>> I definitely don''t see this in Cucumber, BTW as
"should" and "should
>> not" are not the only way to express positive and negative
>> expectations even in English, let alone other languages that might not
>> deal w/ negation in such clean and consistent ways.
>>
>> And it''s not the least number of characters you can type. But
it''s
>> grok-able IMO. And DRY. And cute, to boot.
>>
>> Of course, if anybody can come up with one word other than
"maybe"
>> (damn you Ben Mabey for f''ing up my ability to type that word)
to
>>
>
> LOL... I seem to have that effect on people. :) ?But, think how I feel. ?Do
> you know how many "witty" people I have met who tell some
"maybe" joke and
> think they are the first person to ever make it? ?Well, I can tell you that
> it does, in fact, get very old. :)
>>
>> express should_or_should_not more succinctly, that might help reduce
>> the typing. "Maybe" doesn''t work for me because it
implies lack of
>> precision rather than choice (to me).
>>
>
> Back on topic... ?I like this proposal the best. ?Having the
> ?"should_or_should_not" makes it very clear what is happening.
?To reduce
> typing I suppose you could call it "expectation" in the step
definition...
> and you could possibly even abbrevaite that more.
e9n ???
s18t ???
> But I wold probably stick
> with the more verbose "should_or_should_not". ?I also agree that
this is
> something that shouldn''t be part of Cucumber itself but
I''ll probably play
> around with it in my own projects.
>
> -Ben *Mabey*
>
>
>
>> Don''t know how helpful this is, but it''s fun to
explore.
>>
>> David
>>
>>
>>>
>>>
>>>>
>>>> thanks again,
>>>> joaquin
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>
>>>
>>> Matt Wynne
>>> http://blog.mattwynne.net
>>> http://www.songkick.com
>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>