I know the Unit Testing drum has been beaten for years, so instead of getting on a soap box and berating the Internet for not Unit Testing, I’m going to give you a story about a recent project I worked on, and how unit testing helped me succeed.

It all started last fall when I started work at a new client’s office. I opened the project from VSS and red flags started popping up. The first red flag was that this was a Visual Studio 2005 project and I was using Visual Studio 2008 (they did not install VS2005 on my computer), but this wasn’t really a problem – I was assured that they had standardized on Visual Studio 2008 now and the .NET Framework 3.5. The second red flag was the five projects in the Solution that couldn’t be found in VSS – each one ending with .Tests. I still don’t know why they were removed – but my guess is that they were removed because they didn’t pass.

The first thing I did was create a new Unit Test project. After examining source code thoroughly I created a test harness of unit tests of the existing functionality of the project. This is a very difficult and risky task since these tests are built under the assumption the current code works correctly! This is not a safe assumption when projects are missing from the solution. However, the fewer behavior changes I introduced to a program already in production use the better.

During this period (probably one week) I uncovered and fixed many bugs. I re-factored a lot of code. I did more testing.

Then I added my new functionality, retested and it worked.

I added more tests. They went from red to green.

My confidence grew with each little green light.

I added integration tests to the unit tests. These all passed.

Eventually the program was ready for deployment to the testing server (UAT – User Acceptance Testing) – a model of the production environment. And I was confident! My tests were passing!

This is when everything went wrong.

The Problem? Updating to the .NET Framework 3.5. Of course I had been misled when they assured me that they standardized on 3.5 – the production environment was still very much in 2.0 (and I was strongly assured they would not upgrade – even though I hadn’t asked).

The Solution? Unit Testing! I had extensively used the new productivity features of 3.5 like LINQ and Extension Methods. It took some rewriting and work but I was able to revert and rewrite everything back to 2.0 compatibility in one afternoon! The only reason I could do it so quickly was the unit tests I wrote that told me the functionality was still there and working in the old Framework. It took more time to find another computer with Visual Studio 2005 and the .NET Framework 2.0 installed (and not the 3.5 installed at all) than it took to rewrite the app to the older framework version.

There were more problems that were solved with more testing, but Unit Tests saved me a lot of time and guessing. There were some other things that could have made the project more successful such as better communication with other developers and the production team. Those issues were beyond my control. But I was so glad I had those unit tests, they saved my bacon. They gave me confidence in the completed software. The Unit Tests were also something I could show my client, the maintenance teams, and the testing teams in terms of functionality assurance for them.

Ah success! A new project! Another Solution! …and guess what? No unit tests. *sigh* Here we go again!

XML Files

Most of the ORMs I’ve used required a lot of configuration in XML files. Probably the worst offender in this sense is NHibernate. L2S, EF and DataSets are bad too, but at least they have tooling in Visual Studio to make it easier to use and hide the XML from you. In this respect, the Fluent NHibernate project is a life-saver for anyone using NHibernate.

POCOs and the Repository Design Pattern

