@Simone:

Good point about that first test; thanks for mentioning that — nice catch. I’m pretty sure that the subsequent refactoring of the data provider class in later sessions should have now lead to that test performing the way its ‘expected’ but I will make a point to return to the code and ensure I’m recalling this correctly.

Re: using transactions to roll-back DB changes during unit tests, I am generally NOT predisposed to trust such a thing as its both out of my direct control (e.g. relying on the DB and/or ADO.NET to enforce proper roll-back semantics) and also brittle (in my experience a test that fails in an unpredictable way will often leave me with the DB in an inconsistent state and then I’m stuck going back to restore a backup).

The other reason that I prefer the NDbUnit approach implemented in the screencast is that part of its job is to ensure that KNOWN data is present in the DB when the tests are run. Using this approach I can have all kinds of other (non-test) data in the DB when I want to run my tests, get the expected test-data loaded into the DB, run the tests, and then ‘reset’ my DB to it pre-test-run state so that all my other non-test data is returned at the end.

This approach allows us to have developers run tests agains the DB on their local PC without compromising any other data that they may have in the DB to support their other development tasks on the same project. This way, if the test expects 3 orders in the DB but the dev has 22 orders in their DB becuase they’ve been developing the part of the UI that adds orders NDbUnit will reset the DB to contain the expected 3 orders, run the tests, and then return the prior 22 orders to the DB so the dev can go on about their work with no ill-effeects.

Since NDbUnit is already involved in setting up the test environment (DB) before tests, it only makes sense to me to allow it to also reset the test environment after tests instead of relying on other methods (transactions) to achieve the same thing even if they were reliable.

Hope this helps.

@Scott:

Thanks for the feedback; I’m glad you’re finding value in the content.

I’m not releasing source for the Microdesk.Utility.UnitTest.dll as that’s not (presently at least) open source — its something that I wrote explicitly for my company and so its not really public domain as source even though I have said clearly in other posts here that people are free to use the BINARY version of it (as provided in the code downloads) as they see fit.

As to the NDbUnit source, that project actually IS open source and so the source for this version of it is going to be available soon. Recently, after some neglect, the project was moved to Google Code (http://code.google.com/p/ndbunit/) and I have been made a committer on the project.

Over the past year or so I have make mods to the code and also collected code updates from others who have been involved in patching the code but couldn’t merge their changes into the main line since the project went completely quiet on the ‘main’ website (www.ndbunit.org).

Now I can (finally) fold back into the main release all of these changes (fix for FK ref integrity problems, etc.) Once that’s done (end of the month perhaps?), you will find links to it on my blog and you can visit google code and retrieve the source from there.

However, its not at all clear to me that lacking the source for these should be preventing you from following along in the videos though — you should of course be able to just use these libraries as demonstrated in the video(s) without needing to step into the source code unless you are actually experiencing some bug/issue with either of them (in which case I would encourage you to report that to me so that I can address it).

Hope this helps~!

@Nisar:

This is where we run into some trouble with the fact that these videos are pretty strongly targeted first for internal consumption by our own staff and only secondarily for viewing by the community at-large.

Obviously our own internal staff has already rec’d training on the use of the DatabaseUnitTestBase class to control database setup and teardown before and after test-runs whereas no other viewer would have rec’d the same training, of course.

I’ll try to explain as best I can…

1) The DatabaseUnitTestBase class is a thin wrapper around a bunch of the methods in the NDbUnit library and really adds not a lot of value except in so far as it wraps this stuff neatly up into simple calls like DatabaseSetup() and DatabaseTearDown().

The links in the above post to parts 17, 18, and 19 actually show how this same technique was used by leveraging ‘naked’ NDbUnit calls without the convenience wrapper of the DatabaseUnitTestBase class around them.

2) These methods are provided in the DatabaseUnitTestBase class and so strictly-speaking the answer to this question is a ‘yes’, you need the base class to have these methods.

But as mentioned above, the actual capabilities invoked here are nothing more than a sequence of public methods provided by NDbUnit and so if you familiarize yourself with the use of that library, you could accomplish the same thing as this base class by either writing your own base class or simply calling each of the NDbUnit commands at the appropriate points in your testing. NDbUnit offers a more granular API than I think is most often needed and so where it needs three to four method calls to reset your database, I wrapped that in the single DatabaseSetup() method on our base class, for example.

