This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: Unit Tests as a Gateway Drug
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
As I rule I encourage people to avoid unit testing and write higher level tests. There's nothing wrong with unit tests and I'm not opposed to them, but it seems like we are, as an industry, overly focused on unit tests to the exclusion of other types of tests. I try to encourage people to write tests that exercise more of their application. Mock client tests are my favorite type. They exercise more code than a unit test. When used in a Continuous Integration environment, you still get really good feedback on where problems are. Mock clients are coarse-grained tests in a fine-grained build.
Recently I'm encountering more teams whose code is "untestable". They're convinced that their product isn't testable because it has a browser GUI.
But I've also found that unless the entire team gets involved, creating an automated testing suite is more difficult than it needs to be. It's so much easier when there's a team involved. But the idea that "our product isn't testable"... that's a difficult mindset to overcome.
So, in the cases when I don't have the bandwidth to create a suite of tests myself, I'm starting to sidestep the opposition.
Assuming that your product isn't testable from the GUI, your units are testable. So we'll start at a level you can't argue with... unit testing.
So far it seems to be working... my goal is to introduce automated testing via unit tests. Then we'll broaden their horizons a bit. :)
Previous Topic
