Exercise, Good Choices, and DDT

Test automation is a lot like exercise. If you've not done much of it lately, it tends to hurt a bit when you start back. If you've never written tests before, it's going to be just like squats when you first do a few. You're not going to like it. In fact, it's going to be downright uncomfortable.

We don't write tests, or exercise, because it feels great. We exercise because it makes us more healthy today, and improves our health tomorrow. We write tests because it helps us write better software and makes it easier to maintain in the future. Does it hurt at first? Yes! Is it worth it? Again, yes.

There are a few things you can remember that'll improve your chances whether you're testing or exercising.

Accountability

One of the best tools we have at our disposal is our friends. When you start exercising, you need to find an exercise buddy. When you sleep in and skip the gym, your bud will call you names (most of which I can't print here). There'll be many times you'll only crawl out of that warm bed because your friend is meeting you.

Do the same with your testing. Find a friend at work and challenge them to not write any new code without a test covering it, or not to fix a single bug without proving the fix with a test. Share your work with each other, and if you catch your bud checking in code, feel free to call them any names that come to mind. I find a bit of encouragement tends to work better, but find a way to reach your friends.

Strategy

Wandering into a gym and moving from open station the next available station is a bad strategy. It doesn't produce a balanced workout and won't help you achieve any specific goals. Sadly, that's how many developers write tests. Let me suggest a few alternatives to random improvement.

Defect Driven Testing, or DDT, is a great way to exterminate bugs (just like the chemical DDT). When you find a bug, add a test. It's a pretty simple strategy, but it's insanely effective.

Follow this strategy for a few months, then look at the code your test is covering. It's the worst code in the system... to be fair, it's probably also the most complicated. But it's also the most heavily used. Those reasons are why the bugs were reported in the first place.

By adding automated tests where the bugs have been found, you've followed an extremely targetted approach to test creation. It'll be difficult for anyone to argue that your tests weren't needed... the bugs came first!

Habits

Don't skip a day! Sleeping in one day makes it easier to skip two... then three, then a week. The next thing you know, you'll be shaped liked me! ;) Tests work the same way.

If you skip one fix, and don't cover it in a test, it'll be easier to skip two. Then three. Then you'll look back and wonder why your entire codebase is such a mess.

Wrap Up

Test automation is the easiest way to create solid code, and keep it solid. If you involve your team mates, adopt a proven strategy, and stick to the routine, you'll be in great "shape" before you know it. Just like exercise, no one can make you do it. And, just like exercise, no one can stop you either.

Carpe diem dude