Unit Testing IQuerable<XXEntity>
Joined: 30-Mar-2009
Joined: 30-Mar-2009
Any tips on mocking IDataAccessAdapter? It doesn't look very easy trying to figure out which methods are called by a given LINQ query. 
What would be really cool is if LLBLGen designer could generate entity test data and you could just point the DataAccessAdapter at it so that tests don't have to go to the database.
There's an MVC app called 'Kigg' and they've abstracted out the database such that Linq queries can be run against a mock database. Seems a shame to have the LLBLGen specific LINQ extensions such as 'WithPath' make doing this difficult.
testing with a mocked database is simply useless
It allows one to test that one's queries filter/return the expected data. With T-SQL this is impossible without going to the db but with generic LINQ you can just knock up a small list of entity instances and select against that. Testing a database query is surely not useless!
the database isn't something you can abstract away
But that's exactly what the Kigg website (http://www.codeplex.com/Kigg) has done. They have an IDatabase which looks something like this for production...
public partial class Database : IDatabase
{
public IQueryable<Category> CategoryDataSource
{
[DebuggerStepThrough]
get
{
return GetQueryable<Category>();
}
}
}
.. and like this for testing...
var database = new Mock<IDatabase>();
database.SetupGet(d => d.CategoryDataSource).Returns(new List<Category>().AsQueryable());
Perhaps their db and db operations are all quite simple though.
Sorry about opening a new thread. I always though it was the opposite - use the search because someone else has already asked the question. 
Ian wrote:
testing with a mocked database is simply useless
It allows one to test that one's queries filter/return the expected data. With T-SQL this is impossible without going to the db but with generic LINQ you can just knock up a small list of entity instances and select against that. Testing a database query is surely not useless!
what I meant was that linq to objects behaves differently than linq to <database>, simply because linq constructs have to be converted to SQL and this isn't always 1:1, so running the query not against a DB is IMHO not going to be useful, as the query on the DB might result in different results (and against the DB is what the real application will use, so using something else is only postponing unpleasant surprises 
)
the database isn't something you can abstract away
But that's exactly what the Kigg website (http://www.codeplex.com/Kigg) has done. They have an IDatabase which looks something like this for production...
public partial class Database : IDatabase { public IQueryable<Category> CategoryDataSource { [DebuggerStepThrough] get { return GetQueryable<Category>(); } } }.. and like this for testing...
var database = new Mock<IDatabase>(); database.SetupGet(d => d.CategoryDataSource).Returns(new List<Category>().AsQueryable());Perhaps their db and db operations are all quite simple though.
You don't get real-life numbers / scenarios. For an initial design it might work, but as soon as more and more complex code pops up into your application, the database is something to take into account, as a large percentage of your application will be spend inside the db.
Sorry about opening a new thread. I always though it was the opposite - use the search because someone else has already asked the question.
We in general discourage it because a new post suggests the earlier posts in the thread are relevant for the new post, which isn't always the case, so to avoid miscommunication, we really want new threads instead of reopening old ones 
Joined: 10-Mar-2006
Joined: 10-Mar-2006
Wow...never heard anyone say that! Everyone preaches just the opposite and turns out it was good of me to IGNORE THEM as this is exactly what I have been doing.
Pay close attention who claims these kind of things. Often they're not people who write software for a living. I don't mind if someone claims that XYZ is a good method, perhaps it is, but my experience is that in practice, it doesn't matter. If you suck at writing code, your code will suck, regardless of how much best practices you follow.
About testability. I wrote for v3 ~50 unittests, mainly for situations where I wanted to test out the code before I would write the UI on top of it (otherwise it would take even longer to see if it worked in practice. So they were more or less for testing if some piece of code would work for a situation. If I would have used mocking, I wouldn't have got a clear picture: the mocks would perhaps made it work, while the test in practice would fail if it would have used a full stack of classes.
When migrating v2.x unittests to v3, I ran into an interesting problem: a test for System.transactions failed. This was because v3 was developed on a new machine and MS DTC was setup the wrong way. To test if my code would work under system.transactions I need to have everything in place to see it actually work. I therefore can't rely on 'abstracting away the environment outside my scope' like a database, as that won't work in practice.
Some bigwigs in TDD land hate me for it, but I like to preach 'thinking before doing': Analyze -> decide how to concur problem -> collect algorithms (existing or your own) -> prove your own algorithms -> implement algorithms -> done. This is not without the risk of making mistakes here and there, but it gives you a straight forward path which puts you into control when to take the next step and you make that next step based on thinking and making decisions. If you like uni=ttests, no problem. But writing code in an editor isn't the start of a process, it's the end. See my latest blogpost about algorithmia (posted yesterday) for an example