Exercise, Good Choices, and DDT
Join the DZone community and get the full member experience.Join For Free
Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
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.
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.
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!
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.
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