Forum: RSpec [Cucumber, Webrat] Unable to run 2 features in a row

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
059ed46172a087063ce26250e44c8627?d=identicon&s=25 Fernando Perez (fernando)
on 2009-01-18 00:46
Hi,

I have written 2 features that each have 1 scenario. When I execute each
feature separately with "rake features FEATURE=features/..." they each
pass, but when I do "rake features", the first feature passes, and the
second one fails.

In my Given steps, I populate the DB, and some Given steps are called by
both features. I can't call Given in only one feature and not the other,
because in such case, individually running each feature would fail. So I
have added a check, if the entry already exists, then I shall not create
a duplicate. But it still doesn't work.

How to get around this headache? Anyone already bumped into that?
059ed46172a087063ce26250e44c8627?d=identicon&s=25 Fernando Perez (fernando)
on 2009-01-18 01:07
Fernando Perez wrote:
> Hi,
>
> I have written 2 features that each have 1 scenario. When I execute each
> feature separately with "rake features FEATURE=features/..." they each
> pass, but when I do "rake features", the first feature passes, and the
> second one fails.
>
> In my Given steps, I populate the DB, and some Given steps are called by
> both features. I can't call Given in only one feature and not the other,
> because in such case, individually running each feature would fail. So I
> have added a check, if the entry already exists, then I shall not create
> a duplicate. But it still doesn't work.
>
> How to get around this headache? Anyone already bumped into that?

Okay I get it now. That was a nasty one:

Between each Scenario, the DB gets cleared, however when adding entries
to the DB, the object's id gets incremented (i.e: it won't reset to 1).
So you cannot do something like the following in your step files:
product.author_id = 1

The way to fix this problem is to instantiate the object as an instance
var:
@author = Author.create!

And then in the step definition you get its id using:
product.author_id = @author.id


It took me a few hours to figure out, and a lot of trial and error.

As I don't see any other way around, I guess it is a good idea to update
the following documentation page accordingly to explain in which case an
instance var is compulsory:
http://wiki.github.com/aslakhellesoy/cucumber/step...
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-01-18 02:05
(Received via mailing list)
On 18 Jan 2009, at 00:07, Fernando Perez wrote:

>>
>> How to get around this headache? Anyone already bumped into that?
>
> Okay I get it now. That was a nasty one:
>
> Between each Scenario, the DB gets cleared, however when adding
> entries
> to the DB, the object's id gets incremented (i.e: it won't reset to
> 1).
> So you cannot do something like the following in your step files:
> product.author_id = 1

Yes, hard-coding database identifiers anywhere is going to bite you
somewhere painful every single time.


>
> As I don't see any other way around, I guess it is a good idea to
> update
> the following documentation page accordingly to explain in which
> case an
> instance var is compulsory:
> http://wiki.github.com/aslakhellesoy/cucumber/step...


Not necessarily compulsory. You can also do this:

Given "The Book was written by the Author" do
   Product.count.should == 1
   the_product = Product.first
   Author.count.should == 1
   the_author = Author.first
   product.author_id = author.id
end

We have a convention on my team that as long as your step refers to to
*the* Widget, then
   * there should only be one Widget in the database at that moment
   * you can therefore assume that the feature is referring to that
one and only Widget


Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
This topic is locked and can not be replied to.