I have written recently about my discovery of testing when developing code, and of test driven development. At the time, I was amazed at how well it revealed unused code as well as bugs in the code that is being used. Unfortunately, I have also discovered that testing is a discipline. Like any other discipline, it is one that you have to work at establishing, and you need to work to maintain it.
I came to a spot while working on the LiMSpec project where I was trying to develop some unique code, and simply stopped writing new tests, and completely avoided running the existing tests while I was busily “hacking.” I had reverted to my old bad habits established from 20 years of coding in everything from Assembly Language on up the complexity tree. Code, code, code, then maybe document, then maybe design. Test only when everything is done.
Surprisingly… okay, not surprising at all, I had broken various things in the process. The only way I knew this was when I ran tests to generate a coverage report. So I’ve now gone back and fixed the broken parts, and have extended the existing test suite. There is still more work to be done. I’d like to get close to 100% coverage, but am only at about 85% right now (I think it might actually be quite a bit higher as RCov seems to have missed many places where the code has been run in a test but is not being captured), and will seek to get there during the second release. In the meantime, I’m going to try to force myself to move much more toward the Test Driven Development approach – where the tests are written first, then the code written to pass the tests.