Write tests, because you already do

When I first started programming in Python, I wrote no tests at all, but I had a couple of good reasons why. One, nothing I wrote was at first larger than a single file. Two, I wasn't in the habit and I didn't have good examples to follow.

Now, about five years into programming in Python, a few things have changed. First, I no longer write only toss-off scripts; I'm writing much larger and more complex apps. Second, I'm in the habit of writing tests for anything larger than one file.

The biggest change in this habit came about when I started writing Aki, based on the work done in the Pykaleidoscope project. That project had tests, and at first I wrinkled my nose. But then I started adding to the codebase on my own, and adding tests to go with them, and I Saw The Light.

Whenever you add any new functionality to a program, or change its behavior under the hood, you're going to want to find out whether or not those changes or additions break anything. Writing a test and adding it to an existing test suite is the most convenient way to automate that process. The initial labor of writing the test is far outstripped by the labor saved along the way, and often not even that far along the way.

Aki has a REPL, and one of the quick-and-dirty ways I test a new feature is by typing code into the REPL. If it doesn't work, I fix it, and then I take that quick-and-dirty code and create a test from it. Often I expand on the test as I find other corner cases (which I inevitably do). Because the test suites use helper functions and a boilerplate I can copy and paste, the total time involved in adding tests is negligible.

This is what I mean by "Write tests, because you already do." You have to write something to determine whether or not what you added is going to work! Might as well make it part of the suite you use to ensure everything's Kosher anyway.

Write tests.