Awkward Testability for Linq for SQL
Note: I am writing this post in the express hope that it would help to change the current situation.
I have been just recently informed about a significant problem with Linq for SQL. It doesn't support testing easily. You can see the bug report here, and as usual, it was closed as Won't Fix without even providing an explanation. Did I mention already that I don't like Connect's approach to it? Yes, I did.
The root problem is a fairly simple one. Linq for SQL relies on reams of generated code, which means that if I have code line this:
var customers = from c in context.Customers select c;
Then I have no really easy way to mock what is going on in here. The generated code provides a concrete class without an interface, so it is very hard to mock, and naturally, System.Data.Linq.Table<T> is sealed, has internal stuff, and is utterly hostile to mocking.
You have to use mocking if you want to use the code above without hitting the database, and this is a core part of the way a lot of people work. Linq for SQL doesn't take that into account.
The requirement for mocking aren't really that onerous, we need and interface generated for the context class, and interface for Table<T> and that the generated code will default to using interfaces by default (Best Practices, anyone?).
Having to write adapters classes is something that TDDers on the .Net platform has become very familiar with, because of the insistence of using untestable practices throughout the framework. I am fairly tired of that, and I would certainly like to be able to skip this tiring process for once.
It is shocking to me that in this day and age the Linq for SQL team can still believe utterly ignore such practices and put hurdles in the path of easy testability.
Are we back to demos vs. reality development?
To finish, this bug has been closed, so it is not possible even to vote for it. At the very least, I would like to hear an explanation, and it had better not involved "lack of resources".