Skip to content

Thoughts on Test Driven Development

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.

Post a Comment

Your email is never published nor shared. Required fields are marked *