Now that I have updated the NDbUnit library to support SQLite and SQLCE database targets, I have also just updated the Proteus UnitTest Utility library to offer support for these DB types in its wrapper around NDbUnit.
The new (latest) release is available from the Google Code Site or as a binary download or as source code, your choice.
As I see it there are just 2 small blog posts on proteus project and no other resources anywhere on the web. No examples, etc.
I suppose the lack of db testing tools can be explained by the hatred that xp folks have for db testing and the distain they have for data access and Sql (vs. their love for ORM and object databases).
However. A blog post telling me why I should use proteus rather than NUnit would be nice. Likewise some indication of whether I can use proteus without NdbUnit might encourage me. I don’t like what I’ve seen of NdbUnit; ‘DataSet’s went out with the dinosaurs.
Thanks for the questions. A few thoughts…
1) Proteus contains TWO separate binaries, one in support of easing some recurring unit testing challenges (both with and without databases involved in your unit tests) and another in support of simplifying your domain modeling process.
2) The unit testing-support binary DOES take a hard dependency on NDbUnit, but that’s by design. Part of the services it provides is a simplified abstraction atop NDbUnit, so by definition it requires NDbUnit.
3) I don’t completely understand the ‘Proteus vs. NUnit’ question; the unit testing support provided by Proteus takes no position on your choice of unit test framework; Proteus is desgiend tot work with NUnit, MbUnit, xUnit.net, CSUnit, or even without ANY unit test framework if you choose. The unit testing parts of Proteus are about making using NDbUnit to manage your database state a simpler proposition by enouraging you to follow conventions that Proteus supports, not about affecting your choice of unit test framework.
4) re: the use of datasets, NDbUnit leverages datasets b/c its the lowest-common-denominator of ADO.NET construct that can represent both the database schema and its data in .NET. NDbUnit needs a common way to represent both schema and data in many different database platforms (SQL Server, Oracle, MySQL, etc.) and AFAIK .net datasets are the only thing that fits that bill — if you could recommend another approach that’s less ‘dinosaur-like’ 😉 I’d like to explore that option b/c I have no love of datasets either. But there’s no debating that a) they work with all ADO.NET-supported DBs and b) they are here to stay. All MS data access technologies since the DataSet (Linq2Slq, Entity Framework, etc.) have consistently demonstrated that they are interested in supporting MS-only database targets and I firmly believe there is value in supporting more than that with NDbUnit.
5) I really don’t understand the distaste for DataSets in NDbUnit as its not like you have to write code to interact with them and their existence is really ‘beneath the hood’ in NDbUnit rather than ‘in your face’. FYI, whether Linq2Sql, Entity Framework, or one of the more ‘modern’ [sic] MS data access technologies, they are ALL eventually translated to ADO.NET dataprovider constructs under the hood — also quite the dinosaur technology — but you needn’t care b/c this is abstracted away from you. All NDbUnit requires of you re: datasets is that you use the VS dataset designer to inform NDbUnit of your DB schema structure and that doesn’t seem to me to be that large a burden on people.
6) If you don’t like NDbUnit (for whatever reason), can I ask what alternate approach you are using to manage your database state during database integration testing–? I’m always interested in how others are addressing the same issues NDbUnit is designed to resolve.
7) For details on how to use Proteus to support your unit testing (and your domain modeling), visit http://www.autumnofagile.net and watch some of my screencasts there; the concepts behind it are presented in those screencasts in support of the application that I’m building there.
Hope this all helps~!