David Chelimsky wrote:
On Thu, Apr 16, 2009 at 10:35 AM, Matt Wynne 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
On Thu, Apr 23, 2009 at 9:39 AM, Ben Mabey wrote:
> David Chelimsky wrote:
>>
>> On Thu, Apr 16, 2009 at 10:35 AM, Matt Wynne 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
On Thu, Apr 16, 2009 at 10:35 AM, Matt Wynne 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 |ma
>
> 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
>
> Frankly, I don't think I'll ever implement a cute feature in Cucumber that
>> allows you to have out of the box negation. It would be ugly no matter how
>> it's done, and it would only save you a line or 2 of code.
>>
>
> fwiw, +1 on that. refactor to a descriptive method and get used to
> ref
On Thu, Apr 23, 2009 at 1:53 AM, aslak hellesoy wrote:
>
>
> Frankly, I don't think I'll ever implement a cute feature in Cucumber that
> allows you to have out of the box negation. It would be ugly no matter how
> it's done, and it would only save you a line or 2 of code.
>
fwiw, +1 on that. re
On Thu, Apr 23, 2009 at 12:34 AM, Joaquin Rivera Padron
wrote:
> ok, let's say:
>
> Then /should see "(.+)"/ do |text|
># a binary step, easily negable
> end
>
> Then /I deny some steps/ do
> # really not so readable
> Not Then "should see \"your are not log in\""
>
> Then "some other st
ok, let's say:
Then /should see "(.+)"/ do |text|
# a binary step, easily negable
end
Then /I deny some steps/ do
# really not so readable
Not Then "should see \"your are not log in\""
Then "some other step that holds"
# another way of saying it bad
But Not Then "should receive inf
On Wed, Apr 22, 2009 at 3:51 PM, Jeff Talbot wrote:
>
> On Wed, Apr 22, 2009 at 1:17 AM, aslak hellesoy
> wrote:
>
>>
>>
>> 2009/4/17 Lenny Marks
>>
>>> 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 s
well, that was the vague idea I had when asking at first, but I don't think
every multi-should or should_not step can be in general negated,
by the way, Lenny's one have come to be my preferred solution
joaquin
___
rspec-users mailing list
rspec-users@r
On Wed, Apr 22, 2009 at 1:17 AM, aslak hellesoy wrote:
>
>
> 2009/4/17 Lenny Marks
>
>> 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(per
2009/4/17 Lenny Marks
> 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
> > 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 (no
> 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
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 inclusi
wow! even shorter :-)
2009/4/16 Matt Wynne
>
> 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|
>>
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 m
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
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
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 ne
hey there,
this here may be a little too general, and maybe is only a though sharing,
but would be nice to hear what you think.
What is your opinion about expectation steps that negates another
expectation step?
for example: let's say I have a step that specs something:
Then /^I should see the p
21 matches
Mail list logo
