Blog of Rob Galanakis (@robgalanakis)

A short letter to a unit testing newcomer

One of my friends asked how to get started with unit testing and Test Driven Development and figured I could write a short post. I also mention TDD a few times in my book so I think it could use some more attention.

I got started with unit testing when I wrote a smallish Python project, and realized I couldn’t maintain large Python projects without tests*. So I wrote unit tests for my code. I then quickly got into TDD. I don’t remember what resources I used, but there are plenty.

I’d encourage you to start unit testing by writing your code first, then the tests. As soon as this becomes easy and is paying off, start writing the tests first (TDD). You will come to appreciate that this is a powerful way of thinking and working. Even if you don’t ultimately stick with this approach, it is worth becoming skilled with it. You will uncover many suboptimal areas in your coding process that are otherwise extremely difficult to find and fix.

Keep in mind that learning TDD isn’t like already knowing Mercurial, then reading a book about Git**, and then being skilled with Git because you are skilled with Mercurial. You are embarking on a long journey, and will need to refer to many tutorials, blogs, and books. You will do some TDD, and look back on that code and process in a year and be horrified, just like you were when you started programming. Do not think of unit testing and TDD like learning a new framework or library. Think of it like learning how to program all over again.

So I don’t know exactly where to get started, only that you must, and keep going once you do start.

* I’d soon realize that no project was really maintainable without tests.

** Pro Git is my favorite Git book, by the way.

One thought on “A short letter to a unit testing newcomer

  1. Jon Lauridsen says:

    And the good news is that when you look back horrified that project will be refactorable, because it has tests! :)

    Rob. you send my down the path of unit tests, and it really did change everything I knew about programming. For me, I think collaborating with someone brings out some very interesting implications of tests. Its incredibly eye-opening to work with code someone else wrote and you wonder “this could benefit from a change” and *actually be able to change that code*. Or someone wonders about your code in an edgecase you didn’t think of, and a test instantly shows if there’s a problem or not. Having true confidence in code is worth everything, and it starts with unit tests.

Leave a Reply