An Unexpected Benefit of TDD
I've recently begun using Test Driven Development as my method for developing and maintaining applications. A worry I had early on was that I have inherited several poorly designed ASP .NET applications (read "poorly designed" as "not designed") and that it would be difficult to use TDD in that environment.
I was mistaken.
Today I had an issue with a browse page. The code to browse the database was slammed behind the page in a 250-300 line sub routine. Additionally, the same code was being used by 5 different buttons on the page--btnFirst, btnPrevious, btnNext, btnLast, and btnSearch. Given that the page is supposed to allow the user to browse the records a "page" (a set of x number of records) at a time, I thought the ITERATOR pattern most appropriate. I wrote a unit-test for the MoveFirst(pageSize) functionality of the RecordBrowser class, which didn't yet exist.
After implementing the MoveFirst() method, I then went on and wrote tests for--and coded--the MoveNext(), MovePrevious(), MoveLast(), and MoveToSpecificRecord() methods. After writing the tests and verifying that they worked as expected, it was pretty simple to plug the new class behind the page and start using it instead of the existing code. I watched 250+ lines of code in the Code-Behind dwindle to less than 25 lines.
Because I needed to write a test to capture the failure (which ultimately was a failure in a stored procedure call), I had to create an object that I could test in isolation from the UI and surrounding logic. This took a ltitle bit longer up front, but because I had separated out the actual db browsing logic from the UI, I could just work on getting that part to work correctly without having to worry about whether other stuff in the page was messing up the needs of the browing class. I also ended up with a set of new interfaces and abstract classes that I'll be able to re-use when I have to fix errors with other variants of the browser class, which means that the same fix will go much faster next time around.
When it came time to integrate the new class into the existing page, it took hardly any time at all. I had a couple of initial errors, but since I had already tested the browsing object, I knew that these errors were related to things on the page--not the browsing class. Once I got those straightened out, it was a snap to run the program and watch the page browse the db flawlessly.
So now I have a poorly designed web application with one lone piece of well-designed code. It took less than a morning to add the db browser class, and now I'll know that it's still functional every time I work on this program. The reason that I was able to seamlessly insert a piece of well-designed code into the system is because of the nature of TDD--the whole point is to test functionality in isolation. This means that design changes (and additions) are incremental, and have little impact on the larger system (or non-system in this case). BUT--and this is the key point--over time, as bits of quality design are added here and there, the overall quality of the system incrementally improves. As more and more features and issues are added or fixed, the overall system will begin to take on a definite structured design. TDD causes the design to spread and overtake the system.
I am so looking forward to new enhancements on these old projects I inherited.