It uses an example every web/application programmer is familiar with: ye olde Shopping Cart.

A Catalog interface is used which decouples the database from the shopping cart code. That way you can test your code against the Catalog interface (using a simple implementation sans external/database dependencies) before worrying about the database (which is rightly dismissed as 'infrastructure').

You only directly test the database using DBUnit, or DBI/JDBC mock objects (my preferred option), or whatever, when you implement a Catalog that uses a database.

I'm not trying to say that testing the database is easy. Quite the opposite, external dependencies seem to be a total bitch. The point is that its not necessarily something to get hung up on when you're writing ShoppingCart. This has been a problem for me whenever I have tried to introduce unit tests to my projects, but I think this advice will be helpful next time I try.

(Yes, the article is about Java, but I think databases_and_testing issues are mostly language-agnostic. The rest of the article has decent advice on testing issues as well.)

Also, the testing weblog where I found this article is excellent.