On Wed, Nov 5, 2008 at 7:10 PM, Matt Wynne <[EMAIL PROTECTED]> 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
_______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
