rspec users - May 2009 - cucumber - how to bootstrap outside of rails?

Setting up cucumber inside a Rails project is no more difficult than
running script/generate cucumber.  But what does one do when working
without Rails at all?  How do you generate the features tree and all of
its default files?
-- 
Posted via http://www.ruby-forum.com/.

I use mkdir and touch.

On May 1, 11:25?pm, James Byrne <li... at ruby-forum.com>
wrote:
> Setting up cucumber inside a Rails project is no more difficult than
> running script/generate cucumber. ?But what does one do when working
> without Rails at all? ?How do you generate the features tree and all of
> its default files?
> --
> Posted viahttp://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

> I use mkdir and touch.
>
Me too
> On May 1, 11:25 pm, James Byrne <li... at ruby-forum.com> wrote:
>> Setting up cucumber inside a Rails project is no more difficult than
>> running script/generate cucumber.  But what does one do when working
>> without Rails at all?  How do you generate the features tree and  
>> all of
>> its default files?
>> --
>> Posted viahttp://www.ruby-forum.com/.
>> _______________________________________________
>> rspec-users mailing list
>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/ 
>> rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Aslak Helles?y wrote:
>
>
>> I use mkdir and touch.
>>
>
> Me too
Yeah, "mkdir -p features/support && mkdir -p
features/step_defnintions
&& touch features/support/env.rb" is really all you need.

However, for new projects I really like to use jeweler to bootstrap all 
the setup for Cucumber, RSpec, Rakefiles, etc...  With jeweler you just 
say "jeweler cool_gem --cucumber --rspec" and all of this gets
generated
for you:
    create    .gitignore
    create    Rakefile
    create    LICENSE
    create    README.rdoc
    create    .document
    create    lib
    create    lib/cool_gem.rb
    create    spec
    create    spec/spec_helper.rb
    create    spec/cool_gem_spec.rb
    create    features
    create    features/cool_gem.feature
    create    features/support
    create    features/support/env.rb
    create    features/step_definitions
    create    features/step_definitions/cool_gem_steps.rb

Here is jewelers site:  http://technicalpickles.github.com/jeweler/


-Ben



>
>> On May 1, 11:25 pm, James Byrne <li... at ruby-forum.com> wrote:
>>> Setting up cucumber inside a Rails project is no more difficult
than
>>> running script/generate cucumber.  But what does one do when
working
>>> without Rails at all?  How do you generate the features tree and
all of
>>> its default files?
>>> -- 
>>> Posted viahttp://www.ruby-forum.com/.
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-us... at
rubyforge.orghttp://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

You know what''d be awesome?

If Cucumber scenarios were referential.

I mean, wouldn''t it be awesome if you could refer to them... so you  
could build on them...

So in a login.feature I''d define:

Scenario: logging in
Given that a default user exists
And I am on the login page
When I fill in "username" with "username"
And I fill in "password" with "password"
Then I should be logged in

And then in a different feature somewhere else, I could say:

another.feature

Scenario: make toast
Given Scenario "logging in"
Given I am on the exciting logged in page
Then I .... blah blah blah

and so on...

Julian.

Hi Julian,
You can do just that, the scenarios stack like that quite well, and it is
reasonable to call a step from another, but you should  have something like

Scenario: Logging In
Given there is a user
When I visit the login page
And I fill in username with .......
And I fill in passowrd with ........
Then I should be logged in as .......

Scenario: Visiting Account Page
Given I am logged in
When I visit the account page
Then I should see my account settings

... "Given I am logged in" you define to call in turn each of the step
matchers you wrote to satisfy the first scenario.

.. does that fit your expectations / workflow?


2009/5/2 Julian Leviston <julian at leviston.net>
> You know what''d be awesome?
>
> If Cucumber scenarios were referential.
>
> I mean, wouldn''t it be awesome if you could refer to them... so
you could
> build on them...
>
> So in a login.feature I''d define:
>
> Scenario: logging in
> Given that a default user exists
> And I am on the login page
> When I fill in "username" with "username"
> And I fill in "password" with "password"
> Then I should be logged in
>
> And then in a different feature somewhere else, I could say:
>
> another.feature
>
> Scenario: make toast
> Given Scenario "logging in"
> Given I am on the exciting logged in page
> Then I .... blah blah blah
>
> and so on...
>
> Julian.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20090502/1ed967b7/attachment.html>

