Bill Caputo has a wonderfully clear explanation of how to address questions regarding using TDD at system boundaries.

TDD is fundamentally about writing tests (or 'checked examples' as Brian Marick calls them) before you write the code. One of the benefits of this is that the resultant code is decoupled from the rest of the system. This becomes particularly important when the code is near a boundary (e.g. acesses a database, a queue, another system, or even an ordinary class if that class is "outside" the area your trying to work with or are responsible for).

However this benefit doesn't just happen, you have to want to find a way to structure the code so that it can be tested without resorting to resources beyond the test.

[via Bill Caputo]