Hi David > Even though the code is in a helper, it depends heavily on the model. > This exhibits a code smell called Feature Envy, in which one object (the > helper) does some computation but another object (the CfgInterface > model) has all the data. Based on that, one might argue this method > belongs on the model anyhow, in which case the argument of stubbing out > the model layer makes little sense.
I see your point and in this case you are probably right but what if my helper was more heavy on the processing and still very data dependent ? Should I use fixtures on the helper or should I stub/mock whatever I need to avoid the model layer within the helper ? > There are also several expectations that overlap. It doesn't matter that > the class is a Hash - what matters is that it behaves like a hash, which > is demonstrated in other expectations. The fact that the keys exist is > also demonstrated in the expectations that access those keys. Good point, thanks. > Based on those comments, I'd probably do something like > http://gist.github.com/506366. Then I'd figure out how to swap in > factories for the fixtures - right now there's no way to understand what > 'CONS_ALL_ACCOUNT' means without looking elsewhere. 'CONS_ALL_ACCOUNT' actually has no impact when using stub/mocks, 'CONS_ALL_ACCOUNT' was the input parameter the model was using to fetch data from the BD, in the second form of the test with stubs/mocks, this input parameter has no meaning since I'm controlling all return parameters. -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
