Automated Testing Suites in Ruby on Rails
Make no mistake: web applications are not documents, they are software. While a simple brochure-style site may contain nothing more than static HTML pages, your typical Ruby on Rails application is something more. After all, if you only need a few static pages to your site, there’s no reason to bring Rails into the mix to begin with.
Web applications have evolved into sophisticated beasts. How much “sophistication” or “beast” you see largely depends on the caliber of developer you hire. A key element that “separates the boys from the men” is the inclusion and development of an automated testing suite.
Ruby on Rails makes it easy for developers to test the code they write. Writing these automated tests ensures that the code works the way it should, when new. More importantly, it ensures that no changes in the future will break existing code. This is often called “regression testing” – going back and making sure that new changes to the site haven’t compromised existing parts. With a test suite, literally thousands of regression tests can be run in mere seconds every time a change is made to the code.
Here’s a list of good test-related questions to ask any Ruby on Rails developer you’re considering:
Do you practice Test Driven Development?
The answer you want is “yes”. It ensures that no code ever makes it into the application without first being tested.
What’s your preferred testing suite?
Good answers include Shoulda, RSpec and the Rails default, TestUnit. It’s not so important which the developer prefers. What’s important is that the developer has done enough testing to have a preference. Contract developers will often be skilled in all three, since they need to jump into existing applications where the choice has already been made. That’s a bonus.
What kind of test coverage do you shoot for?
Good developers aim for at least 90-100% test coverage on what are called “unit” tests. They typically strive for 80% or better coverage for “functional” tests. Of course, a good developer might not give you a number at all, because different testing tools measure coverage differently. Instead, they may discuss how they ensure an application is well tested, and that’s okay too. Again, a well thought-out answer is just as good or better than a specific number. This also answers another important question: can this developer explain complex things in a way that is easy to understand?
Testing vs. “Winging It”
In the beginning of a project, you won’t be able to tell if a good test suite is being developed. A junior developer who skips tests will likely take the same amount of time as a seasoned developer who doesn’t cut corners. In fact, if everything on your site works well, you can’t tell if there is a test suite behind the scenes or not. But the first time a code change creates a major bug, you will definitely know there was a lack of good testing.
Test suites are about keeping the code maintainable for the long term. If you plan to have your website for longer than six months, insist on a developer who makes automated testing a priority.