We built an(other) object factory module for our current project and it looks a lot like all the others:
After a while, we noticed that the create methods were all exactly the same. Time for dynamic refactoring!
Unfortunately, this leads to rather bizarre error messages during testing:
Failures:
1) MyHelper#filter returns an empty filter if there's nothing in the session
Failure/Error: not_my_method
NameError:
undefined local variable or method `not_my_method' for ...
# ./spec/support/object_creation_methods.rb:141:in `method_missing'
# ./spec/helpers/my_helper_spec.rb:14:inWe became our own enemy; Since we are including our module in RSpec for our tests, any missing method passed through our dynamic response method, with unfortunate, confusing results. Sad Panda.
There’s a refactoring pattern, “Replace Dynamic Method Receptor with Dynamic Method Definition” which translates run time #method_missing into methods defined at load time. No more crazy stack traces!
Thank you! Jay Fields, et al.
Why are you reinventing Factory Girl?
March 1, 2013 at 10:29 pm
The technique described here is not restricted to the module’s purpose, I’m just using it as an example.
That said, I have a love/hate relationship with FactoryGirl; While the DSL is really, really, nice, I can almost always get the exact same functionality with just plain old ruby. There’s less “magic” than using the gem. I’ve gotten “stuck” in weird places (with an inability to trace back the failure) using the FactoryGirl DSL when I wished I just had plain old ruby to write the factory.
March 1, 2013 at 11:51 pm