regular expression too big error, seems to be related to predicate method, but may have to do with size of factories.rb file.

112 views
Skip to first unread message

mckinnsb

unread,
May 26, 2010, 2:12:51 PM5/26/10
to pickle
Hi,

I'm running a fairly large web application , and I use Rails/RSpec/
Cucumber/Pickle/FactoryGirl to drive a lot of my testing. We recently
upgraded to Rails 2.3.5, and are now seeing the following error:

regular expression too big: (lots of models) ...(RegexpError)

The error is thrown before any of the Cucumber tests are run, during
the loading of the steps (through StepMother).

It seems that it has something to do with the factories.rb file;
commenting out all of the factories in factories.rb allows Cucumber to
continue to load and run its tests, but obviously, all of the steps
that use the aforementioned factories fail, or become undefined.

Removing the pickle_steps.rb file also allows Cucumber to continue to
load and run its tests, but obviously, all of the steps that use
pickle_steps.rb become undefined.

Strangely enough, another portal for the same application (shared
models and factories.rb file), can run its Cucumber features without
experiencing this error - but some of the steps that use Pickle fail
as unambigous matches. Some of them pass.

Has anyone seen this error , or anything like it before?

Ian White

unread,
May 28, 2010, 3:48:50 AM5/28/10
to pickle-...@googlegroups.com
Hi,

Wow, that must be a big app!

The reason why this is happening is that pickle constructs a regexp based on all available 'factories' to keep clashes with other pickle steps to a minimum. The issue that you have reported is making me rethink this approach.

Could you post the exact stacktarce on a gist for me to look at please?, Or mail it to me off-list?

Short term solutions:
- have you tried setting pickle's config.adapters setting (in support/pickle.rb) to just :factory_girl (the default setting loads up 'factories' for all active_records as well)
- you could also try replacing #{capture_model} in the step definitions with (.*?) if you don;t get any ambiguous steps matches this should fix your issue. If you do get ambiguous steps, you can try adding your own regexp which suites your app

Long term solutions:
- use some delimiters in pickle steps so that we don't need to introspect on factories/predicate names, the downside to this is that pickle steps become uglier:

Given "a user" exists

anyone have any other ideas?

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

mckinnsb

unread,
May 28, 2010, 11:10:53 AM5/28/10
to pickle
Hey Ian,

Thanks for the reply. Yeah - it is a fairly big application at this
point. Unfortunately, using just factory_girl was also enough to
generate a huge RegExp (I think we have ~127 factories). The biggest
issue was in the model predicate step - there are a lot of potential
combinations.

However, replacing #{capture_model} with (.*?) did work, and allows
the tests to run. There are a few ambiguous steps, but not too many,
so it shouldn't be that bad covering them with our own RegExp(s).

The delimiter idea doesn't sound too bad - it is a tad uglier but I
think it could still be human readable by our business-types.

Thanks for the response!
-Stew

zubin

unread,
Jun 16, 2010, 12:53:02 AM6/16/10
to pickle
I've been having similar issues with an app with 194 models. About
half are blueprinted.

Instead of getting a "regular expression too big" RegexpError, I'm
getting intermittent segfaults.

I've tried the suggestion of replacing #{capture_model} with (.*?)
like this:

# pickle_steps.rb
capture_model = '(.*?)'

... and am using cucumber --guess to avoid ambiguous matches.

But the segfaults persist:

/opt/local/lib/ruby/gems/1.8/gems/cucumber-0.8.0/bin/../lib/cucumber/
rb_support/regexp_argument_matcher.rb:7: [BUG] Segmentation fault
ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin10]

Anyone have any suggestions? It's slowly but surely driving me mad!

Thanks
Zubin

On May 29, 1:10 am, mckinnsb <lordma...@gmail.com> wrote:
> Hey Ian,
>
> Thanks for the reply. Yeah - it is a fairly big application at this
> point. Unfortunately, using just factory_girl was also enough to
> generate a hugeRegExp(I think we have ~127 factories). The biggest
> issue was in the model predicate step - there are a lot of potential
> combinations.
>
> However, replacing #{capture_model} with (.*?) did work, and allows
> the tests to run. There are a few ambiguous steps, but not too many,
> so it shouldn't be that bad covering them with our ownRegExp(s).
>
> The delimiter idea doesn't sound too bad - it is a tad uglier but I
> think it could still be human readable by our business-types.
>
> Thanks for the response!
> -Stew
>
> On May 28, 3:48 am, Ian White <ian.w.wh...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > Wow, that must be a big app!
>
> > The reason why this is happening is that pickle constructs aregexpbased on all available 'factories' to keep clashes with other pickle steps to a minimum.  The issue that you have reported is making me rethink this approach.
>
> > Could you post the exact stacktarce on a gist for me to look at please?, Or mail it to me off-list?
>
> > Short term solutions:
> >  - have you tried setting pickle's config.adapters setting (in support/pickle.rb) to just :factory_girl (the default setting loads up 'factories' for all active_records as well)
> >  - you could also try replacing #{capture_model} in the step definitions with (.*?) if you don;t get any ambiguous steps matches this should fix your issue.  If you do get ambiguous steps, you can try adding your ownregexpwhich suites your app

zubin

unread,
Jun 16, 2010, 4:11:08 AM6/16/10
to pickle
I forgot to mention, we're in the process of phasing out factory_girl,
which means we have both factories and blueprints. Commenting out
factories prevented further segfaults, so maybe that was the issue.
Reply all
Reply to author
Forward
0 new messages