In many of the projects I’ve been working on we use an ORM tool called LLBL Gen Pro. This tool provides a LINQ implementation that allows us to to select objects from our data source using LINQ query syntax. An interesting obstacle we encountered was how to unit test code that used LINQ queries passed to LLBL.
For unit testing we did not want to actually hit our database, we wanted to isolate the code under test and ensure that it did what we intended. Our first thought was to mock the IQueryable interface. However, in the context of a LINQ query this didn’t seem feasible. When mocking an object usually we provide a mock implementation as a stand in and have it provide return values when needed and otherwise track the the object being’s mock usage. It wasn’t immediately obvious how we would program a mocked IQueryable interface or what calls would be made against it during a particular LINQ query.
Instead of providing a mocked IQueryable interface we realized we could simply create an “in memory” test database of sorts for our tests. Generic lists provide an ‘AsQueryable’ method that return their contents as an IQueryable. In order to make our select logic testable we have our methods take the IQueryable to select against as a parameter. When running for real the IQueryable parameter passed to the method is the data object that really hits the database, when under test a generic list is passed in. A very simplified example method might look like the below:
public List<SchoolEntity> GetList(SchoolFilter filter, IQueryable<SchoolEntity> schoolQ)
{
var result = from school in schoolQ
where school.Name == filter.Name
&& school.Colors == filter.Colors
select school;
return result.ToList();
}
In order to test we can create a list to pass in to our method:
[Test]
public void TestSchoolColorFilter()
{
//--Arrange
SchoolFilter filter = new SchoolFilter();
filter.Colors = "Blue";
List<SchoolEntity> schools = new List<SchoolEntity>();
SchoolEntity school1 = new SchoolEntity();
school1.Colors = "Blue";
schools.Add(school1);
SchoolEntity school2 = new SchoolEntity();
school2.Colors = "Purple";
//--Act
List<SchoolEntity> retVal = GetList(filter, schools.AsQueryable());
//--Assert
Assert.AreEqual(1, retVal.Count());
}
When actually running the method is called after a reference to an IQueryable object from the database is created and passed in like the below:
public List<SchoolEntity> GetList(SchoolFilter filter)
{
using (DataAdapter data = new DataAdapter())
{
LinqMetaData meta = new LinqMetaData(data);
return this.GetList(filter, meta.School);
}
}
This allows us to take advantage of LLBL’s LINQ to LLBL functionality but still create unit tests that don’t have to cross the boundary to the database in order to run. So far it’s helped us to keep our code less coupled and more cohesive. The next hurde, and another post, is how we handle unit testing when LLBL specific LINQ extension methods are involved, aka Prefetch Paths!
