I am creating a repository that exposes IQueryable. What is the best way to mock this out for my unit testing?
Since I am using RhinoMocks for the rest of my mock objects, I tried to do the following:
IQueryable<MyObject> QueryObject =
MockRepository.GenerateStub<IQueryable<MyObject>>();
This doesn't work though so I tried doing this:
IQueryable<MyObject> QueryObject =
(new List<MyObject> { new MyObject() }).AsQueryable();
Is there a better way to do this, or have any other mocking frameworks built support for IQueryable in?
My repository interface looks like this:
public interface IRepository<T> where T : TableServiceEntity
{
IQueryable<T> Table { get; }
void Attach(T existingItem);
void Delete(T itemToDelete);
void Insert(T newItem);
T Load(string partitionKey, string rowKey);
IEnumerable<T> Load(string partitionKey);
IEnumerable<T> Query(IQueryable<T> query);
IEnumerable<T> Last(int count);
T Last();
void Update(T item);
}
Here is the method that I want to test:
public Post LoadPost(int year, int month, int day, string slug)
{
var query = from p in _blogRepository.Table
where
p.PartitionKey == Key.Partition(year, month, day)
&& p.Slug == slug
select p;
var posts = _blogRepository.Query(query.Take(1));
return posts.First();
}
Then here is the test as I have it right now that will test LoadPost.
[Fact]
public void LoadWillRetrieveByPartitionKeyAndRowKeyWhenUsingUriFormat()
{
Repository
.Stub(x => x.Query(Arg<IQueryable<Post>>.Is.Anything))
.Return(new List<Post> {_post});
var result = Service.LoadPost(
_post.Year(),
_post.Month(),
_post.Day(),
_post.Slug);
Assert.NotNull(result);
}
The code is taken from my AzureBlog project.
I usually do exactly what you ended up doing in your test. When writing my tests I assume that the .Net library classes work correctly and don't contain bugs, so I can use them in the tests. When I need a test list, collection, queryable, dictionary, etc. I just create the real thing and populate with test data. It makes the tests much more readable and quicker to write, and to be honest the risk is non-existent.