Right from what I can gather from skim reading that article is that it's mostly call assertion and there are no tests around queryable results. IMO these tests are pretty meaningless and more over when you start putting in meaningful tests it wont work because Linq-to-sql is not mockable, DbContext is not mockable, can't use pocos, etc. This article was written in 2009 and Linq-to-sql is not a current product.
How big is the project? If at all possible move to EF6 and utilise either IDbSet
to create a FakeDbSet
or Mock the DbSets
themselves and alot of the methods are virtual now. Have a look at this Q&A:
How are people unit testing with Entity Framework 6, should you bother?
If you search for Unit testing EF6 you find what your're trying to achieve much easier.
If you really can't change the Ling2Sql then use a façade pattern and compose you DbContext inside this. The façade would expose the DbSet
are IQueryable and wrap up any method calls. This means though that you would have to create methods and properties that are virtual
and then you can mock the façade. Alternatively you could also create an interface for the facade which you can also use for mocking. This would make any complex queries you write completely testable but you are creating code that calls other code. You would also have to watch the lifestyle of the façade as this is newing up the DbContext. This pattern is used to get round testing where AppSettings are involved, it's the same thing really. You just creating something that is mockable as a wrapper for something that isn't.