Speaking at SD Expo

This year I will be speaking at SD Expo on a topic I spent a lot of time on the topic in the last couple of years: Testing with databases. This remains a very controversial topic for the TDD crowd it seems. One point of view is that you shouldn't involve large external systems like databases in unit tests at all. Involving a database in the test introduces uncertainties into the test environment that can lead to false negatives. Then there's the issue of test performance. If you access a database in your test suite, it will run much slower than if all the objects are created in memory, on code. To accomplish a db free test suite requires a major commitment of an architecture that can substitute object construction away from the live code that would use a database with test code that doesn't. Then you still have to test the code that connects the live configurations to the database. The value of doing all this is where the debate starts and seemingly never ends.

Another point of view attempts to make the database part of the test suite as painlessly as possible. What the effort really comes down to is being able to maintain a stable starting point for the database before each test that can't be messed up by the tests itself. There are different approaches to this and I have outlined some of them in an earlier post here. I have also written a section for an upcoming book by Jimmy Nilsson on the topic and much of what I present at SD Expo will be based on that text. If you are in this camp, you also have to accept some hard to beat limits on how fast the full test suite will run, but there are some ways to help there too. Fortunately there are metrics to help you decide what is and isn't practical.

Testing with databases is controversial for the non TDD crowd as well because that group seems pretty stuck in the idea that testing is something that QA does. QA testers often have few tools, less skill than developers with which to reset the results of earlier tests, verify outcomes, less access to systems, etc etc etc. The result is dramatic increases in testing and iteration time.

I hope people that come to my session will come away with a sense of the choices and trade offs to help them make the best choice for them and their unique circumstances. There seems to be a nearly religious fervor around this topic in some circles but I really don't think the trade offs are that hard to evaluate. I'm really looking forward to doing this and I'm guessing that there will be lots of good questions raised that will help illustrate the topic. I'm also hoping to meet more of the virtual TDD community while there.