Unit testing using the NDBUnit framework
I am writing block tests for an application that has matured a lot over time. We use NDBUnit as test cases become independent of each other. At the time we started developing this application, the DB schema was quite manageable and hence dragging and dropping tables on the VS Designer to create XSDs was never a problem. Well, with my current DB schema, the XSD that is generated is over 3MB in size. On a slow dev machine, VS shuts down when you try to open the XSD. Hence, keeping the DB schema and XSD in sync has become a very difficult task. Is there a way to get rid of the manual XSD change step? Do you think I should consider other unit testing frameworks? Spring.Net will certainly give me what I need, but we don't have interfaces and so the integration will be a tedious task.
source to share
If you manually use the Visual Studio Designer to create XSD files in production, you are probably wrong :) As you discover, the Visual Studio XSD Designer is probably the least manageable way to save your XSD files.
I would recommend doing as I did and switching to the MyGeneration code generation tool to generate 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 note that while I have demonstrated the use of the NDbUnit tool in these scenarios by pushing the entire database into one XSD file, the intended real-time usage pattern for the NDbUnit tool is to use multiple XSD files as needed to support different tests. database-dependent.
Since the content of the XSD file (s) governs the "area" of your database that NDbUNit will run at any given time, the purpose of this tool is that you will have many different XSD files for different of your data-dependent tests and that you carefully studied tests, XSD and test data (XML) so that they all closely correlate with each other for different collections of tests.
Your entire database is represented in a single XSD file (especially when that XSD file gets close to 3MB!) Is almost certainly an anti-pattern and must be the reason why you probably don't think about your tests or your test data enough in a granular manner to be effective.
If you cannot efficiently load data into only a subset of the tables in a database without breaking referential integrity rules, you may have to fix a database problem. just like one single god object is an anti-pattern in OO design, just like one monolithic database with referential integrity constraints in many places that only when EACH data table is loaded can records be inserted (forcing you to test all at once, as it sounds like you can here).
Finally, as a quick point of order in the interest of clarity, the NDbUnit project is now and always open source and completely independent of Microdesk. While I was working at Microdesk the company did use this tool and I spent my extra-venerable hours creating the project, but Microdesk was only one company that adopted this tool and therefore it is completely wrong to refer to NDbUnit as "Microdesk" NDbUnit Framework ".
Hope this helps ~!
source to share