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.