> (on a aside note: what would examples look like if both ideas get
> implemented? I'm afraid it'll be confusing.)
>
> > > I agree that in defining the rules that define the behaviour those
> > > situations are equivalent.
> > >
> > > However, as the examples _are the tests_ we need both as we need
My initial approach to this (when I hit it in my work) was to get around
this problem by catching the whole row from the example in the
Before(scenario) filter, putting it into a well known member @data, so all
steps have access to it.
The problem with this is that it is then implicit which fields
Hi Kero..
I agree that in defining the rules that define the behaviour those
situations are equivalent.
However, as the examples _are the tests_ we need both as we need to test
both those scenarios so the testers have confidence the feature is working
in all situations.
It's being a really good
sorry.. the first point.. you're right this feature is to do with tables
too, however this feature is orthogonal to the other one, so I decided to
start a new thread ... I hope that was right.
Cheers
Nigel
2009/4/23 Nigel Thorne
> Hi Kero..
>
> I agree that in defining the rul
In Cucumber I want to remove duplication from my examples tables.
see http://gist.github.com/99516 for an example of the type of situation I
am facing.
I would like the second example to be equivalent to the first.
To do this... I need cucumber to read a row in the examples and notice the
'option
Here is the same thing as a gist http://gist.github.com/99443
2009/4/22 Nigel Thorne
> I would prefer it to be explicit what columns I am using, that way if you
> have two steps that require this technique in your scenario it still
> works.Relying
> on an implicit 'the rest
I would prefer it to be explicit what columns I am using, that way if you
have two steps that require this technique in your scenario it still
works.Relying
on an implicit 'the rest' doesn't work in that situation.
In my scenario I would like to have something like this..
Given I am logged in as
that superfluous to requirements, there? I think so.
> You've already specified three calls in order, so that should cover it.
>
> 2009/4/14 Nigel Thorne
>
>> Hi Folks,
>>
>> I want to assert on an order of interaction between two objects where one
>> method g
Hi Folks,
I want to assert on an order of interaction between two objects where one
method gets repeated.
Here is a simple example...
# this fails "Mock 'x' expected :a with (any args) once, but received it twice"
x = mock("x")
x.should_receive(:a).once.ordered
x.should_receive(:b).once.ordered
Hi Folks,
I want to assert on an order of interaction between two objects where one
method gets repeated.
Here is a simple example...
# this fails "Mock 'x' expected :a with (any args) once, but received it twice"
x = mock("x")
x.should_receive(:a).once.ordered
x.should_receive(:b).once.ordered
Hi Barun,
Here is my take on this...
Why are you mocking methods on the object under test? The aim of BDD is to
specify the behaviour of the class. When you are mocking, the intention is
to spec one object in isolation. When you define expectations between
objects you are specifying object interac
I'm starting one of these too... I'll github it when I'm happy with my
approach.
2009/4/8 Ben Mabey
> David Chelimsky wrote:
>
>> On Tue, Apr 7, 2009 at 3:26 PM, Sophie (itsme213)
>> wrote:
>>
>>
>>> Some time ago I had come across a web-based story editor for scenarios.
>>> I'm
>>> not sure if
That is exactly what I was looking for.. Thank you !
2009/3/21 Tim Walker :
> We're accessing it like this
>
> Before do |scenario|
> puts "Before Scenario: #{scenario.to_sexp[3]}"
> .
> .
> .
> end
>
> HTH,
>
> Tim
>
> On Thu,
Where in the scenario object is the name stored?
Cheers.
Nigel
walketim wrote:
>
> That did the trick. Thanks Aslak! Took a little while to figure out
> where it was in the Scenario object but it was pretty straight forward
> from there.
>
> T
>
> On Wed, Mar 11, 2009 at 10:21 AM, aslak he
14 matches
Mail list logo
