Saturday, October 15, 2005
Unit testing
Unit testing just rawks. I'm having such a blast doing "this XP thing" with respect to TDD, coding by intention, and writing unit tests.
We have no official unit test tool (such as JUnit or CPPUnit, etc.) since we are writing in CLIPS. However, a couple of cool things about CLIPS. One is that it is reflective and another is that you can extend the functions/methods of a class by adding them into another file. This makes it every easy to write a test harness framework (which I had previously done) and then start writing unit tests.
In general I'm doing very little design up front. Based upon the iteration and who signed up for what task, I'll say something like, "OK. So I'm supposed to write a class to do X and Y, right?" and then after we discuss this for a few minutes, I'll write a stub for the test code for the class. Setting up a directory (we have all our configuration, run scripts, and test code for a particular suite in the same directory). I can get this set up in about 5 minutes or less - creating all the code I need to create for a test suite and then running it to show it runs and fails the first test.
I then start writing my tests. "OK - the class needs an X method, and it needs to do Y." I write the test, and maybe as I'm doing that I realize that I need a way to easily prove it worked - so maybe I need a few more methods. I add those into the class, stubbed - along with X. And I just keep going, building helper classes (which now get their own test suite, which I can quickly set up and start testing.
The other day I started in the morning thinking I was going to write class A, but as I went to test it realized that I really needed to write B first - as a helper class for A. By the end of the day I hadn't gotten much progress done on A (although the test was still in place for it), but I had gotten B fully completed, along with 27 tests that proved everything it needed to do. The next day I could look at A and see that with B complete, there was much less to do in A, and I started testing and working on it.
The thing that makes unit testing rawk, to me, at this point in the life of this new project, isn't even all the cool long-term project stuff like being able to easily modify code, being able to fix a defect or add a feature with the hard and fast knowledge that you haven't broken anything yet. What is really cool is the other things that XP talks about. Feedback and progress. The ability to quickly write code and have feedback. To think of a needed functionality, write a test for it, and code it within minutes and see it work. To have that feeling of accomplishment. Not just that "I wrote some code today and I think it will probably work and I'm making some progress", but to know that "I added 5 new methods to the class today and they are passing 25 unit tests, doing both positive and negative tests." To see that test number climb from 1 to 3 to 7 to 10, etc. throughout the day. Its just a very cool thing... and so fast and immediate.
We have no official unit test tool (such as JUnit or CPPUnit, etc.) since we are writing in CLIPS. However, a couple of cool things about CLIPS. One is that it is reflective and another is that you can extend the functions/methods of a class by adding them into another file. This makes it every easy to write a test harness framework (which I had previously done) and then start writing unit tests.
In general I'm doing very little design up front. Based upon the iteration and who signed up for what task, I'll say something like, "OK. So I'm supposed to write a class to do X and Y, right?" and then after we discuss this for a few minutes, I'll write a stub for the test code for the class. Setting up a directory (we have all our configuration, run scripts, and test code for a particular suite in the same directory). I can get this set up in about 5 minutes or less - creating all the code I need to create for a test suite and then running it to show it runs and fails the first test.
I then start writing my tests. "OK - the class needs an X method, and it needs to do Y." I write the test, and maybe as I'm doing that I realize that I need a way to easily prove it worked - so maybe I need a few more methods. I add those into the class, stubbed - along with X. And I just keep going, building helper classes (which now get their own test suite, which I can quickly set up and start testing.
The other day I started in the morning thinking I was going to write class A, but as I went to test it realized that I really needed to write B first - as a helper class for A. By the end of the day I hadn't gotten much progress done on A (although the test was still in place for it), but I had gotten B fully completed, along with 27 tests that proved everything it needed to do. The next day I could look at A and see that with B complete, there was much less to do in A, and I started testing and working on it.
The thing that makes unit testing rawk, to me, at this point in the life of this new project, isn't even all the cool long-term project stuff like being able to easily modify code, being able to fix a defect or add a feature with the hard and fast knowledge that you haven't broken anything yet. What is really cool is the other things that XP talks about. Feedback and progress. The ability to quickly write code and have feedback. To think of a needed functionality, write a test for it, and code it within minutes and see it work. To have that feeling of accomplishment. Not just that "I wrote some code today and I think it will probably work and I'm making some progress", but to know that "I added 5 new methods to the class today and they are passing 25 unit tests, doing both positive and negative tests." To see that test number climb from 1 to 3 to 7 to 10, etc. throughout the day. Its just a very cool thing... and so fast and immediate.
