Test Driven Development In the Real World
Well its been a couple years now and I've got enough experience doing TDD to feel that I can speak intelligent about what works (at least for me) using this development methodology. I've seen some people say that they should never write a line of code before writing the tests, well that might be all-and-good for if your primary goal is to get an A on your test this semester, but in the real world, I'm not sure this is the best use of time. Again, this is speaking from my past experience and the way I develop systems so your mileage may vary.
In my experience, as software developers we have to assume a certain level of stability in the building blocks we create. Should we create test cases around our business objects that ensure when we execute a SQL Command against the database the SQL Connection object opens the connections and successfully executes the command?
Let's look at the Red-Green refactor cycle. At any one time when you are developing software you are attempting to solve a specific problem. If you aren't sure of the problem you are trying to solve you might not be ready to start coding, it might be time to drop back to the white-board and draw some boxes/puffy clouds, or you may need to revisit your data model. Either way just getting that little green light to come on within your screen may prove your current API is valid, but I'm guessing that, the API may change a little bit once you continue on in your efforts.
So if you made it this far, you have an open mind and we can continue our discussion...so let me say this, is there a place for TDD? Abso-fricky-lutely I just did a little effort that was really built as more of a test concurrent type of development effort, but it's almost the same thing. This was a very complex process where we had a disconnected database on a remote device that synchronized with a server. We had to create some new "stuff' on the device that all needed to work locally before we could talk to the server. No problem you say right? Well where it gets interesting is the fact that the server uses integers to establish the relationships between the tables, that means if I create a new record on the device, I can't use an integer as the primary key, because that will only be available once we look at the identity column on the server database. We need to build up all our referential integrity on the device database using Guido's then replicate those changes back to the server, create the "real records" send those "real records" back down to the device and make sure all our relationships are still happy. For about the past year, I've been very happy using NUnit, however the client I'm building this for uses VSTFS so built the testing using this technology...really about the same thing, just slightly different syntax. My new favorite little utility TestDriven.NET works like a charm with both. So anyway, I was able to create some really nice scenarios that create the item on the device, add this to it, add that to it, change this, change that, then synchronize with the server and make sure the data I had on the device was the same as after I synchronize.
Another awesome experience I had with TDD was the development of a binary serialization algorithm for DataSets. This I did as a pure TDD experience, I built my tests for the different data types I needed to serialize, then I created the methods and work on this until each of the unit tests passed.
My other experience wasn't so much with TDD but more of a formalized Unit Testing via NUnit. I created a VB.NET ASP.NET 2.0 application, with about 150 unit tests, I'm not sure I gained a ton in development efficiency, however it did same my rear-end a couple times with my build cycle. As part of the continuous integration environment that was in place for this project, we ran the unit tests, if they didn't succeed, we knew we shouldn't deploy. Worked out slick and once the test were built it worked for "free" so that was kind of nice.
So what's my final opinion on TDD? Well just as in anything moderation...and finding the right tool to solve the right problem. I'm not convinced you need to write a test case to make sure the set and get properties work on your business objects, however if you have a complicated workflow, it is certainly worth the investment in time.
-ec