I'm always writing lots of unit-tests for my code, in any language. Unit tests are a great way to increase the overall quality of the code. Most importantly, they allow one to make changes and refactor code with much less fear of breaking something.

Test-driven development (TDD) takes unit-testing to an extreme. According to this methodology, tests are written first, and only then code is written to make them pass. "Never write a new line of code without a failing test requiring it" is a commonly quoted adage from the XP community.

I've always felt this is taking things a bit too far, and have rarely used TDD. Although eventually I end up with code well covered by tests, I write code first, and only then the unit tests.

One marked advantage of TDD is, however, tricking your own laziness. After writing a sizable chunk of code, it is somewhat boring and unexciting to spend hours (and sometimes days) writing tests for it. I'm feeling this extremely well with my C parser now. It's hard to write a partial parser, so I wrote most of the code limiting myself only to basic usability tests. Now, for the past few sessions I find myself facing my test_ files, in need of writing many many tests. This is boring, and I keep procrastinating.


comments powered by Disqus