Friends

Unit Testing…. sooo 1990s right?

Last weekend however, I listened to this podcast from SE Radio that gave me a fresh perspective on them. It’s an interview with Jay Fields… an engineer from Thoughtworks in Chicago who recently wrote an advanced book on testing concepts, synopsis from the publisher…

Unit Testing has moved from fringe to mainstream, which is great. Unfortunately, developers are creating mountains of unmaintainable tests as a side effect. I’ve been fighting the maintenance battle pretty aggressively for years, and this book captures what I believe is the most effective way to test.

Here are points from the interview that struck a chord with me.

Applying ROI to Tests

@ 9:46 in the podcast

I always figured that any test developed for a feature took effort & therefore should always be preserved as part of build or nightly tests. Jay says…

A lot of people conflate TDD & Unit Testing…. but they’re not. A test that you wrote to help create a new feature with TDD is not guaranteed to be valuable for you in the long term. Just because it helped you write the feature, once you’re done there are a lot of things you can do from there. First off you can delete the test.

Jay’s point here is that keeping tests comes with a maintenance and suite runtime cost.

What’s the ROI for this test? If it will save me from getting a phone call every 6 months… then maybe I don’t want to maintain it in my codebase. It helped me TDD the feature, but I don’t need it anymore.

Similarly, even if the test you wrote for TDD is for an important feature, that doesn’t mean that the TDD test is necessarily the best on to add to your suite. You might want to add another test that fits in more with an existing suite or an integration test.

The ROI rule also applies to older codebases having large chunks of functionality with little or no tests. Of course, we want to do as much as we can to improve the situation when we’re (carefully) making changes to that code. However, the fact is that we won’t always have the luxury of time needed to shore up years of neglect. The team should always assess the biggest bang for the buck given the constraints.

DRY Is not a Golden Rule for Test code

@ 12:00

When it comes to writing test code, approachability trumps DRY (i.e. Don’t Repeat Yourself). Approachability meaning: 3 years from now when someone is looking at a failure in the code you wrote, their main goal is to get into the test… figure out quickly what it’s testing, fix the issue & get on with developing. This means that things you wouldn’t normally want in production-grade code like cut & paste might be ok… especially if it makes it easier for the poor dude figuring out why the test is failing.

What’s a Unit Test & What’s Not?

Jay said that in his first draft of the book, he defined Unit Tests as not hitting the DB, Filesystem, Messaging, etc. Martin Fowler advised him to rip this out, since… there’s too much debate over defining the term & it’s not really useful. What is more useful is to think of your tests in terms of ones that can run fast vs. slow… so you can kick them off more or less often in your dev process.

Other stuff…

@ 25:00 in the podcast, Jay gives an example of state verification versus behavior verification. Still not sure I get the difference tbh, but interesting. Good reason to get the book!

@ 37:15 He talks about Test Data Builders which can quickly generate test data for you for OO systems.