Re: [rspec] Refactoring/DRYing up complex controller specs

[David Chelimsky]

On Sun, Mar 31, 2013 at 9:54 AM, Bryce Senz <bryce...@gmail.com> wrote:

I am currently trying to refactor my app's controller specs, and I'm a bit unsure how to begin.  One of my controllers is for a model which implements a moderately complex state machine.  The controller is as thin as can be, while still handling the fact that different controller actions need to react differently depending on the model's state.

Between many (10+) different controller actions, many (10+) different states, and the fact that each test checks the flash, instance variables, and redirect paths, my controller specs are now over 2000 lines long.  Would it be more appropriate to just create a new spec file for each action at this point?

What about breaking up the controller? Any logical grouping of actions that makes sense?

In terms of spec'ing state machines, one thing that RSpec doesn't have DSL support for, but Ruby makes easy, is setting up a table, e.g.

[ [a, b, c, State::FOO], [d, e, f, State::BAR] ].each { |factor1, factor2, factor3, state|

  it { should produce(state).given(factor1,factor3,factor3) }

} 

You'd need a "produce" helper (or whatever) to make it read this cleanly, but as you can see this can reduce a lot of run-time examples to a single eval-time example that gets run multiple times with different inputs/outputs.

If you are at liberty to post some of the controller spec and controller code we can get into specifics, and there are certainly other approaches.

HTH,

David

 

It's just become so big that it's difficult to sort through it all.  Has anyone else ever run up against this problem?

--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/rspec/-/FUSybPnR_lsJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bryce Senz]

Breaking up the controller doesn't make conceptual sense to me - it pretty much maps 1:1 with all of the user driven state transitions.  Breaking it up would sacrifice logical structure just for the sake of file readability, which doesn't seem right.  Also, the controller itself isn't too overwhelming - it's just all of the tests.

Unfortunately, I can't share any of the code directly.  I do like the idea of looping over different states in the test itself.  I'll give that a shot.  Thanks!