Julian Leviston wrote:
> You know what''d be awesome?
>
> If Cucumber scenarios were referential.
>
> I mean, wouldn''t it be awesome if you could refer to them... so
you
> could build on them...
>
> So in a login.feature I''d define:
>
> Scenario: logging in
> Given that a default user exists
> And I am on the login page
> When I fill in "username" with "username"
> And I fill in "password" with "password"
> Then I should be logged in
>
> And then in a different feature somewhere else, I could say:
>
> another.feature
>
> Scenario: make toast
> Given Scenario "logging in"
> Given I am on the exciting logged in page
> Then I .... blah blah blah
>
> and so on...
>
> Julian.

Believe it or not, this exact feature did exist in Cucumber at one time 
but was deprecated and is now removed.  You can find a good explanation 
of the reasoning behind that decision and what are the better 
alternatives on Joseph''s blog:

http://blog.josephwilk.net/ruby/cucumber-waves-goodbye-to-givenscenario.html

-Ben

Fair enough.

The steps from step definitions one is the best approach for what I  
want, and it''s actually what am doing, but I do notice that
there''s a
lot of the time when I''m actually re-typing the same text (ie once in  
the explicit explanation of what it means to log in, and then once  
more in the step definitions to refer to that login procedure) when I  
do this approach. Re-typing the same stuff is pretty retarded, and  
never a good idea.

Hence... my interest in this feature :)

How about this... Whenever I refer to other steps from within my  
steps, they should be printed out on the output line... tabbed in a  
bit, like so:

Given I am logged in:
	Given a default user exists
	And I am on the login page
	And I fill in "username" with "username"
	And I fill in "password" with "password"
	Then I should be on the superduper page
Given...
When...
Then...

Then the option to turn this feature off or on on the command line.

That''d be bloody brilliant. Okay so maybe I should go fork it and do  
it :)

Julian.

On 03/05/2009, at 4:50 AM, Ben Mabey wrote:
> Julian Leviston wrote:
>> You know what''d be awesome?
>>
>> If Cucumber scenarios were referential.
>>
>> I mean, wouldn''t it be awesome if you could refer to them...
so you
>> could build on them...
>>
>> So in a login.feature I''d define:
>>
>> Scenario: logging in
>> Given that a default user exists
>> And I am on the login page
>> When I fill in "username" with "username"
>> And I fill in "password" with "password"
>> Then I should be logged in
>>
>> And then in a different feature somewhere else, I could say:
>>
>> another.feature
>>
>> Scenario: make toast
>> Given Scenario "logging in"
>> Given I am on the exciting logged in page
>> Then I .... blah blah blah
>>
>> and so on...
>>
>> Julian.
>
>
> Believe it or not, this exact feature did exist in Cucumber at one  
> time but was deprecated and is now removed.  You can find a good  
> explanation of the reasoning behind that decision and what are the  
> better alternatives on Joseph''s blog:
>
>
http://blog.josephwilk.net/ruby/cucumber-waves-goodbye-to-givenscenario.html
>
> -Ben
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Julian Leviston wrote:
> Fair enough.
>
> The steps from step definitions one is the best approach for what I 
> want, and it''s actually what am doing, but I do notice that
there''s a
> lot of the time when I''m actually re-typing the same text (ie once
in
> the explicit explanation of what it means to log in, and then once 
> more in the step definitions to refer to that login procedure) when I 
> do this approach. Re-typing the same stuff is pretty retarded, and 
> never a good idea.
>
> Hence... my interest in this feature :)
>
> How about this... Whenever I refer to other steps from within my 
> steps, they should be printed out on the output line... tabbed in a 
> bit, like so:
>
> Given I am logged in:
>     Given a default user exists
>     And I am on the login page
>     And I fill in "username" with "username"
>     And I fill in "password" with "password"
>     Then I should be on the superduper page
> Given...
> When...
> Then...
>
> Then the option to turn this feature off or on on the command line.
We would definitely want it as a feature you could turn on or off.  By 
default I think it should be off.  I think it adds a lot of noise to the 
feature output.  In most cases I don''t care what the exact steps of 
logging in are.  How I log in can change and it doesn''t really effect 
this scenario at all.  What is important is that you are logged in- not 
how you got there.  So this is probably not a feature I would personally 
use.  (Especially, given that I don''t use steps within steps a whole 
lot.)  That said it seems like a reasonable request... Any other 
opinions on the suggested feature?  Should we move the discussion to 
lighthouse?

