Am writing unit tests for an app that has matured a lot with time..We are using NDBUnit as the test cases become independent of each other..while we started the development of this app the DB schema was pretty manageable and hence dragging and dropping the tables on VS designer to create an XSD was never an issue. Well, with my current DB schema the XSD that is generated is more than 3MB in size. On slow dev machine VS goes off to sleep when one tries to open the XSD. Hence keeping the DB schema and the XSD in sync has become very challenging. Is there a way i can get rid of the manual step of modifying the XSD? Do you suggest that i should consider other unit testing frameworks? Spring.Net will definitely give me wt i need, but we don't have interfaces and hence integrating it will be a tedious task.
If you're manually using the Visual Studio designer to create your XSD files in a production environment, you're probably doing it wrong :) As you're discovering, the Visual Studio XSD designer is probably the least-managable way to maintain your XSD file(s).
I'd recommend doing as I have done and switch to the MyGeneration code-gen tool to create your XSD files from your database.
Info: http://www.mygenerationsoftware.com
Download: http://sourceforge.net/projects/mygeneration/
XSD Template: http://www.mygenerationsoftware.com/TemplateLibrary/Archive/?guid=59a03408-c96f-4baf-8171-b6bfe8725dab
Also, you should take careful note that while I demonstrated the use of the NDbUnit tool in those screencasts by brute-forcing the entire database into one single XSD file, the intended real-world usage pattern of the NDbUnit tool is to use multiple XSD file(s) as needed to support your different database-dependent tests.
Since the contents of the XSD file(s) control the 'scope' of your database that NDbUNit will operate on at any one time, the intent of the tool is that you would have many different XSD files for different of your data-dependent tests and that you would carefully scope the tests, the XSD, and the test data (XML) together so that they all closely correlate with each other for different collections of tests.
Having your entire database represented in single XSD file (especially when that XSD file is approaching 3MB!) is almost certainly an anti-pattern and should be cause for you to consider that you're probably not thinking about your tests or your test data in a granular-enough way to be effective.
If you cannot effectively load data into just a portion of your database tables without violating referential integrity rules then you probably have a database design problem to address. just as one single god-object is an anti-pattern in OO design, so too is one single monolithic database with referential-integrity contraints in so many places that only by loading EVERY table with data can records be inserted (forcing you to test the whole thing at once as it sounds like you may be doing here).
Lastly, just as a quick point-of-order in the interests of clarity, the NDbUnit project is now and has always been open-source and completely independent of Microdesk. While I was employed at Microdesk, the company did make use of the tool and I did spend my off-hours contributing to the project, but Microdesk was just one company that adopted the tool and so its completely erroneous to refer to NDbUnit as 'Microdesk's NDbUnit Framework'.
Hope this helps~!