Re: the source for the base class (and the whole Microdesk.Utility.UnitTest.dll), as I’ve mentioned in other comments here that’s not entirely my choice to make (see comment 17 here for example) but I will see what my employer says to a request to do so.

Hope this helps~!

@Nisar:

Without starting another EF v Nhib flame-war, let me offer my *opinion* on EF v1: DON’T.

The first release of EF has so many shortcomings (ranging from issues with their lazy-loading to no support for SCC merges of your EDM, etc., etc.) that are better solved by other existing software (NHib, but many others too) that unless you are in an all-MS shop (read: no OSS tools allowed), I would avoid EF until v2 (or v3) when they have promised to solve some of these issues (to varying degrees).

As for it (ever) replacing Nhib (e.g., like NHib ceases to exist), I don’t see this happening any time soon — just like the Logging Application Block in the Enterprise Application Block stuff didn’t ‘kill’ Log4Net, NLog, or others I think there is enough difference between Nhib adopters and EF adopters in their approaches, concerns, focus, and other factors that there will remain NHib adopters for quite some time to come. If I didn’t think this, I’d be doing screencasts on EF 🙂

Re: myself, I am currently a Senior Project Manager and Solutions Architect for Microdesk, Inc. in New York City (http://wwww.microdesk.com) where I lead teams of developers in what are typcially consulting-style engagements to produce custom enterprise software solutions based on .NET sometimes focued on general business needs but often focused on CAD and GIS technologies and how these integrate into the enterprise.

In that role, I neither code *nor* teach 🙂 but spend a good deal of time mentoring staff in development methodologies (Agile, SCRUM, etc.), software architecture concerns, and improving techniques for efficient and effective software development. I’m one of the senior developers and generally the go-to guy for issues of software architecture challenges when they arise in a team. I also spend a significant amount of time focused on how we improve our process and procedures to steadily increase our efficiency and our effectiveness as a group. I have a strong focus on the BUSINESS of software solutions consulting as well as the software side of that.

I’ve been using NHib for about three years now, but the story I tend to share is that it took me two aborted tries over a year to teach myself about it before I was successful at learning it and that’s one of the reasons that I started this screencast series and have been making it available to the community at-large; the available resources to learn this stuff on your own tend to be scattered across the ‘net, poorly organized, and often assume you are already aware of all of the CONCEPTS behind NHib when you start to try to read thru most of them.

Thanks again for the feedback.

@Scott:

Sorry if I misunderstood — that’s partly why I couldn’t understand how you might be ‘stuck’ 🙂

I appreciate the curiosity and DO actually expect to be able to at least post the source code for at least the main parts of the Microdesk.Utility.UnitTest.dll so that the curious can get a better sense of what’s going on inside it.

@Erik:

This is indeed one of those areas (speedy mass changes) that OR/M technology in general tends to not be able to (easily) keep up with the performance of ‘raw SQL’ approaches to DML commands.

The only ‘efficient’ way for you to accomplish mass-updates/mass-deletes without requiring the retrieval of all of the data to your local (client) computer using NHib is to pass literal SQL from the ISession.CreateSQLQuery(…) command that exists for just this purpose.

Using the .CreateSQLQuery(…) method you can just pass “DELETE CUSTOMER” and nuke the contents of your CUSTOMER table in one shot or something like “UPDATE CUSTOMER SET ACTIVE=TRUE” to make all of your CUSTOMER rows ‘active customers’. Without this ‘shortcut’ approach, you would indeed need to retrieve every CUSTOMER object, call ISession.Delete(…), etc. on each one in a foreach loop and then flush the session/commit the transaction to get these changes pushed back to the DB (clearly much less efficient).

GENERALLY you want to avoid using .CreateSQLQuery(…) for all but those things that just cannot be efficiently accomplished without it since passing literal SQL is a non-DB-neutral way to communicate with your DB and will tend to tie you to a specific DB vendor’s ‘special SQL syntax’ (e.g., T-SQL, PL/SQL, etc.) but this is MOSTLY ok in the case of mass-deletes since nearly all DBs implementation of the SQL-92 DELETE syntax is mostly identical anyway.

Hope this helps.

@Ryan:

This is an interesting point you make here (generally about UDTs and more specifically about the Geog/Geom types in MSSQL2008).

Up until this ‘core functionality’ of the the platform was exposed as UDTs, I had generally shied away from UDTs in SQLServer as an avoidable evil (this is just my opinion, UDT-lovers out there, I don’t really want to hear from you about this).

But with the advent of 2008 and the core spatial functionality being encoded in this manner, I think I will have to take a look into this. As I think I’ve mentioned in perhaps the screencasts and certainly in my blog, Microdesk does a considerable amount of work in the GIS market and so this is something that we will have to come to grips with, I imagine. To-date, our spatial solutions have all been Oracle-based since it was really the only commerical enterprise-ready spatial database out there (yes, I’m aware of both MySQL Spatial and PostGIS, but these don’t count in many of our client’s eyes and so they don’t count for us either).

In Oracle situations, the SDO.Geometry datatypes are represented in datasets as BLOBS and in objects as byte[] (byte arrays); is this not the case with the geometry types in MSSQL2008…?

We don’t yet have any clients moving to SQL2008 for spatial support though looking into the product is definitely on the agenda and I have seen a number of presentations at various conferences on the spatial support in the product.

I’d be very interested to hear from you what experiences you have had with it; the limited spatial query operators and the lack of coodinate system projection support, no concept of spatially-correlated raster data (AFAIK, would love to be proven wrong) all look like deal-breakers for us in evaluting the platform as a primary-role GIS spatial data store.

@John:

Yes, I sure did but as my request to Simon to send me an e-mail took this dicussion offline (well, off-blog at least since e-mail still counts as online to me), the solution also ended up offline.

Here’s the relevant part from my e-mail response to Simon so that you can see if your issue is the same as his was. If your issue *isn’t* the same as his, please e-mail me ZIP file with your solution (or a smaller test solution that also evidences the problem) along with either a DB backup or (even better, a DDL sql script that I can just run to create a copy of your DB for myself to assist in my testing process) and I will attempt to dig into it for you.

Let me know.

-Steve B.

—Begin E-Mail Excerpt—

The specific error you are reporting is due to (I think) a problem in the way the .NET dataset designer reverse-engineers your DB type when you use the SQLServer ‘tinyint’ datatype for a field. The .NET dataset designer seems to want to assign this to the .NET System.Byte type. You can see this for yourself if you open your Database.xsd file, click on the pkSaleTypesID field in the tblSaleTypes table, and look @ the VS property panel.

The reason that I classify this as a ‘bug’ in the VS dataset designer is that not only do you get System.Byte for the type, you also don’t get the AutoIncrement property as being ‘true’ (I checked your DB and the PK field in the actual DB *is* set to true). This setting being wrong in the Database.xsd file effectively ‘fools’ NDbUnit into thinking it doesn’t need to set INSERT_IDENTITY ON before inserting data into the DB for the tblSaleTypes table. I actually think that we could ‘live with’ the incorrect data-type (System.Byte) being assinged in the dataset xsd file, but the fact that AutoIncrement is set to ‘false’ is confusing NDbUnit. In NDbUnit, we don’t set INSERT_IDENTITY ON for *every table* we insert values into, just those that have auto-increment PK values (because if the PK *isn’t* set to auto-increment, its 100% valid to just insert a PK value right into the table directly so no need to toggle IDENTITY_INSERT on and then off on either side of inserting data into the table when we do our loading of data into the tables).

I’m (reasonably) sure that you selected tinyint as a database size optimization, figuring that there wouldn’t be any need to have more SaleTypes than a tinyint could hold. But the fact that (for whatever reason) the VS dataset designer fails to properly reverse-engineer (deduce) the correct settings for a SQL type of tinyint means that this optimization is really the source of this problem (even if only somewhat indirectly).

So I addressed that issue by simply changing your DB schema (and the related Database.xsd) to use int as the datatype for all the PKs in all the tables. I had to do several since other tables than just tblSaleTypes had tinyint as the PK datatype and as soon as I corrected tinyint in the tblSaleTypes table the next table with it threw an exception, etc., etc. so I stopped and changed them all to int and the error ‘magically’ went away.

For the record, I didn’t really bother to experiment with whether leaving the datatpe as tinyint in SQL server and as System.Byte in the dataset would still work as long as you ‘remembered’ to go into the dataset xsd and flip auto-increment to TRUE for all of these tables every time you regenerated the dataset if/when your schema changed. That might very well work too (and allow you to retain the use of tinyint in the DB) but my guess is that its simpler to just change to int in the DB than to have to remember to always manually adjust the dataset schema in the future all the time. Your choice; feel free to experiment a bit to see if that also might be a viable way to solve this issue; I’d be interested to hear back if you find out one way or the other.

—End E-Mail Excerpt—