Friday, August 08, 2008

MXUnit 1.0

I've been remiss in my blogging! I don't have a single entry about mxunit. The project seems to be going really well thanks to the dedicated work that (theguys at mxuint dot org) are doing (yours truly is probably the biggest slacker of the bunch).

If you haven't looked into test driven development, here are a few links to get you started:

A good readable book to get the juices flowing: Test Driven Development: By Example
The mxuint website
The mxuint blog
a good online reference

Now that mxuint has made it's 1.0 debut, there are a lot of interesting thoughts floating around the group regarding what we can do next. For me, I think the most compelling idea is that it would be nice to be able to use the same framework to do other sorts of testing. In particular, finding some strategies for testing THROUGH the database and pushing into the area of functional testing.

The db problem is a tricky one since in order to write good tests for that, you need to have your database in a known state for each test. A lot of people persue the mock strategy, but to me, that only gets you so far. A lot of my apps have a great deal of logic in the db itself which mocks short circuit. Use of transactions would seem like a good idea, but the devil is in the details. Screw up a rollback and your db could wind up in really bad shape. I like the use of a backup/restore strategy, but performance can be a big issue as well as database locking. Oh, and forget about running it against a shared development database. Hopefully we'll get something nailed down to help with this, even if it's just a set of processes you can implement.

Functional testing is where the real fun comes in. Scenario and output testing can take so many forms that it's going to be fun to tackle some of that. If you have any thoughts on what you would like to see here, make sure you post them over on the mxuint blog. We're still gathering thoughts on the subject, so it would be nice to see what everyone is thinking about.

1 comment:

  1. DB testing is tough. I use Ant to to run scripts to reset my db to a known state. And we test on a dedicated testing server - not on our development server so there is no impact on other users.