Programmers Who Write Tests Get More Time to Program

From WikiContent

Revision as of 15:30, 22 November 2008 by Kevlin (Talk | contribs)
Jump to: navigation, search

I became a programmer so that I could spend time creating software by programming. I don't want to spend my time managing low-quality code.

Does your code work the first time your test it out? Mine certainly never does. This means that if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.

So the first thing I do when I'm starting on a programming task it to ask myself "How am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.

A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.

I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use. For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code to be able to run synchronously and in-process by a configuration change. The design got better in the bargain. But I would still have to set up a long chain of services. Reducing the number of asynchronous steps made my tests easier. And the design got better. I still would have to register a callback to get the result of the services chain. Refactoring my services to calculate the result they forward using a function call made my design better. And I could test almost all the logic by writing simpler tests.

When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very well," write the test anyway. And use the information to refactor your system to have a better design.

May you achieve fewer bugs and spend all your days programming happily in a well-designed system!

By Johannes Brodwall

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools