Forum: RSpec rake features and cucumber feature/name not producing same result

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.
Mikel L. (Guest)
on 2008-11-05 06:00
(Received via mailing list)
Hi all.
If I run rake features or cucumber features/* I get one failing FIT
scenario
in one of my features.

If I then run that feature that contains the FIT table with the failing
scenario manually, it passes.

I run it again with rake features or cucumber features/* it fails, run
individually, it passes.

Obviously some state is carrying over between the features.

Any idea where i would start looking to debug the problem?

Are features transactional?  Should I be investigating inter feature
state
contamination?

Mikel
Matt W. (Guest)
on 2008-11-05 10:27
(Received via mailing list)
On 5 Nov 2008, at 03:58, Mikel L. wrote:

>
> Obviously some state is carrying over between the features.
>
> Any idea where i would start looking to debug the problem?
>
> Are features transactional?  Should I be investigating inter feature
> state contamination?
>
> Mikel

What is the failure message you're seeing?

Could it be this?
http://rspec.lighthouseapp.com/projects/16211/tick...

cheers,
Matt
Mikel L. (Guest)
on 2008-11-05 17:46
(Received via mailing list)
On Wed, Nov 5, 2008 at 7:10 PM, Matt W. <removed_email_address@domain.invalid> 
wrote:

>> Are features transactional?  Should I be investigating inter feature state
>> contamination?
>>
>
> What is the failure message you're seeing?
>
> Could it be this?
>
> 
http://rspec.lighthouseapp.com/projects/16211/tick...


Alas no.

I'm getting expected: "1"
                         got: "0"

on a simple should change(Model, :count).by(1)

It follows the specific model around as well.  If I change order of the
fit
table or not (the fit table has 20 rows of different models all being
exercised the same way, they are part of a replication tool that copies
a
database).  The only time it passes is when I run the feature
independently.

I guess I'll have to look at what the difference is between ( rake
features
|| cucumber features/* ) and cucumber features/specific.feature and try and
hunt down what beginning state I could be missing.

Any other ideas?

Mikel
Joseph W. (Guest)
on 2008-11-05 18:03
(Received via mailing list)
>
> I guess I'll have to look at what the difference is between ( rake
> features || cucumber features/* ) and cucumber
> features/specific.feature and try and hunt down what beginning state I
> could be missing.
>
> Any other ideas?
>
> Mikel
>
Are you running using Webrat or Selenium/Watir?

--
Joseph W.
http://www.joesniff.co.uk
Mikel L. (Guest)
on 2008-11-06 00:55
(Received via mailing list)
On Thu, Nov 6, 2008 at 2:53 AM, Joseph W.
<removed_email_address@domain.invalid>wrote:

> I'm getting expected: "1"
>>                         got: "0"
>> on a simple should change(Model, :count).by(1)
>>
>> It follows the specific model around as well.  If I change order of the
>> fit table or not (the fit table has 20 rows of different models all being
>> exercised the same way, they are part of a replication tool that copies a
>> database).  The only time it passes is when I run the feature independently.
>>
>>  Are you running using Webrat or Selenium/Watir?


Yes!  Running webrat, latest trunk version (as of yesterday anyway).
Though
this feature doesn't use it specifically, webrat is loaded with a
require
line in the features/steps/env.rb file.
Mikel L. (Guest)
on 2008-11-08 00:19
(Received via mailing list)
On Thu, Nov 6, 2008 at 11:28 PM, Joseph W.
<removed_email_address@domain.invalid>wrote:

> If you are using cucumber with rails and used the rails generator  you
> should find in your generated features/steps/env.rb file (In the latest
> cucumber version 0.1.9 this is in features/support/env.rb):
>

Yes, I was already using the transactional fixtures.  This wasn't the
problem.

The final problem was actually two code bugs.  One on a trigger in the
database and the other was a namespace confliict in my code.

Those two combined basically had me totally confused :)

Mikel
This topic is locked and can not be replied to.