No joy yet. But I’ve gone deeper into the issue, and the puzzlement continues. It puzzles even friends of mine with far more RSpec experience than I, which is obscurely gratifying.
Not sure why it didn’t occur to me to try the ActiveRecord::Base#reload method before, but it hadn’t. I tried it here, but with the same result. #reload returns back the object you’re trying to reload (as opposed to a true or false for success/failure of reloading, so you can query the object directly. Check this out.
When this didn’t work:
1<tt> </tt>2<tt> </tt>3<tt> </tt>4<tt> </tt><strong>5</strong><tt> </tt> |
it <span class="s"><span class="dl">"</span><span class="k">should change state to 'dormant' with #dormantize!</span><span class="dl">"</span></span> <span class="r">do</span><tt> </tt> <span class="iv">@user_feed</span>.dormantize!<tt> </tt> <span class="iv">@user_feed</span> = <span class="iv">@user_feed</span>.reload<tt> </tt> <span class="iv">@user_feed</span>.state.should == <span class="s"><span class="dl">"</span><span class="k">dormant</span><span class="dl">"</span></span><tt> </tt><span class="r">end</span> |
I threw this in there to see what the output was like:
1<tt> </tt>2<tt> </tt>3<tt> </tt>4<tt> </tt><strong>5</strong><tt> </tt> |
it <span class="s"><span class="dl">"</span><span class="k">should change state to 'dormant' with #dormantize!</span><span class="dl">"</span></span> <span class="r">do</span><tt> </tt> <span class="iv">@user_feed</span>.dormantize!<tt> </tt> puts <span class="iv">@user_feed</span>.reload.state<tt> </tt> <span class="iv">@user_feed</span>.state.should == <span class="s"><span class="dl">"</span><span class="k">dormant</span><span class="dl">"</span></span><tt> </tt><span class="r">end</span> |
And I got (big surprise), “active.” Which isn’t what I get in the console. This leads me to believe that my original suspicion of not getting the RSpec object life cycle really is what’s happening here. I’m going to throw together a minor test app and put this on the RSpec mailing list to see if the gurus can get what’s going on. After that, I’m going to start setting breakpoints in AASM and do other random stuff to see if I can figure out where this is(n’t) happening.
Also, I don’t think I’m going to write a custom expectation matcher for this. Feels like overkill to me when you can just use a lower-level test that’s much faster to use and actually just queries the DB to make sure that the correct data persistence happened, which is after all, the entire point of AASM. I need to start trusting my instincts more on this kind of thing.







Copyright © 2010 Catapult Creative - info(at)catapult(hyphen)creative(dot)com - Powered by