Writing tests first
October 10th, 2008 at 6:15 pmI’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.
Related posts:
October 10th, 2008 at 20:54
I have some kind of mental block against true TDD. I find that I really prefer to code something before I feel I can write initial tests for it.
For new code, I try to write tests and code simultaneously rather than before or after. My typical setup has 3 terminal sessions side by side: one for code, one for the tests for that code, and one for running tests and keeping test output visible while I tinker. Writing the test as immediately as possible means I can run it immediately and know that I’ve left myself in good shape before moving on to writing the next piece of code.
For changes to code that’s already well-covered, I focus on always updating the test (or adding new tests) first, as test failures make a nice to-do list. Once the tests are passing again, I’m confident that I’m done and can move on.
And of course Titus Brown’s (in)famous remark about TDD comes to mind — “I don’t do test-driven development. I do stupidity-driven development. I wait until I do something stupid, and then write tests to avoid doing it again.”
October 15th, 2008 at 20:26
Yeah, Mike made the exact point I wanted to make in his quote - people should make sure to precede every bug fix with a test. The order of things should be:
1. Discover a bug
2. Write a test, make sure it fails (and actually catches the bug)
3. Fix, watch things turn green.
4. Rejoice.
Making sure the test fails is crucial here, otherwise you could be testing the wrong thing.
October 15th, 2008 at 22:13
I think you are making a serious error. If you wait for bugs to appear for writing tests then refactoring will be hard. When people feel that writing a unit test boring, IMHO, there are two possbilities:
1) Code is really a one-man project,
2) It is really redundant, see tips for writing good unit tests, you don’t have to test everthing, you have to test cleverly.
There is a very good tutorial on Micoroft site, named Unit Testing Tips.
October 17th, 2008 at 06:42
One way to make TDD easy on a developer is to use a powerful IDE. Java/junit TDD, with the eclipse framework, from my experience is fluid, fast and fun.
For instance, while writing your unit tests, declaring a non existing object, will give an on the fly error, where the developer can test-fail and then correct immediately by allowing eclipse to auto generate the object. this applies to other properties of the object as well.