Two bits of advice off the top of my head: Test interfaces, not internals. What you really care about is whether the models behave consistently, not how they get things done. For example, if calling banish_from_my_sight on a Thingy should remove it from the list returned by Thingy.in_sight, check that directly. Don't check whether it set the banished? flag, because it's not relevant and could change later without impacting what matters.
Mine your controllers and views for model interfaces you count on. Look for the non-standard ones first, the ones that assume something Rails doesn't provide by default. In the Thingy example, you might have a destroy method in ThingyController that calls banish_from_my_sight, then redirects to the index method to call @thingies = Thingy.in_sight. That's the assumption to test. Corollary to that second bit, since you're upgrading: As you find interfaces that don't work, write the test before fixing the problem. If the test fails when the thing is broken and passes when the thing is fixed, that shows that you know where the problem really is. :) Good luck, ~chris On Fri, Dec 13, 2013 at 10:55 PM, Chris McCann <[email protected]>wrote: > > The question I'm posing to the group is this: what's a good approach to > adding tests to existing Rails models using RSpec? What should I be trying > to cover? Are there any tests that are particularly smart to run in a > framework upgrade situation? What types of tests would you add right off > the bat? > > -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
