tags not working with cucumber :)

[Bharat]

The tags are not working for me in cucumber. I have installed the
following gems related to cucumber:

webrat (0.7.1)
will_paginate (2.3.14)

bruparel:~/rr_work/railzor
→ gem list | grep cucumber
cucumber (0.8.3)
cucumber-rails (0.3.2)

Any scenario that I tag just causes cucumber to not work at all. Here
is an example:

@wip
Scenario: View the calendar
When I go to the home page
Then the calendar should show the current month
And the page should link to /\/journal_entries\/\d{4}-\d{2}-\d{2}/

when I run the following command, see the output:

→ ruby script/cucumber --tags @wip
Using the default profile...
/home/bruparel/rr_work/railzor/config/../vendor/rails/railties/lib/
rails/gem_dependency.rb:119:Warning:
Gem::Dependency#version_requirements is deprecated and will be removed
on or after August 2010. Use #requirement


0 scenarios
0 steps
0m0.000s


What is interesting is that if I negate the tag condition, then it
works fine as shown below:

→ ruby script/cucumber --tags ~@wip
Using the default profile...
/home/bruparel/rr_work/railzor/config/../vendor/rails/railties/lib/
rails/gem_dependency.rb:119:Warning:
Gem::Dependency#version_requirements is deprecated and will be removed
on or after August 2010. Use #requirement
..F.........

(::) failed steps (::)

Can't find mapping from "a journal entry page" to a path.
Now, go and add a mapping in /home/bruparel/rr_work/railzor/features/
support/paths.rb (RuntimeError)
./features/support/paths.rb:33:in `path_to'
./features/step_definitions/web_steps.rb:20:in `/^(?:|I )go to (.+)$/'
features/journal_entries.feature:16:in `When I go to a journal entry
page'

Failing Scenarios:
cucumber features/journal_entries.feature:15 # Scenario: View a single
entry

3 scenarios (1 failed, 2 passed)
11 steps (1 failed, 10 passed)
0m0.548s

Please advise.

This happens both in MRI and JRuby

Bharat

[Bharat]

Interestingly the rake commands work with built in switches, i.e.

rake cucumber:wip
and
rake cucumber:ok

work as expected.

Bharat

[E. Litwin]

The default profile (see config/cucumber.yml) does not run anything
with the @wip tag. (std_opts is set to --tags ~@wip)

If you run it like this: cucumber -p wip, it will only run the @wip
tags.

[Bharat]

Thanks for your response. Here is what I see when I run cucumber -p
wip:

Feature: Authentication
In order to keep a journal of my shaving activities
As one who shaves
I want to create and use an account on the website.

@wip
Scenario: Signup (Refactored) # features/
authentication.feature:7
Given I am on the signup page # features/
step_definitions/web_steps.rb:15
When I fill in the following: # features/
step_definitions/web_steps.rb:54
| Login | Bertram |
| Email | ber...@example.com |
| Password | 123456 |
| Confirm Password | 123456 |
And I press "Sign up" # features/
step_definitions/web_steps.rb:23
Then I should see "Thanks for signing up" # features/
step_definitions/web_steps.rb:143

1 scenario (1 passed)
4 steps (4 passed)
0m0.238

The --wip switch was used, so I didn't expect anything to pass. These
scenarios passed:
(::) passed scenarios (::)

features/authentication.feature:7:in `Scenario: Signup (Refactored)'

As you can see:
1. I have marked a scenario with @wip tag to isolate its execution
2. Cucumber correctly runs only the marked scenario
3. However, it is the bottom three lines which don't make sense to
me:

The --wip switch was used, so I didn't expect anything to pass. These
scenarios passed:
(::) passed scenarios (::)

It seems like @wip behavior is hard-wired in cucumber?

Bharat

features/authentication.feature:7:in `Scenario: Signup (Refactored)'

[aslak hellesoy]

Cucumber doesn't give special meaning to any tags, and no such
behaviour is hard-wired.

Cucumber-Rails sets up Rake tasks for you in liv/tasks/cucumber.rake
and config/cucumber.yml. They use the @wip tag. You can modify this if
you want different behaviour.

Aslak

> Bharat
>
> features/authentication.feature:7:in `Scenario: Signup (Refactored)'
>

