Finally taking the plunge with writing tests. Still, not quite getting all things covered but this test-driven development is an excellent way to keep development moving without fear of breaking stuff. Developing without tests is like walking down a dark alley in a rough neighborhood. Tests throw floodlights all around you so you know what's coming. It wont stop you from getting mugged if you walk down the wrong street, but you'll see it coming from a mile away with ample time to respond rather than being caught by surprise after it's too late. Same with pickpockets and murderers.
For example, I found a method I was using was a redundant and brittle re-implementation of something that could be done with default associations. After changing the methods and views, test failures went from 0 to 15 or so. I immediately knew it had something to do with my change and was probably related to old fixtures and controller tests. The fix maybe took 5 minutes and now I was back to 0 failures and errors. This is much better than waking up 3 months later, scratching my head about what went wrong.
Of course, it wont make an amateur coder a rails hacker but even if my methods are ugly and code is badly coupled, it is nice to know stuff works to a certain extent and it provides an excellent basic form to improve upon.
A combination of ZenTest's "autotest -rails" and this Red/Green terminal hack ensures I'm always up to speed with tests running in the background anytime there's a change and color coded to boot!
I really can't do testing any justice compared to this wonderful article or any of the other links below, but this should give you a good start.
A Guide to Testing the Rails |
New Bamboo - You never know when the brakes might fail
Agile Reality: Making Unit-Testable Environment-Specific Rails Routes
RailsTips.org—Tips for Riding the Rails
Projectionist: DRY up object attribute change assertions
Panasonic Youth » Blog Archive » Hacking green bar color output into Autotest
