Testing is a huge thing in the Ruby on Rails world – in fact, it’s such a core contributer to the success of our software development efforts that I find I sometimes forget that the software industry as a whole still hasn’t really caught on to the business value and productivity increases that you gain by making testing an integral part of your work.
Still, the emphasis placed on testing in Rails means that it’s an area that’s seen a lot of extension and as a result, there’s so many different tools and practices now in use in the community that we find many developers and team leaders who are unsure what they’re all for and how they related, and what testing platforms & practices they should best adopt.
The situation isn’t helped by the few testing extremists who almost put some people off with advice that seems completely unrealistic for some projects.
So when I was making a presentation on Rails application testing for the local Wellington Rails group I wanted to firstly lay out what all the different tools are and what their respective pros and cons are, and secondly to give some idea of how to choose a testing strategy that’s appropriate for the actual project rather than lecturing from a religious “one size fits all” position.
There was good interest in the material from the group and some requests for me to put it online for those who couldn’t make it; so in this little series of articles, I’m going to cover the material that went into my presentation and give a bit more discussion & some more pointers to resources elsewhere.
What we want to test – Step back for a second and have a quick look at what the actual scope of our testing work needs to be.
MVC testing – This is where the bulk of most projects’ testing time is spent. Covers when to write the tests, and RSpec vs. Test::Unit.
Model testing – For most apps, this is where you get the biggest pay rate of bugs squashed to time spent. What to test, what not to test, and some inflammatory comments about stubbing out too much.
Coming up next:
Comments