-Ben
>
> That''d be bloody brilliant. Okay so maybe I should go fork it and
do
> it :)
>
> Julian.
>
> On 03/05/2009, at 4:50 AM, Ben Mabey wrote:
>
>> Julian Leviston wrote:
>>> You know what''d be awesome?
>>>
>>> If Cucumber scenarios were referential.
>>>
>>> I mean, wouldn''t it be awesome if you could refer to
them... so you
>>> could build on them...
>>>
>>> So in a login.feature I''d define:
>>>
>>> Scenario: logging in
>>> Given that a default user exists
>>> And I am on the login page
>>> When I fill in "username" with "username"
>>> And I fill in "password" with "password"
>>> Then I should be logged in
>>>
>>> And then in a different feature somewhere else, I could say:
>>>
>>> another.feature
>>>
>>> Scenario: make toast
>>> Given Scenario "logging in"
>>> Given I am on the exciting logged in page
>>> Then I .... blah blah blah
>>>
>>> and so on...
>>>
>>> Julian.
>>
>>
>> Believe it or not, this exact feature did exist in Cucumber at one 
>> time but was deprecated and is now removed.  You can find a good 
>> explanation of the reasoning behind that decision and what are the 
>> better alternatives on Joseph''s blog:
>>
>>
http://blog.josephwilk.net/ruby/cucumber-waves-goodbye-to-givenscenario.html
>>
>>
>> -Ben
>> _______________________________________________
>> 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 2 May 2009, at 23:33, Ben Mabey wrote:
> We would definitely want it as a feature you could turn on or off.   
> By default I think it should be off. I think it adds a lot of noise  
> to the feature output.  In most cases I don''t care what the exact
> steps of logging in are.  How I log in can change and it doesn''t  
> really effect this scenario at all.  What is important is that you  
> are logged in- not how you got there.  So this is probably not a  
> feature I would personally use.  (Especially, given that I don''t
use
> steps within steps a whole lot.)  That said it seems like a  
> reasonable request... Any other opinions on the suggested feature?   
> Should we move the discussion to lighthouse?
I think this could be a useful debugging feature, although less  
compelling since Cucumber started reporting failures in steps called  
from steps the same way as steps called in a feature file.  But  
sometimes it''s useful to see in finer detail what Cucumber is doing.

One thing I wrestle with frequently is making scenarios fail fast and  
transparently.  Assumptions about what exactly is going on creep in,  
and often, the step that reports failure is not the one that  
fundamentally caused it.  Anything to make that assumption-breaking  
easier would be valuable IMHO.

Ashley

-- 
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
http://aviewfromafar.net/
http://twitter.com/ashleymoran

Aslak Helles?y wrote:
>> I use mkdir and touch.
>>
> 
> Me too
Fine for those that know cucumber inside out.  A bit sparse for the rest 
of creation.

What I ended up doing was copying an example directory tree from the 
cucumber gem and deleting most of it.  It would be useful for non-Rails 
users of cucumber if cucumber itself had an option to copy a template 
directory tree from the gem into a project root. In other words:

$ cd project_root
$ tree
.
|-- bin
|-- doc
`-- lib
$
$ cucumber --initialize
$ tree
.
|-- Rakefile
|-- bin
|-- doc
|-- features
|   |-- sample.feature
|   |-- step_definitions
|   |   `-- sample_steps.rb
|   `-- support
|       |-- env.rb
|       `-- tag_count_formatter.rb
`-- lib
-- 
Posted via http://www.ruby-forum.com/.

Aslak Helles?y wrote:
> 
> You only need this to start:
> 
> +-features/
>   +-foo.feature
> 
I realize this.  I am not complaining. I just think that for a modest 
amount of effort cucumber could be made self starting for the large 
number of people who do not have any prior experience with either Rails 
or Cucumber and who probably do not know about jeweller and newgem.  I 
had no idea such things existed or were possible until I received 
replies to this thread.

I still recall the vast amounts of time it took me to get going with 
cucumber and BDD. And that was with the benefit of the Rails generators 
that at least set me up with a skeleton to work from.  I think it would 
be useful to offer non-Rails users a similar facility.

-- 
Posted via http://www.ruby-forum.com/.

Aslak Helles?y wrote:
> 
> Then that''s a case for better documentation - not more Cucumber 
> features.
> Feel free to create a separate Wiki page for "plain ruby"
projects that
> points the user to newgem and jeweler.
Actually, that was what I was doing when I first raised the question.
-- 
Posted via http://www.ruby-forum.com/.