Here at Spider Strategies, we strive to use the latest and greatest technologies and software development methodologies. One area that has received a lot of buzz during the past few years is Test-Driven Development (TDD). Proponents of TDD claim it can both improve software quality and decrease development time. A technique that can both improve quality and decrease cost is a very attractive prospect, but we've been a little puzzled on how to get TDD started.
The trouble is, TDD depends on the creation of unit tests, but it's difficult if not impossible to write unit tests for code that accesses a relational database. Since most of the Corporate Management Suite is concerned with accessing and manipulating data in databases, it didn't seem like there was much room for us to apply TDD to our development process.
In the past 2 weeks, the way has become clearer. Last Friday our newest addition to the development staff, Keith, wrote a test that verifies documents in the documents tab are displayed alphabetically. That got me thinking that although testing is difficult when dealing with databases, there are lots of parts of the application that aren't directly concerned with the database for which we can write tests. So, this morning I wrote a unit test that makes sure we're sending correct HTTP responses back to web browsers.
Instead of starting up the application, logging in and manually testing the part of the application, I was able to run my tests directly in my development environment. Instead of taking 1 or 2 minutes for testing every time I made a change, I was able to run my tests in seconds. All told, I felt like I accomplished several hours of work in a little under an hour. I've never had any doubt that TDD would improve software quality, but I was always incredulous that TDD could decrease development time. Today I saw that TDD really does have the potential to both improve quality and speed along development.