We have been working to enable access to our data via ODBC and/or MS Access - a project more complicated than expected. While we were working on this, I went to cf.Objective.
Among the very good presentations I attended was one called "Test Driven Development" by Paul Kenney. I had attended a few online presentations about TDD before and read a few articles as well. I always came away thinking that I should try that out "some day", but also feeling like I didn't quite grasp the concept fully (I did not grok TDD).
This presentation, however, was different. Paul explained the concept in such a way that I felt like I could (and would) implement it. I felt like I had a fair understanding of the process and could put that understanding to work.
Once I returned to work, we were nearly done with coding our application and ready to test. Clearly, we couldn't really use TDD here - we had already written the code. Even so, we would put some of the lessons of TDD to work right away.
We decided to pretend that we hadn't yet written the code. We wrote a testing document and from those ran the test cases (having chosen CFUnit as our testing framework). Our code failed perhaps half of the tests initially.
We started testing on Monday for a deadline the following Monday. Late on Saturday and tests are still failing. Saturday ends with both of us exhausted and feeling a bit panicked.
I wake up Sunday realizing that I don't understand the parts of the code that I hadn't written. This is no good. I review of the code reveals that it could be written more smoothly.
This point deserves a quick aside. The code and process it followed was rough because we were trying to do something that neither of us had done before. By the time I reviewed it, we had done it was (unsuccessfully, obviously, but still good experience). It was when I looked at it with the experience of having created the application (and the test cases!) that I saw why the process wasn't smooth.
It turned out that some parts of the process were very smooth and others weren't. I had to rewrite some of the process. The rewrite took only a few hours. This was thanks in part to a better understanding of the process and to cannabalizing code from the previous process.
Now for the good news. Because our tests were already written and because they were written only to check the results of the process (that is, without knowledge of the implementation), we were able to use the same test cases for the new process.
By late Sunday, we had the new process done and tested and taken live. I even had a few hours of sunlight left to get outdoors for a while before the sun set.
Next time, I will write the tests first and more closely follow TDD (what we did here clearly wasn't TDD). Even without following TDD, however, our late imitation of it and our use of CFUnit clearly saved the day.