Even though I’m still a Unit Testing luddite, I’ve been looking around to see how people are getting LINQ to SQL and Entity Framework to work in their Unit Testing scenarios even though neither technology is really built to test against well.

First, I found this excellent post by Ian Cooper that explained not just unit testing, but what makes code apprpriate for unit testing. This was really enlightening for this newbie  (that is, moi) and gave me a much better understanding of why the TDD guys have been so frustrated wtih Entity Framework – although it is absolutely evolving in a way that will satisify them (more likely V2, then V1 though).

Ian also was able to find a way to do Unit Testing with LINQ to SQL.

Then I headed back over to Danny Simmons’ blog for this recent post on some key tweaks to make to the EDM (and codegen’ed classes (and now my brain knows enough to say “uh oh… codegen…that’s a problem for Unit Testing!”) work with Unit Testing.

Then I started playing with VS2008 to get a feel for how the tools enable me to do unit testing when have zero experience. I had give in and read through documentation (I know , how lame and lazy am I?) after I spent about 1/2 hour searching for a screencast or webcast on the topic. But I got some of the basics and figured out debugging, but still have some definite quandries! (Such as why do I get a failure when the expected value is 10 and the actual value is 11, but I get an inconclusive (rather than a pass) when the expected value is 10 and the actual value is 10?) I have a lot to learn! 🙂

I found Chris Buckett’s post on shoving EF into vS2008 Pro unit testing which helped a lot, mostly because he already understands unit testing and therefore understands what challenges he needs to solve when working with entity framework objects. The biggest issue about unit testing data access modules is that you don’t necessarily want to hit the database each time. to this point, Chris is trying to create a mock provider to emulate the database calls made by Entity Framework. Another issue is that you need classes that are instantiated without parameters. So while Danny tells us the simple trick for getting regular classes to fit into unit testing (in the above linked post), Chris is struggling with how to create an ObjectQuery return without instantiating an ObjectContext because the latter requires parameters. (Surely, I’ve gotten some bit of my interpretation wrong in a way that is making you TDD pro’s cringe, but I’m trying! :-))

I am happy to sit by the sidelines while he comes up with the model. (Subscribed)

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!