How DTS can assist your automated unit testing

The reason I blogged earlier about Yukon DTS is that, as part of my build, a database is created and DTS loads up the data. This is handy, but the approach can be expanded to help with unit testing.Each time a unit test is run the data should be restored to a known point so that unit tests (and the order they run in) don`t affect each other. DTS can be called to keep reloading the data.On larger projects different developers or teams of developers may have completely different sets of test data to one another to support their different tasks. Just as likely is that different sets of tests require a very different set of underlying test data. DTS can be used here to delete/truncate tables (if that is quicker than rebuilding the database with DDL) and load up different sets of data.That is why, in my previous post, I am manipulating DTS from the command line to use data files in a configurable file location. Therefore each developer, team etc. can have a series of their own folders in source control (alongside their unit tests) containing sets of text files that DTS can be instructed to load into the database before the tests.All of this of course can be orchestrated (too much BTS) from within NAnt.