With Entity Framework I usually construct a UnitOfWork with repositories in it. These return an IQueryable on the Get().

My test implementation for these IRepository interfaces use a List<T> and in combination with the IQuerable I can be pretty sure the LINQ queries I use will work similarly on the database implementation.

How would I go about getting the same test coverage and confidence with LLBLGen?

Our linq provider also produces IQueryable's ? So that's the same as with EF. You can even go further and obtain the expression trees if you want to, and execute the queries later instead of using ToList, see: https://www.llblgen.com/Documentation/5.9/LLBLGen%20Pro%20RTF/Using%20the%20generated%20code/Linq/gencode_linq_gettingstarted.htm#illblgenproquery

Have you looked at our Linq provider? https://www.llblgen.com/Documentation/5.9/LLBLGen%20Pro%20RTF/Using%20the%20generated%20code/Linq/gencode_linq_gettingstarted.htm

But how do I mock the LLBLGen classes to enable me to run the tests in-memory? They seem to be "fat classes" with lots of logic in them which cannot be easily mocked.

You don't. Our framework isn't a POCO framework. We have the philosophy you should test your code on a real database, not mock that part. If you want you can mock e.g. the DataAccessAdapter (using its interface IDataAccessAdapter) to not hit the db but write code against it, but I advice against it. Let your tests hit a local database, monitor the queries generated with orm profiler to see if they are what you expect, so you won't run into surprises later on.

I have to say that I strongly disagree with you on this. I believe unit tests should run in memory to provide instant feedback which is needed to quickly develop and test complex business logic code. Having to wait an hour for 1000 unit tests to run kills interactivity and impedes fast development.

So maybe LLBLGen is not for me.

I understand your point of view, however our unit tests run on live databases over the network, all 8000+ of them complete in less than 4.5 minutes (I measured it just yet to be certain, and that's a combined 1 minute of waiting for the thread deadlock to kick in for the transient error recovery tests ). So it's not as bad as you think it is

The other thing to consider is that if you want to mock DB access, like I said, you can mock the IDataAccessAdapter interface which is implemented on the DataAccessAdapter, the object which executes queries.

I deliberately mentioned live testing on an actual database as in our field that's the recommended way to test database targeting code, because it'll avoid you running into database specific issues later on which might force you to redesign your architecture. But it's up to you of course.