Tim Walker wrote:
> FWIW - I just did it and it seemed OK...
>
> /features/steps/holiday_steps.rb
> ...
> Then /^there should be 2 nodes in the control group$/ do
> Fixtures.create_fixtures("/../../test/fixtures", "holiday_schedules")
> end
> ...
>
> /test/fixtures/holiday_schedules.yml
> one:
No arguments there! Just curious why it didn't work...
FWIW - I just did it and it seemed OK...
/features/steps/holiday_steps.rb
...
Then /^there should be 2 nodes in the control group$/ do
Fixtures.create_fixtures("/../../test/fixtures", "holiday_schedules")
end
...
/test/fixtures/holiday_sch
Fixtures = yuk!!
Try object_daddy or maybe factory_girl instead :)
Andrew
2008/11/26 Tim Walker <[EMAIL PROTECTED]>:
> Great post James. Very, helpful. Perhaps should be on the cucumber
> Wiki? I hope someone follows up on the load fixtures question. Lots to
> go play with now!!! Tim
>
> On Wed,
Great post James. Very, helpful. Perhaps should be on the cucumber
Wiki? I hope someone follows up on the load fixtures question. Lots to
go play with now!!! Tim
On Wed, Nov 26, 2008 at 11:04 AM, James Byrne <[EMAIL PROTECTED]> wrote:
> Tim Walker wrote:
>> Question: In Cucumber when you're writin
Tim Walker wrote:
> Question: In Cucumber when you're writing code to satisfy steps and
> accessing the model objects directly, what support for asserts,
> responses, etc.
> do people use. (the equivalent of ActionController::TestCase and
> ActiveSupport::TestCase), Fixtures, etc.
>
> Thanks,
>
On Tue, Nov 25, 2008 at 6:09 PM, Tim Walker <[EMAIL PROTECTED]> wrote:
> Since Cucumber is about BDD and defining the "acceptable and desired
> behavior" of the software through plain english (executable
> requirements if you will) it is not always clear what "level" the
> steps will implement.
>
>
Since Cucumber is about BDD and defining the "acceptable and desired
behavior" of the software through plain english (executable
requirements if you will) it is not always clear what "level" the
steps will implement.
In the case of Rails testing out of the box this maps roughly to:
1) unit tests -
James Byrne <[EMAIL PROTECTED]> writes:
> Ben Mabey wrote:
>
>> Right. Although, I'm unsure if rspec is even the default framework
>> outside of the rails generators.
>> -Ben
>
> Where can one get a handy quick reference of what syntax is acceptable
> to cucumber by default?
Ruby syntax is acce
On Tue, Nov 25, 2008 at 9:54 PM, James Byrne <[EMAIL PROTECTED]> wrote:
> Aslak Hellesøy wrote:
>
> >>
> >> Cucumber depends upon RSpec.
> >
> > No it doesn't
> >
> > Aslak
>
> Forgive my misapprehension.
Sorry - I should never email from my iPhone.
What I meant is that Cucumber itself does not
James Byrne wrote:
Ben Mabey wrote:
Right. Although, I'm unsure if rspec is even the default framework
outside of the rails generators.
-Ben
Where can one get a handy quick reference of what syntax is acceptable
to cucumber by default?
Hmm.. I'm not sure what you mean but the cu
Ben Mabey wrote:
> Right. Although, I'm unsure if rspec is even the default framework
> outside of the rails generators.
> -Ben
Where can one get a handy quick reference of what syntax is acceptable
to cucumber by default?
--
Posted via http://www.ruby-forum.com/.
_
James Byrne wrote:
James Byrne wrote:
But, if one wished to incorporate minitest say, then one
would extend the cucumber world
Where does one put this? A the begining of each step_definitions file?
In support/env.rb?
You only need it once- so the env.rb file is fine and natura
James Byrne wrote:
Ben Mabey wrote:
The previous gem releases of cucumber required the rspec gem but as of a
few commits ago that dependency is only there for developing cucumber.
-Ben
I see. So, if I understand correctly, rspec is the "default" testing
framework? But, if one wishe
James Byrne wrote:
> But, if one wished to incorporate minitest say, then one
> would extend the cucumber world
Where does one put this? A the begining of each step_definitions file?
In support/env.rb?
--
Posted via http://www.ruby-forum.com/.
___
Ben Mabey wrote:
>
> The previous gem releases of cucumber required the rspec gem but as of a
> few commits ago that dependency is only there for developing cucumber.
>
> -Ben
I see. So, if I understand correctly, rspec is the "default" testing
framework? But, if one wished to incorporate min
On Tue, Nov 25, 2008 at 4:06 PM, James Byrne <[EMAIL PROTECTED]> wrote:
> James Byrne wrote:
>> Aslak Hellesøy wrote:
>>
Cucumber depends upon RSpec.
>>>
>>> No it doesn't
>>>
>>> Aslak
>>
>> Forgive my misapprehension.
>
> So, where does one find a comprehensive list of expectations for
James Byrne wrote:
> Aslak Hellesøy wrote:
>
>>>
>>> Cucumber depends upon RSpec.
>>
>> No it doesn't
>>
>> Aslak
>
> Forgive my misapprehension.
However, this is what rdoc says:
cucumber 0.1.9 [rdoc] [www] - depends on diff-lcs, hoe, rspec,
term-ansicolor, treetop.
--
Posted via http://
Zach Dennis wrote:
On Tue, Nov 25, 2008 at 4:06 PM, James Byrne <[EMAIL PROTECTED]> wrote:
James Byrne wrote:
Aslak Hellesøy wrote:
Cucumber depends upon RSpec.
No it doesn't
Aslak
Forgive my misapprehension.
So, where does one find a comprehensiv
James Byrne wrote:
> Aslak Hellesøy wrote:
>
>>>
>>> Cucumber depends upon RSpec.
>>
>> No it doesn't
>>
>> Aslak
>
> Forgive my misapprehension.
So, where does one find a comprehensive list of expectations for
cucumber step matchers? Things like:
response.body.should +~ \pattern\
In my ig
Aslak Hellesøy wrote:
>>
>> Cucumber depends upon RSpec.
>
> No it doesn't
>
> Aslak
Forgive my misapprehension.
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rs
Tim Walker wrote:
Question: In Cucumber when you're writing code to satisfy steps and
accessing the model objects directly, what support for asserts,
responses, etc.
do people use. (the equivalent of ActionController::TestCase and
ActiveSupport::TestCase), Fixtures, etc.
Cucumber depends u
Tim Walker wrote:
> Question: In Cucumber when you're writing code to satisfy steps and
> accessing the model objects directly, what support for asserts, responses,
> etc.
> do people use. (the equivalent of ActionController::TestCase and
> ActiveSupport::TestCase), Fixtures, etc.
Cucumber depen
Question: In Cucumber when you're writing code to satisfy steps and accessing
the model objects directly, what support for asserts, responses, etc.
do people use. (the equivalent of ActionController::TestCase and
ActiveSupport::TestCase), Fixtures, etc.
Thanks,
T
On Tue, Nov 25, 2008 at 12:16 PM
On 25 Nov 2008, at 17:26, Ben Mabey wrote:
David Chelimsky wrote:
On Tue, Nov 25, 2008 at 12:52 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
Andrew Premdas wrote:
I came across this idea of dropping unit tests for acceptance
tests in
the java world. It didn't like it there and I don't like it
David Chelimsky wrote:
On Tue, Nov 25, 2008 at 12:52 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
Andrew Premdas wrote:
I came across this idea of dropping unit tests for acceptance tests in
the java world. It didn't like it there and I don't like it here, but
maybe thats because I'm an old
On Mon, Nov 24, 2008 at 8:34 PM, Raimond Garcia <[EMAIL PROTECTED]> wrote:
>> Wow, if that's it in a nutshell... :)
>>
>> Pat
>
> Thanks Pat, great summary.
>
> I have to admit that I'm as crazy as Yehuda,
> and believe that all we need are just acceptance tests,
> at different layers of abstractio
James Byrne wrote:
> As I work with Rails TestUnit tests I am reconsidering how to use
I discover that in Ruby 1.9 TestUnit is out and minitest is in. I
wonder what effect, if any, this will have on future releases of Rails.
http://www.ruby-forum.com/topic/171625
--
Posted via http://www.ruby-
On Tue, Nov 25, 2008 at 12:52 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
> Andrew Premdas wrote:
>>
>> I came across this idea of dropping unit tests for acceptance tests in
>> the java world. It didn't like it there and I don't like it here, but
>> maybe thats because I'm an old fuddy duddy or somet
Andrew Premdas wrote:
I came across this idea of dropping unit tests for acceptance tests in
the java world. It didn't like it there and I don't like it here, but
maybe thats because I'm an old fuddy duddy or something :). I do think
that every public method of an object should be specifically un
On Mon, Nov 24, 2008 at 1:18 PM, Mark Wilden <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 24, 2008 at 10:29 AM, Pat Maddox <[EMAIL PROTECTED]> wrote:
>>
>> I disagree with the part about edge cases. Acceptance Tests are about
>> defining and verifying business value, and edge cases are supremely
>> va
On Mon, Nov 24, 2008 at 9:41 PM, Pau Cor <[EMAIL PROTECTED]> wrote:
> I really understand what you are getting at. However, as I less
> experienced developer (my degree is actually in business) I have found
> that having more unit tests (for models and controllers) helps ensure
> that I write bett
I came across this idea of dropping unit tests for acceptance tests in
the java world. It didn't like it there and I don't like it here, but
maybe thats because I'm an old fuddy duddy or something :). I do think
that every public method of an object should be specifically unit
tested, and yes that
Pau Cor <[EMAIL PROTECTED]> writes:
> Pat Maddox wrote:
>> Here's my latest Theory of Testing, in a nutshell:
>
> I really understand what you are getting at. However, as I less
> experienced developer (my degree is actually in business) I have found
> that having more unit tests (for models and
Pat Maddox wrote:
> Here's my latest Theory of Testing, in a nutshell:
I really understand what you are getting at. However, as I less
experienced developer (my degree is actually in business) I have found
that having more unit tests (for models and controllers) helps ensure
that I write better
> Wow, if that's it in a nutshell... :)
>
> Pat
Thanks Pat, great summary.
I have to admit that I'm as crazy as Yehuda,
and believe that all we need are just acceptance tests,
at different layers of abstraction, for clients and developers.
I also see the benefits of speccing out single object's
On Mon, Nov 24, 2008 at 2:40 PM, Pat Maddox <[EMAIL PROTECTED]> wrote:
> Wow, if that's it in a nutshell... :)
>
Nice nut.
///ark
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Shane Mingins <[EMAIL PROTECTED]> writes:
> On 25/11/2008, at 7:29 AM, Pat Maddox wrote:
>>
>> Lately I've been putting more and more stuff into ATs. I'm finding it
>> valuable to keep tests for domain logic separate from plain ol unit
>> tests...meaning that my Account object may be tested mostl
On 25/11/2008, at 7:29 AM, Pat Maddox wrote:
Lately I've been putting more and more stuff into ATs. I'm finding it
valuable to keep tests for domain logic separate from plain ol unit
tests...meaning that my Account object may be tested mostly with
Cucumber, but helper objects such as a stats a
On Mon, Nov 24, 2008 at 1:07 PM, Pat Maddox <[EMAIL PROTECTED]> wrote:
> In my hypothetical example, the
> specification is what to do when someone withdraws more than they have
> in their account. Then when you write scenarios, the simplest thing you
> can do to show that is the edge case itsel
"Mark Wilden" <[EMAIL PROTECTED]> writes:
> On Mon, Nov 24, 2008 at 10:29 AM, Pat Maddox <[EMAIL PROTECTED]> wrote:
>
> I disagree with the part about edge cases. Acceptance Tests are about
> defining and verifying business value, and edge cases are supremely
> valuable to businesses.
On Mon, Nov 24, 2008 at 2:18 PM, Mark Wilden <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 24, 2008 at 10:29 AM, Pat Maddox <[EMAIL PROTECTED]> wrote:
>>
>> I disagree with the part about edge cases. Acceptance Tests are about
>> defining and verifying business value, and edge cases are supremely
>> va
Hi guys,
I'm having trouble figuring out where the line between writing a spec or
a feature is.
Since I started with rspec stories, I have the idea that stories where
just the evolution of specs.
My main reason for this was the re-usability of steps throughout
stories, which I think is great.
O
On Mon, Nov 24, 2008 at 10:29 AM, Pat Maddox <[EMAIL PROTECTED]> wrote:
>
> I disagree with the part about edge cases. Acceptance Tests are about
> defining and verifying business value, and edge cases are supremely
> valuable to businesses. What happens when an ATM user tries to withdraw
> $1 m
On 24 Nov 2008, at 18:29, Pat Maddox wrote:
Matt Wynne <[EMAIL PROTECTED]> writes:
On 21 Nov 2008, at 18:15, James Byrne wrote:
As I work with Rails TestUnit tests I am reconsidering how to use
cucumber features. It seems to me that it might be best to have a
coherent view of how to arrang
Matt Wynne <[EMAIL PROTECTED]> writes:
> On 21 Nov 2008, at 18:15, James Byrne wrote:
>
>> As I work with Rails TestUnit tests I am reconsidering how to use
>> cucumber features. It seems to me that it might be best to have a
>> coherent view of how to arrange my test suites before I get much
>>
James Byrne wrote:
> into this. Now, so far I have considered three possibilities:
Ok, five...
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
On 21 Nov 2008, at 18:15, James Byrne wrote:
As I work with Rails TestUnit tests I am reconsidering how to use
cucumber features. It seems to me that it might be best to have a
coherent view of how to arrange my test suites before I get much
further
into this. Now, so far I have considered
Its tempting to see features as a kind of extended test tool, I
certainly looked at them in that way initially. However I think this
isn't really the most profitable way to look at them, nor how they
were designed. It would probably be worthwhile if you looked up some
articles on BDD, and perhaps p
As I work with Rails TestUnit tests I am reconsidering how to use
cucumber features. It seems to me that it might be best to have a
coherent view of how to arrange my test suites before I get much further
into this. Now, so far I have considered three possibilities:
1. Use features exclusively.
49 matches
Mail list logo
