Testing approach on major Rails upgrade

[Chris McCann]

SD Ruby,

It's finally time for me to upgrade the first Rails app I ever built.  Thanks to all who made some great suggestions previously on approaches for doing so -- I'm well under way.

One of the things I want to make right with the upgrade from Rails 2.3 to (initially) 3.1 is adding test coverage.  When I started this app over (gulp!) 6 1/2 years ago I was an utter noobie and didn't know jack squat about unit testing or any other kind of software testing.  So, the application doesn't have any test coverage.  Zero.  Zip.  Nada.  

I'm presently bringing all the models into the Rails 3 version of the app, checking gem and plugin dependencies, fixing fully deprecated method calls (I'm looking at you, "named_scope"!) and really just trying to get the app to start cleanly on the Rails console.  

I've decided I want to use RSpec to write all the tests and am enjoying getting up to speed on that test framework.

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?

For now I'm only concerned about the models.  As I get more comfortable with the test coverage on them I'll begin bringing over the controllers and views.  

If you have any advice on an approach I might consider at this point I'd love to get some input.  It's never too late to add tests to an app, and I'd like to maximize the bang for the buck here.

Cheers,

Chris

[Rafael Cardoso]

I think you best option is to test it how you use them.

Also I am sure you made other mistakes that you can refactor, and that is always a great point to add test coverage too. Find that model that got too big or shouldn't exist and work your way from there.

Usually when I am trying to add coverage I find that the code isn't easy to test because it wasn't made with tests in mind. To deal with that, I usually create a layer between what I'm trying to test/refactor, and write a test for the old functionality and then refactor it.

How big is your app? 100+ models? Is this app still having new features added?

--
--
SD Ruby mailing list
sdr...@googlegroups.com
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 sdruby+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Chris Radcliff]

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

[Scott Smith]

I've found Michael Feather's book an excellent approach: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

--
--
SD Ruby mailing list
sdr...@googlegroups.com
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 sdruby+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Scott Smith

http://twitter.com/_ofd (OldFartDeveloper)

[Adam Grant]

Hi Chris,

Some folks recommend not testing the "has_many" and "validates_presence_of" stuff, since Rails has it all tested. But I would highly recommend making sure you use all the Rspec helpers on each model to make sure they pass.

Like the helpers provided in: https://github.com/carlosbrando/remarkable

it { should validate_presence_of :name }

Those are quick and easy to add for each model.

Regards,

Adam

On Fri, Dec 13, 2013 at 10:55 PM, Chris McCann <testf...@gmail.com> wrote:

--

[Rob Kaufman]

Hey Adam,

  Can I ask why you're making that recommendation? Has something in your experience gone wrong that would have been caught by having the helpers there?

Best,

Rob

[Chris McCann]

Thanks, Adam, that's exactly what I've been churning through the past few days.

Chris

You received this message because you are subscribed to a topic in the Google Groups "SD Ruby" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sdruby/FdcShqzYjFM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sdruby+un...@googlegroups.com.

[Rob Kaufman]

Thanks for the clarification Adam =-) You make some great points here.

Rob

[Adam Grant]

Really, sometimes it's all about: "did I configure this frickin' thing correctly???" 

Hehe,

Adam