[ACCEPTED]-How are people unit testing code that uses Linq to SQL-linq-to-sql
Update:
Fredrik has put an example solution 13 on how to do unit test linq2sql applications 12 over at his blog. You can download it at:
Not 11 only do I think its great that he posted 10 an example solution, he also managed to 9 extract interfaces for all classes, which 8 makes the design more decoupled.
My old post:
*I 7 found these blogs that I think are a good 6 start for making the DataContext wrapper: Link1 Link2
They 5 cover almost the same topic except that 4 the first one implements means for extracting 3 interfaces for the tables as well. The second 2 one is more extensive though, so I included 1 it as well.*
3 years late, but this is how I do it:
https://github.com/lukesampson/LinqToSQL-test-extensions/
No 6 need to write a wrapper or do lots of plumbing, just 5 drop the T4 template next to your .dbml 4 and you get:
- An interface for your data context e.g. IExampleDataContext
- An in-memory mock for your data context e.g. MemoryExampleDataContext
Both will automatically use 3 the mappings you've already configured in 2 your DBML.
So you can do things like
public class ProductRepo {
IExampleDataContext DB { get; set };
public ProductRepo(IExampleDataContext db) {
DB = db;
}
public List<Product> GetProducts() {
return DB.Products.ToList();
}
}
and you 1 can call that with either
new ProductRepo(new MemoryExampleDataContext()).GetProducts(); // for testing
or
new ProductRepo(new ExampleDataContext()).GetProducts(); // use the real DB
Wrap the DataContext, then mock the wrapper. It's 5 the fastest way to get it done, although 4 it requires coding for testing, which some 3 people think smells. But sometimes, when 2 you have dependencies that cannot be (easily) mocked, it's 1 the only way.
Normally, you don't need to test the part 12 of the code that uses LINQ to SQL but if 11 you really want to, you can use the same 10 data sets that you're querying against the 9 server and turn them into in-memory objects 8 and run the LINQ queries against that (which 7 would use the Enumerable methods instead 6 of Queryable).
Another option is to use Matt 5 Warren's mockable version of the DataContext.
You can also get the SQL statements 4 that LINQ to SQL uses by getting them via 3 the debugger (from the IQueryable object), check 2 those manually, and then include them in 1 the automated tests.
Linq makes testing much easier. Linq queries 3 work just as well on Lists as on the Linq-to-sql 2 stuff. You can swap out Linq to SQL for 1 list objects and test that way.
Mattwar over at The Wayward Web Log had a great article about 2 how to mock up an extensible Linq2Sql data 1 context. Check it out -- MOCKS NIX - AN EXTENSIBLE LINQ TO SQL DATACONTEXT
LINQ to SQL is actually really nice to unit 6 test as it has the ability to create databases 5 on the fly from what is defined in your 4 DBML.
It makes it really nice to test a ORM 3 layer by creating the DB through the DataContext 2 and having it empty to begin with.
I cover 1 it on my blog here: http://web.archive.org/web/20090526231317/http://www.aaron-powell.com/blog/may-2008/unit-testing-linq-to-sql.aspx
More Related questions
We use cookies to improve the performance of the site. By staying on our site, you agree to the terms of use of cookies.