I was just working on adding autoindenting to bililiteRange, and actually took advantage of the fact that I had an automated test harness in place for that library. So I actually used test-driven development: write the tests for the code that doesn't exist yet, then write code until they pass. It's an odd way of thinking, but I realized that it was more fun than my usual development cycle (remember, I'm a hobbyist, so if it ain't fun, I don't have to do it):
- Think of problem that needs solving (interesting)
- Write code to solve problem (interesting)
- Write demo/test code (sort of interesting)
- Run test-fail test-mutter at code-recode debugging cycle (frustrating)
With TDD, it's more like:
- Think of problem that needs solving (interesting)
- Write demo/test code (sort of interesting)
- Run test-fail test-Write code to solve problem cycle (interesting)
The tedious "debugging" phase is swallowed up in the interesting "write code to solve problem" phase and I enjoy it a lot more. There's still some tedious debugging if the test doesn't work, but the test code is simpler than the "production" code and generally easier to debug. I have had some problems getting my head around testing asynchronous code, but that probably means I need to simplify the whole system.
Now I need to learn the discipline to keep to this style of development and I'll be a happier hacker.
Leave a Reply