Tuesday, September 2, 2014

Problem: When you are doing unit testing you are often faced with testing against some mock repository or some object store. The actual repository could be SQL repository or Azure repository or even CSV files . Inside a unit test you want some fake data and that data is easy to come up with as long you don’t have many records and fewer properties on each of those objects. For example, in the code below if you want to test IPersonRepository’s GetAll method you will try to write dummy data as a List<Person>(). I am using FakeItEasy as my mocking framework.

1. What if you have more properties than just firstName and LastName? Typically in a real world you will have lots of properties and lot of different values which you will have tough time creating and remembering for your particular unit test.

2. What if you have entities that are related? While IPersonRepository’s GetAll() method is very basic but what if you want to test FindAllPeopleWhoDidNotPayBills() in which you are doing a LINQ query against different related tables and want to test if that LINQ query is returns appropriate data. That LINQ query might look something like this.

How are you going to generate fake data if you want to test this query. A solution is you want to generate your own DbSet<Person> and DbSet<Sale> and you would make sure that the data would be related in those classes. Good luck coming up with that.

Generally people would do data driven tests that will pull data from database, excel, csv file. At my work in our current application we have lots of existing tables (think more than 100) and lots of columns (more than 20) on each of those tables and it is just painful trying to hook up each table and property using our List initializer syntax. And on top of that our unit test would have become very slow. In order to speed things up you want to have all your sample data hard coded in some helper method.

For each DbSet<T> we have a helper method that generates a DbSet<T> from hard coded List<T>. That hard coded List<T> is generated automatically using LINQPad Extension method. In our team we love LINQPad and I wished if there was a way to generate List<T> based upon the LINQ query that we execute inside LINQPad. So here is the extension method.

Copy and paste inside your MyExtensions static class in My Queries section of LINQPad. If you write any extension method here it is available throughout LINQPad.

1. Save your query. On saving it gets compiled and it gives you warning if you didn’t something wrong.

2. In LINQPad any anonymous query will not just work. You will have to do a ToList() and then GetCList(“Nameofclass”) method to get List<T> as C# text which you can copy and paste.

3. Don’t forget to specify the type of the class you want to generate in the GetCList(“Person”);

4. Now you can copy that the generated list and then use it in your dummy data generator class.

5. If you want to add support for different data types then first you might want to know which property is not showing up. Just uncomment this line in the extension and it will display which type is not listed.

Since this is a LINQPad extension you can do a lot of mix and match and generate a lot sample data as C# text pretty quickly. I am using AdventureWorks and using GetCList method against Persons. This is how it looks like.

Another pain point in this is if you are generating DataTime then getting the right DateTime for that particular event is tough. You have to think through different events that might have happened with that entity. For example, Lastvisited, ApprovedOn, InactivatedOn, PaymentPostedDate, etc. These dates have to be related in real world business problems. By generating data this way you are sure it will be related and you don’t have to think about it.

In LINQ using the let keyword you can generate different sets of data easily. You can generate related DbSet<T> in LINQPad easily but coming up related data manually is very time consuming and boring. If you made this far in a very silly post then thanks for that. Please let me how you are testing against DbSet<T> with lots of properties and if this could be improved upon.