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! On Monday, 1 April 2013 00:45:17 UTC+9, [email protected] wrote: > > On Sun, Mar 31, 2013 at 9:54 AM, Bryce Senz <[email protected]<javascript:> > > 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] <javascript:> >> . >> 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. >> >> >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msg/rspec/-/9RUKEzmvFVkJ. For more options, visit https://groups.google.com/groups/opt_out.
