The Testing Practices Interview series is back. Our interviewee is Mike Gunderloy, publisher of A Fresh Cup and member of the Rails Documentation Team.

Mike has recently released Rails Rescue Handbook, a guide to taking over Rails projects that have been abandoned or are otherwise new to you. It’s a DRM-free PDF file, available for $9.95, and it’s full of useful tips and advice, highly recommended.

So, here’s Mike.

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

To some extent I’ve been testing for 30 years, ever since I got started programming. I don’t see a strong distinction in purpose between manual testing, debugging, and automated testing: they’re all ways to make sure your code does what you think it does.

As far as automated testing, though, my first exposure was during some Microsoft contracts 10 years ago or thereabouts. But on those big projects, automated tests were maintained by the testers, not by the developers; completely different group of people and tools. I did dabble a bit with tools like TestDriven.NET, but ultimately, it was moving over to Ruby/Rails that got me into a truly test-infected environment.

So I’ve pretty much “always” known that testing was valuable, and even seen the benefits of automated testing for quite a long while. It’s been an evolutionary step from there to developer-written automated tests and TDD – which I am not religious about. I use TDD when it suits me, and skip it when it doesn’t.

What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

Probably 90% of the tests I write these days are functional and unit tests, and the other 10% integration tests. As a subcontractor to many different teams, I’ve had the chance to experiment with a great many tools. The exposure has left me unconvinced that there’s a good ROI on either view testing or Cucumber-style BDD, though I recognize that reasonable people differ on this (and that different teams or different projects might have left me with a different impression).

When I have the luxury of picking my own tools these days, I find myself using Test::Unit, Shoulda, Mocha, and Object Daddy most often, with a side of parallel_test when the test suite grows. I’ve played with a couple of different CI servers as well, and at the moment I’m leaning towards Cerberus.

As far as process goes it’s a mix of TDD and more traditional top-down decomposition development with tests as I go; some of this just reflects my age in the industry, I’m sure. I do lots of little code spikes via git branching, and those usually don’t have tests involved; then I’ll come back to the branch I’m working on when I know where I’m going and write the tests and code together.

What’s the most interesting thing you’ve discovered about testing recently?

I’ve been spending a fair amount of time doing code reviews lately. It astonishes me how many teams – even good teams writing good code – have little to no test coverage. The fact that the code is good indicates that testing is not 100% essential – the fact that it has holes shows how it would help. And it’s also evident that the wider Rails community isn’t as test-infected as we like to think it is.

Is there a tool you wish you had for testing that you don’t think
currently exists?

I wouldn’t mind finding a good open source record-and-playback tool to use for browser-based integration and maybe even view testing. That used to be pretty useful, back in the day. For all I know one exists and I haven’t gone looking for it. I’d also like something that could do an automatic “lint” looking for cross-browser issues.

What advice would you give somebody looking to write more effective tests?

0) Buy Noel’s book. 1) Write tests. Like anything else, you improve if you do more of it. 2) Find a project you like and look at their tests to see how they did it. If you find patterns you can steal, go for it.

Weblinks:
Test Driven Development: A Tutorial (pdf)