Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How are people unit testing code that uses Linq to SQL [closed]

People also ask

Is LINQ to SQL still used?

LINQ to SQL was the first object-relational mapping technology released by Microsoft. It works well in basic scenarios and continues to be supported in Visual Studio, but it's no longer under active development.

How LINQ queries converted into SQL queries?

LINQ to SQL translates the queries you write into equivalent SQL queries and sends them to the server for processing. More specifically, your application uses the LINQ to SQL API to request query execution. The LINQ to SQL provider then transforms the query into SQL text and delegates execution to the ADO provider.

Why we use LINQ instead of SQL?

SQL isn't broken, so why fix it? Why do we need another querying language? The popular answer is that LINQ is INtegrated with C# (or VB), thereby eliminating the impedance mismatch between programming languages and databases, as well as providing a single querying interface for a multitude of data sources.


Update:

Fredrik has put an example solution on how to do unit test linq2sql applications over at his blog. You can download it at:

http://web.archive.org/web/20120415022448/http://iridescence.no/post/DataContext-Repository-Pattern-Example-Code.aspx

Not only do I think its great that he posted an example solution, he also managed to extract interfaces for all classes, which makes the design more decoupled.

My old post:

*I found these blogs that I think are a good start for making the DataContext wrapper: Link1 Link2

They cover almost the same topic except that the first one implements means for extracting interfaces for the tables as well. The second one is more extensive though, so I included it as well.*


3 years late, but this is how I do it:

https://github.com/lukesampson/LinqToSQL-test-extensions/

No need to write a wrapper or do lots of plumbing, just drop the T4 template next to your .dbml and you get:

  1. An interface for your data context e.g. IExampleDataContext
  2. An in-memory mock for your data context e.g. MemoryExampleDataContext

Both will automatically use the mappings you've already configured in 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 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 the fastest way to get it done, although it requires coding for testing, which some people think smells. But sometimes, when you have dependencies that cannot be (easily) mocked, it's the only way.


Linq makes testing much easier. Linq queries work just as well on Lists as on the Linq-to-sql stuff. You can swap out Linq to SQL for list objects and test that way.


Mattwar over at The Wayward Web Log had a great article about how to mock up an extensible Linq2Sql data context. Check it out -- MOCKS NIX - AN EXTENSIBLE LINQ TO SQL DATACONTEXT


Normally, you don't need to test the part of the code that uses LINQ to SQL but if you really want to, you can use the same data sets that you're querying against the server and turn them into in-memory objects and run the LINQ queries against that (which would use the Enumerable methods instead of Queryable).

Another option is to use Matt Warren's mockable version of the DataContext.

You can also get the SQL statements that LINQ to SQL uses by getting them via the debugger (from the IQueryable object), check those manually, and then include them in the automated tests.