Mocking ISession.Query<T>() for testing consumer

I'm trying to avoid using an in memory database for testing (though I might have to do this if the following is impossible). I'm using NHibernate 3.0 with LINQ. I'd like to be able to mock session.Query<T>() to return some dummy values but I can't since it's an extension method and these are pretty much impossible to test.

Does anyone have any suggestions (other than using an in memory database) for testing开发者_StackOverflow社区 session queries with LINQ?

---

I've tried this before with previous versions of NH without much luck. I eventually used another class to wrap the query and mocked that instead.

I do think it's also worth writing an integration test against a real sql server, to make sure that the repository behaves as expected.

---

A better approach will be to mock the concept of what you are trying to do, not the inner api of an external system. For instance

• Write the query in a separated artifact, like IQuerySomething / QuerySomething
• Test your query against a database. Try this database be prety like the real db.
• When testing something that depends on IQuerySomething, mock IQuerySomething.

Fabio Maulo wrote about this pattern as EQO (Enhanced Query Object), i recommend you his post.

This is the way we use in .net for almost everything.

---

It's looking like you are going to overcomplicate things. I will try to save your time =)

First of all let's start that there is two tipes of testing for the typical project (I am sure you know this, but it is better to mention). Integration tests and Unit tests. And typically (I will assume that you have a typicall application in order no to add "typically" to every sentence) you need both of them.

Integration tests are going on real database and some of them on In-Memory one for better test performance.

So you probably have mappings in your application and want to test them, it is better to do with integration tests on real DB, and if you are using Fluent Nhibernate (if you don't it is better to start using it) this will be a pice of cake.

Then you probably have a kind of Repository or another data access layer (where you are using Linq) that you want to test too. And you probably want to have tests like:

When I submit a query get-customer-by-name, my data access component should return customer with specified name.

This is better to achieve using in-memory database, because this is cheaper. This will save you some time in the typical scenario.

But if you have a lot of complex queries, then I would agree with José F. Romaniello, that it is better to use Enhanced Query Object and test it separately.

You can put your attention on Sharp Arhitecture framework that is targeting a lot of issues when using Nhibernate and testing persistence layer.