views:

33

answers:

1

Yet another "simple" question about unit testing model objects that uses data access layer.

When I mock my Table<Customer> to IQuerable<ICustomer>, where new List<FakeCustomer>().AsQuerable() is used in role of in memory data store, the following code passes unit test perfectly:

var filteredCustomers = from c in dal.Customers
                        where c.Code.ToUpperInvariant() == "ABC"
                        select c;

When running app I of course get NotSupportedException (because of ToUpperInvariant()). Maybe it is rather lame example, because problem there can be fixed by replacing ToUpperInvariant() to ToUpper(), but you got the point.

Question: is such inconsistency a "fee" for writing real unit but not integration tests? Or maybe I am doing something wrong, e.g. there should be another way to mock DataContext in a way that fully emulates Linq To SQL DataContext?

Currently I am queuing a test database instead of in-memory mock to catch such an errors.

Thanks for your suggestions.

+2  A: 

Yes, this is precisely the fee you pay for it not being an integration test. It's a good idea to have integration tests as well as unit tests, of course.

It's hard to avoid this sort of problem with ORMs, in my experience - how are you going to emulate the whole of SQL Server accurately without running SQL Server? That doesn't mean ORMs are useless or anything like that - just that there are limitations.

Jon Skeet
Ahh, sorry. I have already fixed "Objects" to "SQL". Friday, was drunk :). Thanks for quick reply and noting to wrong term
Roman
@Roman: No problem. Have edited my answer :)
Jon Skeet