The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

TDD Guidance

We are doing TDD.One of the features involved,is a system action,initiated by a cron.This action,involves,a series of steps,and some of these steps involve touching the database.Now,while writing tests,we are touching the database.Is it against conventional wisdom? Also,how to write tests,for testing, that each step is executed in the right order?
Thursday, September 06, 2007
Most of the TDD stuff I have read kinda falls short of dealing with DB's which is, for a lot of us, where 95% of the action is. There is some stuff out there - DBUnit I think - that purports to deal with this. I looked at it once briefly, it looked like the right idea, but I never actually tried it.
Greg Send private email
Thursday, September 06, 2007
Okay, there are several things here.

The first question is: why isn't your database access isolated into a separate, replacable class? If you do that, you can mock or stub out the database access and test your logic, rather that the DB.

For testing the DB itself, there are several ways to do it. One of my personal favorite techniques is to start a database transaction in your test setup method, and set your initial state. Then your test method does whatever it needs to, and the teardown rolls back the transaction.

This way, your database is always clean when you need it to be.

The other question: are you testing your database access, or are you testing the database itself (stored procs, triggers, etc.) The former is pretty well understood, the latter is still a bit of a mess.

The best discussion of this stuff is currently in "xUnit Test Patterns" by Gerard Meszaros.

Chris Tavares Send private email
Thursday, September 06, 2007
It sounds like you're running tests on your production database.  If so, that's very passe'.

What we've done is created a test database, which is basically a copy of the production database, albeit on a slower machine (when we upgrade the production database, we keep the old server and now use it for test).  We can run any kind of tests we want on it with impunity, because it's not our production server.

About once a month, our DBA repopulates it.  To do that, he basically wipes it out entirely, then does a restore from his latest backup of the production database.  This has the added benefit of testing that the backups of the production database are happening correctly.
Michael G Send private email
Thursday, September 06, 2007
There's no point in being dogmatic about this. If it is working for you and the database data does not change then why add any more overheads?

If you are writing to the database you can use (and probably are already using) something to rollback it back but that's it.
JSD Send private email
Friday, September 07, 2007
If your data arbitrarily changes once a month (eg. due to the DBA backup) then I don't see how you are doing any sort of real scripted testing.
Greg Send private email
Monday, September 10, 2007
Unless your database is immense, you should be able to load a test database in a few seconds.

One problem with using the production database is that you can't get the strange situations you need to test your logic in the application.

You either need to create a testing database when the tests are run or else use "mock objects" and simulate the database through an isolating access layer.
Monday, September 10, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz