@Nisar:

If I were as single-minded in my pursuit of completeing the series as you were at asking if I plan to continue it, I’d be long-since done with it by now 😀

Seriously though, the next installment is already half-complete and the other half is on-tap to be recorded this evening so its nearly here…!

@Jorge:

I’d encourage you to give NDbUnit a try again — the FK fixes I have incorporated go a long way to making it useable for real-world work.

The single biggest advantage that I see to NDbUnit over the traction-rollback approach is that NDbUnit also provides a simple way to manage seeding the DB with the expected data before the test is run and because different data can be pre-loaded before specific tests or groups of tests, things like asserting that a select really returns the proper set of records are simple and consistently pass or fail.

The transaction-rollback approach solves the “undo-the-delete-all” issue, but doesn’t provide an easy way to address the very real need to have “known data in the DB” before each test. I’m curous how you are presently handling that need; can you advise in more detail?

Re: using VS to create the dataset XSD file, in my screencasts you may have seen me demonstrate that appraoch because its the simplest to show others but in the real-world we actually leverage the MyGeneration open-source code-gen templating engine to create the XSD file(s) for us so that we don’t have to bother ourselves with the (significant) annoyance of the VS .NET Dataset designer’s quirks (including its seemingly unquenchable thirst to always add a default DataAdapter to every table over and over again 🙂 ).

If you do decide to take another look at NDbUnit, I’d be interested to hear your take on the update(s) and thanks for the comment!

@Jorge:

No experience with Liquibase but I googled it as soon as u mentioned it and took a look. At first glance it looks to me to be a lot like migrator.net and others that provide similarities to Ruby-on-Rails ‘migrations’ although some kind of IDE and also a DB diff engine would seem to differentiate it a bit from those others that seem to lack those features. Can you compare it to any experience that you might have with some of thoes other classes of tool?

Also, am I understanding that Liquibase also stores DB *records* in its xml files or just the DB schema? Is that how you are loading content into your DB to support your tests or are you using some other method for that?

Re: MyGeneration, I *did* actually demonstrate its use in the Summer of NHibernate series when we explored slaving our object model to the DB schema although that wasn’t speficially about generating XSD files.

@tab:

For the creation of the XSD there are two basic ways that I do this: using the .NET dataset design surface if I want to quickly select one or two tables from a larger set or via MyGeneration templates if I want to produce XSD for the entire DB quickly. There is a template that ‘ships’ with the MyGeneration download that does dataset XSD creation quite capably so we didn’t have any need to author our own.

For the creation of the test-data XML files, *sometimes* I will in fact create them ‘by hand’ since once the XSD file is created and referenced into the XML file the VS XML editor will provide intellisense based on the XSD schema definition file, making this approach feasible where it otherwise wouldn’t be so in cases where I need only a few records to support my present testing.

The other way I typically work is by using the database itself (usually via tools like the SQL Server Enterprise Mgr, etc.) to enter sample data directly into the tables. This can obviously ‘protect’ me from violating FK constraints and other in a way that typing in the XML directly cannot. Once this is entered into the DB, I use NDbUnit to persist the DB contents to an XML file. You can use ‘naked’ NDbUnit for this but in my UnitTest Utility library there is a convenience method of the DatabaseUnitTestBase class called SaveTestData() that makes this operation trivial (you just ensure the properties of the class are set to the right XSD and XML filenames, invoke the method, and it orchestrates NDbUnit as needed to persist the DB contents from the tables contained in the XSD to the XML filename you specify).

Remember that NDbUnit’s operations on your DB are controlled by the tables that exist in the XSD file that you direct it to for any given test cycle. Rarely do I create XSD (and accompanying XML) files for my entire DB at once — the 90% use-case is that I create XSD files and accompanying XML test data files on a test-by-test (or at least testfixture-by-testfixture) basis ensuring that I am only interacting with the part of the DB that I ‘care’ about for any given integration test.

Hope this helps some,

-Steve B.

@tab:

Interesting — I hadn’t actually even considered the “select … for XML” approach~! I actually meant entering the data into the DB tables directly then invoking NDbUnit methods to create a dataset from that data. I don’t think the “…for xml” T-SQL construct produces 100% valid XML for a dataset (and that’s actually what is needed since NDbUnit uses the dataset’s intrinsic .WriteXML(…) and .ReadXML(…) methods to get data in and out of the .XML files it uses.

The utility class I mention isn’t part of NDbUnit per-se (sorry!) its a set of utilities that I have written to abstract a lot of the messiness of dealing with NDbUnit away from test-authors by providing a base class from which u derive your testfixtures when you want them to be NDbUnit-enabled with a minimum of fuss. For details, see this post…

http://unhandled-exceptions.com/blog/index.php/2008/10/09/unittest-utility-library-update/

@Zeljko:

Yes, there aren’t (presently) any binaries posted for release as the 1.2 release isn’t ‘baked’ just yet. For the time-being, this means you need to grab the code from the SVN repository (trunk) and build it yourself.

My intent was to post the 1.2 binaries for download once that release was fully-baked but your question here perhaps points out that I should really post binaries from every build/check-in whether it represents a ‘release’ or not just for people’s convenience…maybe I’ll take a second and do just that later today…