Another thing most ORMs provide you with is an ability to use simple POCOs or Plain Old CLR (or C#) Objects. Ordinary DataTables and Strongly-Typed DataSets come with a lot of extra “clutter” to them, this is especially visible when you’re interacting with them using IntelliSense inside Visual Studio. The clutter appears as all the baggage that comes along with DataTables, as well as the fact you have to use DataAdapters, and fetch row objects (i.e. UserTableRow).

It is really nice to just have a simple class that can do what you need it to within the “domain” (following the Domain Driven Design ideas). It simplifies your data layer model significantly, and of course reduces a lot of clutter.

NHibernate and SubSonic are the clear leaders here, NHibernate even more so, but SubSonic can regenerate mappings after you’ve made changes to your database.

Simple Database Schema Creation

Another thing I like to see in an ORM tool is the ability to take your data-layer mappings and generate a database schema from that. The primary reason is that database versioning during development is hard. Keeping everyone on the same page with databases is difficult and making each developer use the same database is hard to impossible. If your ORM can just create and/or update your database schema for you off the bat, keeping each developer up-to-date is a breeze. No more “why is my app crashing?”, “where is that SQL script?”, “who did this?” shouting over the cubicle walls, instead you just run the update scripts and you’re all set.

As far as I know there is only one clear winner here and that is NHibernate; L2S, EF and Strongly-Typed DataSets don’t have this functionality at all. I believe that the 3.x version of SubSonic does have this now, and version 2.x had a version of migrations (that may be obsolete in version 3).

My Pick for Best ORM

I’ve personally switched from the SubSonic camp to the NHibernate camp in the last year. With Fluent NHibernate and guidance from the S#arpArchitecture projects all real difficult barriers into NHibernate have fallen. SubSonic is an awesome ORM and does help you get up to speed quickly, but it does feel like it isn’t developer or maintained quite as much as NHibernate is, and the differences between 2.x and 3.x versions was so great as to almost be intimidating to me (almost)!

Entity Framework is good, but I’ve had problems with the tooling and updating the mapping schema in the projects I’ve used it in. To me, there is very little programmatic difference with Linq-to-SQL, in fact EF seems to have more functionality. According to what I’ve read, it will have Database Schema Generation in the .NET 4.0 version, but NHibernate 2.1 already has LINQ support (via another library) so EF is really still just playing catch-up.

Strongly-Typed DataSets are pretty much an obsolete technology as far as I’m concerned – from the .NET 1.0/1.1 days. They do provide some simplification over bare metal ADO.NET, but I don’t find them as easy to use as NHibernate or any of the other ORMs I’ve discussed so I’ve seen little benefit in modern projects.

Summary

While I know there are more options out there than just the ones I’ve pointed out, NHibernate is the tool that best represents what I’m looking for in an ORM.

I didn’t actually speak to the developers myself, but my friend sent me an MSN transcript of their “discussion”.  Apparently tempers grew quite hot!  I did read most of the discussion and spoke with my friend to learn more about the system.

It turns out there would be many transactions with the database and web service coming from these devices with a fair bit of geographic data that had to be processed at the server.  One developer felt that using a web service would  involve too much XML/SOAP overhead and wanted to write his data as XML to the database directly.

I was not in favor of this suggestion.  A web service makes perfect sense in a .NET situation.  It denotes a logical boundary between applications and computers, and would be pretty obvious to any supporting developer what is going on.  Usually two applications do not share the same database (maybe the same server, but not the same database).   This increases complexity.

I was also not convinced that the “overhead” of the SOAP would actually limit the application.  Microsoft has done a lot to optimize web services.  They’re easy to develop now, easy to consume, and as I said: a logical boundary between systems.

In the end I strongly recommended that they do some benchmarking.  This early in the game is the perfect time to test assumptions.  I also recommended using one of the new Service Bus APIs out there that use technologies like Microsoft Message Queues if the web services are too slow.

Also, as Jeff Atwood recommended in his Coding Horror blog, sometimes it is cheaper to throw another $5000 server at the solution (even TWO servers) instead of paying two $70,000 / year developers to spend three-to-six months doing performance enhancements.

NHibernate is documented better than I originally thought if you look at nhforge.com, not at the hibernate site.  It also does some nice schema generation based on your mapping.  You still have to go through “XML Hell” to map the site, unless you use another mapper or FluentNHibernate (which does the mapping for you in code) or another tool.  As an ORM SubSonic feals cleaner and quicker since it generates the ORM classes from the database, where-as NHibernate generates the Schema from your mappings and ORM classes.

Generating the schema in NHibernate, even with Fluent-NHibernate, seems to take more work than generating the classes in SubSonic took.  However, it’s still quite simple.

Better support for Oracle was one of the primary drivers for me using NHibernate for this project, but after making the switch I’ve found a lot more interesting stuff, including an exciting ecosystem of NHibernate addins, plugins and updates.  I think it really appeals to the gadget geek in me.

The other thing that kept me thinking about NHibernate is the sheer number of other blogger / developers out there are using NHibernate!  After I started looking I was surprised to see how many blogging developers actually used NHibernate for their projects.  So not only do I feel like I’m in good company right now, but there are also a lot of people out there with good advice on best practices.

So, I’m taking another look at NHibernate right now, and I might post on it again later!

In the .NET world there are two powerful ORM tools out there, NHibernate and SubSonic.  NHibernate is based on the successful and popular Java EE ORM Hibernate.  SubSonic is an entirely new ORM developed in the Ruby on Rails ActiveRecord development model, with some nice .NET 2.0 features like Controllers that you can use with ObjectDataSource controls.

For a recent project I quickly evaluated both software tools, and I’m publishing what I learned here.

Setting up NHibernate:

The NHibernate Object/Relational Mapping is setup using XML files.  If you’re using the 3.5 Framework you can use a fluent interface instead (i.e. code the mapping in C# instead of XML).  I didn’t find a tool that generated the XML or interface automatically for you, but there must be one out there.

Changes to the database require changing the mappings, which means digging through XML.

Setting up SubSonic:

SubSonic mappings are generated via an external tool called SubCommander run from the tools menu.  Any changes to the database require regenerating these mapped classes.  SubCommander connects to your database, reads the Schema and generates O/R classes.  The O/R classes are Partial classes in C# so that you can create methods for the classes that won’t get overwritten by the tool each time you write it.

Changes to the database require re-running SubCommander (which can be done via the IDE).

The SubSonic team has also come up with some great videos to help you get started.

Migrations

The big thing that sold me on SubSonic was the new Migrations feature.  It uses a Ruby on Rails style migrations tool to help keep your database versioned.  It’s really excellent for a first generation tool.  It’s missing a few things, like it’s hard to set Unique Keys, but otherwise it is excellent.  This is also the first .NET Migrations utility I’ve found.

Migrations are one of the easiest ways to keep your database versioned, which has always been a problem for me when updating Test and Production databases.

Conclusion

I ended up selecting SubSonic for the following reasons:

1. No XML configuration files (running a tool is much easier, IMHO)
2. Migrations
3. Their excellent video tutorials and directions on their website

StringBuilder sb = new StringBuilder(256);
UTF8Encoding e = new UTF8Encoding();
MD5CryptoServiceProvider md5 = new MD5CryptoServiceProvider();

into this:

var sb = new StringBuilder(256);
var e = new UTF8Encoding();
var md5 = new MD5CryptoServiceProvider();

His point is that declaring the type as StringBuilder and then assigning it a new StringBuilder is redundant – StringBuilder appears twice on that line of code, before and after the assignment operator (=).  He makes an excellent point because the example using var is far more concise than the original example.  Furthermore, we should be more interested in what is being assigned than what we’re assigning too (at least on that line of code).  I find when I read the first block my eyes stick on the left-hand side of the assignment, but in the second example I read the right-hand side code instead.

As a side note. the excellent tool ReSharper 4.0 suggests using var for every local variable declaration by default.  It’s one of the first things I changed in ReSharper when I started using it.

You see, I don’t entirely agree with using var.  Using var is fine, but we aren’t converting C# into a dynamically typed language like Python or JavaScript – C# is still statically typed, using var just forces the compiler to figure out the type you’re using, usually based on the first value assigned to it.  In Python or JavaScript I could take sb from the above example and assign to it the UTF8Encoding() object reference on the next line, but C# won’t let you do that, the compiler will give you an error.

I don’t like the illusion, so where possible I will use var, but I’ll keep using types too when necessary for clarity.

In practice here is what I did:

var currentOperatorFacilityIds = from fac in Facility.Facility.ListAllForOperator(this.OperatorId) select fac.ID;
var deleteOperatorFacilityIds = from fac in Facility.Facility.ListAllForOperator(operatorId) select fac.ID;

var commonFacilityIds = currentOperatorFacilityIds.Intersect(deleteOperatorFacilityIds);

Really simple!  I love LINQ.