Archive for the ‘Test Driven Development’ tag
If you code by writing tests that fail, and then fixing the tests by writing the code, then you might find yourself switching to a terminal, running the test, ad nauseum. Part 1 of my tip is to run the test in a loop that takes a single keystroke to trigger:
$ while read line; do clear; perl MyTestScript.t; done
This works with any language, not just perl — just replace the test command with the right one. ALT-TAB, press Enter, ALT-TAB back to your editor.
Part 2 of my tip is to make it really easy to drop into the debugger if you want. Notice the small change here:
$ while read line; do clear; perl $line MyTestScript.t; done
Now instead of pressing Enter, you can type “-d” and press Enter. Presto, you’re in the debugger. This also works for any language that has a built-in debugger. Of course, you can also pass any other arguments you want, such as enabling profiling.
I got some interesting comments on my previous article about unit testing Maatkit, including echoes of my own conversion to the unit-testing religion. One of the objections I’ve heard a lot about unit-testing is how it’s impossible to test code that talks to a database. “It’s too hard,” they say. “Oh, it’s easy to test a module that calculates a square root, but a database? Way too much work!”Read the rest of this entry »
Over in Maatkit-land, Daniel Nichter and I practice test-first programming, AKA test-driven development. That is, we write tests for each new feature or to catch regressions on each bug we fix. And — this is crucial — we write the tests before we write the code.* The tests should initially fail, which is a validation that the new code actually works and the tests actually verify this. If we don’t first write a failing testcase, then our code lacks a very important guarantee: “if you break this code, then the test case will tell you so.” (A test that doesn’t fail when the code fails isn’t worth writing.)Read the rest of this entry »