rspec users - Nov 2008 - rake features and cucumber feature/name not producing same result

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

-- 
http://lindsaar.net/
Rails, RSpec and Life blog....
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081105/fa58aa5a/attachment.html>

On 5 Nov 2008, at 03:58, Mikel Lindsaar wrote:
> 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
What is the failure message you''re seeing?

Could it be this?
http://rspec.lighthouseapp.com/projects/16211/tickets/60-patch-next_column_index-not-resetting-after-large-tables

cheers,
Matt

On Wed, Nov 5, 2008 at 7:10 PM, Matt Wynne <matt at mattwynne.net> wrote:
> On 5 Nov 2008, at 03:58, Mikel Lindsaar wrote:
>
> 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?
>>
>
> What is the failure message you''re seeing?
>
> Could it be this?
>
>
http://rspec.lighthouseapp.com/projects/16211/tickets/60-patch-next_column_index-not-resetting-after-large-tables

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081106/74bf2d5e/attachment.html>

> 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
>
Are you running using Webrat or Selenium/Watir?

--
Joseph Wilk
http://www.joesniff.co.uk

On Thu, Nov 6, 2008 at 2:53 AM, Joseph Wilk <josephwilk at
joesniff.co.uk>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.

-- 
http://lindsaar.net/
Rails, RSpec and Life blog....
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081106/9e37ff80/attachment.html>

On Thu, Nov 6, 2008 at 11:28 PM, Joseph Wilk <josephwilk at
joesniff.co.uk>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


-- 
http://lindsaar.net/
Rails, RSpec and Life blog....
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081107/661e741e/attachment.html>