> --
> You received this message because you are subscribed to the Google Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
>
>

[Matt Wynne]

Another thought which I may have just missed in the features: what happens if cli options and code options conflict? Who wins? Seems to me cli should overide code

[aslak hellesoy]

On Sun, Jul 11, 2010 at 7:21 PM, Matt Wynne <ma...@mattwynne.net> wrote:
> Another thought which I may have just missed in the features: what happens if cli options and code options conflict? Who wins? Seems to me cli should overide code
>

Can you give an example Matt? I don't understand what you mean.

Aslak

[Bharat]

Hello Aslak,
Thanks for your response. Perhaps I did not articulate my question
clearly. What I am finding is that no matter which tag is use and try
to run the scenario that I mark with the tag, it will not work. It
simply does not run ANY scenarios. So I googled around and found the
info. on @wip tag. So I started to use it. Off course, it has a
special meaning in the way cucumber sets up its scripts and therefore
will alert you that what you think is work-in-process is closer to the
finished product. I would love to use my own tags as I could in the
earlier version of cucumber 0.4.4 I believe, but that feature does not
work in the current version of cucumber for me. Perhaps I may not
have the right settings, but I am unable to tweak it to work.
Bharat

[Matt Wynne]

On 11 Jul 2010, at 18:50, aslak hellesoy wrote:

> On Sun, Jul 11, 2010 at 7:21 PM, Matt Wynne <ma...@mattwynne.net> wrote:
>> Another thought which I may have just missed in the features: what happens if cli options and code options conflict? Who wins? Seems to me cli should overide code
>>
>
> Can you give an example Matt? I don't understand what you mean.
>
> Aslak

Sorry, wrong thread. Phone/email fail. Ignore me.

cheers,
Matt

Software Quality Coaching
http://blog.mattwynne.net
+44(0)7974 430184

[nruth]

I think E Litwin figured this out above: when you do cucumber --tags
@wip it's also using the default profile, so you end up with both --
tags @wip (from your args) and --tags ~wip (from the default
cucumber.yml profile) so nothing runs.

Have you tried changing the cucumber.yml profiles?

Also have you considered changing your @wip tag to another word?
It may be easier going forward than fighting the defaults each time
you upgrade cucumber and run script/generate cucumber.
Also the default behaviour is quite useful if you get used to it.

Or is it not just @wip that's causing issues?

On Jul 12, 1:14 pm, Matt Wynne <m...@mattwynne.net> wrote:
> On 11 Jul 2010, at 18:50, aslak hellesoy wrote:
>

> > On Sun, Jul 11, 2010 at 7:21 PM, Matt Wynne <m...@mattwynne.net> wrote:
> >> Another thought which I may have just missed in the features: what happens if cli options and code options conflict? Who wins? Seems to me cli should overide code
>
> > Can you give an example Matt? I don't understand what you mean.
>
> > Aslak
>
> Sorry, wrong thread. Phone/email fail. Ignore me.
>
>
>
>
>
>
>

> >> aslak hellesoy <aslak.helle...@gmail.com> wrote:

>
> >>> On Sun, Jul 11, 2010 at 4:23 PM, Bharat <bcrupa...@yahoo.com> wrote:
> >>>> Thanks for your response.  Here is what I see when I run cucumber -p
> >>>> wip:
>
> >>>> Feature: Authentication
> >>>>  In order to keep a journal of my shaving activities
> >>>>  As one who shaves
> >>>>  I want to create and use an account on the website.
>
> >>>>  @wip
> >>>>  Scenario: Signup (Refactored)               # features/
> >>>> authentication.feature:7
> >>>>    Given I am on the signup page             # features/
> >>>> step_definitions/web_steps.rb:15
> >>>>    When I fill in the following:             # features/
> >>>> step_definitions/web_steps.rb:54
> >>>>      | Login            | Bertram             |

