> >> Cucumber could dump in the table data it found from the file, and
> >> print it out when running the scenarios, and it allows some sets of
> >> sample data be re-used easily, in an understandable manner.
If the file is used to unclutter the examples, does printing-when-running
help?
> > This
On 9 Apr 2009, at 20:36, Zach Dennis wrote:
On Thu, Apr 9, 2009 at 3:30 PM, Zach Dennis
wrote:
On Thu, Apr 9, 2009 at 2:56 PM, Matt Wynne
wrote:
On 9 Apr 2009, at 17:47, Zach Dennis wrote:
On Thu, Apr 9, 2009 at 9:29 AM, Williams, Wesley
wrote:
Matt,
Hmm, I think this is one way to
On 9 Apr 2009, at 17:47, Zach Dennis wrote:
On Thu, Apr 9, 2009 at 9:29 AM, Williams, Wesley
wrote:
Matt,
Hmm, I think this is one way to do it. I will need to get my
customer
to think differently about defining the requirements. They really
like
the tables.
Some times table just wo
On Thu, Apr 9, 2009 at 3:30 PM, Zach Dennis wrote:
> On Thu, Apr 9, 2009 at 2:56 PM, Matt Wynne wrote:
>>
>> On 9 Apr 2009, at 17:47, Zach Dennis wrote:
>>
>>> On Thu, Apr 9, 2009 at 9:29 AM, Williams, Wesley
>>> wrote:
Matt,
Hmm, I think this is one way to do it. I will nee
On Thu, Apr 9, 2009 at 2:56 PM, Matt Wynne wrote:
>
> On 9 Apr 2009, at 17:47, Zach Dennis wrote:
>
>> On Thu, Apr 9, 2009 at 9:29 AM, Williams, Wesley
>> wrote:
>>>
>>> Matt,
>>>
>>> Hmm, I think this is one way to do it. I will need to get my customer
>>> to think differently about defining th
riginal Message-
> From: rspec-users-boun...@rubyforge.org
> [mailto:rspec-users-boun...@rubyforge.org] On Behalf Of Matt Wynne
> Sent: Thursday, April 09, 2009 9:58 AM
> To: rspec-users
> Subject: Re: [rspec-users] Reuse of Cucumber Features
>
> On 8 Apr 2009, at 10:31, Williams, Wesle
Matt Wynne
Sent: Thursday, April 09, 2009 9:58 AM
To: rspec-users
Subject: Re: [rspec-users] Reuse of Cucumber Features
On 8 Apr 2009, at 10:31, Williams, Wesley wrote:
> All,
>
> I know this is an older post but I have a similar but different set
> of scenarios I need to handle.
e.
Wes
From: rspec-users-boun...@rubyforge.org
[mailto:rspec-users-boun...@rubyforge.org] On Behalf Of Rick DeNatale
Sent: Thursday, April 09, 2009 3:19 PM
To: rspec-users
Subject: Re: [rspec-users] Reuse of Cucumber Features
On Thu, Apr 9, 2009 at 3:57 AM, Matt Wynne wrote:
Anot
[mailto:rspec-users-boun...@rubyforge.org] On Behalf Of Matthew Krom
Sent: Thursday, April 09, 2009 2:44 PM
To: rspec-users
Subject: Re: [rspec-users] Reuse of Cucumber Features
Two other brainstorms:
Brainstorm 1:
Given an empty flights database
And aircraft XX1 flight number
On Thu, Apr 9, 2009 at 3:57 AM, Matt Wynne wrote:
>
>
> Another way to remove duplication (and noise) from Cucumber steps is the
> hide the details in the Ruby code that implements the step, and write a much
> more general step in the feature file like this:
>
>Given there are 3 flights de
Two other brainstorms:
Brainstorm 1:
Given an empty flights database
And aircraft XX1 flight number XX0001 departs on 03Mar2009 at 1000
And aircraft XX1 flight number XX0002 departs on 03Mar2009 at 1400
And aircraft XX1 flight number XX0003 departs on 03Mar2009 at 2100
lever about it,
these 'declarative' steps can still be pretty re-usable.
HTH,
Matt
Subject: [rspec-users] Reuse of Cucumber Features
+lots :)
Generally when we have problems with features its because we are
trying to
do to much at once. So in your case date entry is being
: [rspec-users] Reuse of Cucumber Features
+lots :)
Generally when we have problems with features its because we are trying
to
do to much at once. So in your case date entry is being complicated by
different contexts, birth and incident. One of the tennents of BDD is to
write the simplest thing
+lots :)
Generally when we have problems with features its because we are trying to
do to much at once. So in your case date entry is being complicated by
different contexts, birth and incident. One of the tennents of BDD is to
write the simplest thing you can to make you feature pass. I think ano
Hi Steve,
I likely would only write two scenarios, one for a valid date and one
for an invalid one. Then I would write object-level specs to determine
what a valid date is. Extract this to a validator that you can reuse
throughout your model.
If it's important that you write features for each p
Thanks -- that gets me closer. Here's an example. Let's say I have two
features, 'Create new patient' and 'Create new incident'. To create a new
patient you have to enter a valid birth date. To create a new patient you
must enter a valid birth date. To create a new incident you must enter a
va
On 13 Dec 2008, at 20:58, Steve Molitor wrote:
What's the best way to handle a requirement that shows up as a sub-
requirement requirement in other features? For example let's say
users can enter dates in various forms throughout my application.
There is one set of global rules specifyin
What's the best way to handle a requirement that shows up as a
sub-requirement requirement in other features? For example let's say users
can enter dates in various forms throughout my application. There is one
set of global rules specifying the formats in which dates may be entered,
and how the
18 matches
Mail list logo