> >>>>      | Email            | bert...@example.com |

> >>>> For more options, visit this group athttp://groups.google.com/group/cukes?hl=en.

>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups "Cukes" group.
> >>> To post to this group, send email to cu...@googlegroups.com.
> >>> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.

> >>> For more options, visit this group athttp://groups.google.com/group/cukes?hl=en.

>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Cukes" group.
> >> To post to this group, send email to cu...@googlegroups.com.
> >> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/cukes?hl=en.

>
> > --
> > You received this message because you are subscribed to the Google Groups "Cukes" group.
> > To post to this group, send email to cu...@googlegroups.com.
> > To unsubscribe from this group, send email to cukes+un...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/cukes?hl=en.

[byrnejb]

Just a WAG, but you do not happen to have an old cucumber.yml file
lying about in your project's root directory perchance? If so, what
happens if you remove it and then run cucumber?

[Bharat]

Thanks for your response byrnejb. Here is the cucumber.yml file in
the config directory of my project:

<%
rerun = File.file?('rerun.txt') ? IO.read('rerun.txt') : ""
rerun_opts = rerun.to_s.strip.empty? ? "--format
#{ENV['CUCUMBER_FORMAT'] || 'progress'} features" : "--format
#{ENV['CUCUMBER_FORMAT'] || 'pretty'} #{rerun}"
std_opts = "--format #{ENV['CUCUMBER_FORMAT'] || 'progress'} --strict
--tags ~@wip"
%>
default: <%= std_opts %> features
wip: --tags @wip:3 --wip features
rerun: <%= rerun_opts %> --format rerun --out rerun.txt --strict --
tags ~@wip

Is this the cause of this problem?

Bharat

[Bharat]

Byrnejb,
Thanks for your suggestion. I tried another cucumber.yml which came
with peepcode screencast and it worked fine. So it was the
cucumber.yml shown above that was the culprit.
Bharat

[byrnejb]

Well, I do not really think that the cucumber.yml file that you
removed is the actual source of the problem. I am glad that changing
things about seems to have resolved your immediate problem but I have
concerns that this is more an incidental artifact of the change and
not a resolution of the problem. I would like to see a few things if
you can provide them.

First, could you post the contents of the new cucumber.yml that
removes the symptoms? Second, using the config/cucumber.yml
distributed with cucumber-rails could you provide the exact command
line invocation and console output that exhibits the problem? Last,
could you also run the tree utility in your project's root directory
passing features as the target (# tree features) and provide the
output?

[Bharat]

Hello byrnejb,
Here is the cucumber.yml that works fine. I will do the rest when I
get home from work this evening, can't spend too much time playing
with my Ruby toys at my day job.

<%
rerun = File.file?('rerun.txt') ? IO.read('rerun.txt') : ""

rerun_opts = rerun.to_s.strip.empty? ? "--format progress features" :

"--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} #{rerun}"

std_opts = "#{rerun_opts} --format rerun --out rerun.txt --strict --
tags ~@wip"
%>
default: --format pretty --color

wip: --tags @wip:3 --wip features

This comes from the excellent peepcode screencast.

I am not sure where the problem lies though.
Thanks.
Bharat

[Bharat]

Hello Byrnejb,
I do not understand it. The bad cucumber file is working good too
now! I swear that it was misbehaving before. My apologies for
putting the group through this wild goose chase. All I have is a lame
excuse that it was not working before. Teaches me not to work to the
point where I may not be thinking straight and come back at something
after rest.
Thank you for your time and patience.
Bharat

[Mike Sassak]

The culprit is almost certainly a stray rerun.txt file. You're not the
first to get bitten by it--not by a long shot--so don't worry about
that. You're definitely not going crazy. I'm a bit confused why the
new version of cucumber-rails (that generated the "bad" cucumber.yml)
was still picking up rerun.txt by default, though. Did you ever run
the plain cucumber command from the root of your app, or did you only
see the error when using "ruby script/cucumber"?

Mike

> Bharat