Develop Reference

Unit testing a method that returns a collection

I'm trying to write some unit tests for a service which returns collections of complex objects (IQueriable<MyObject> to give an idea) and I'm not sure how to approach the problem.
Consider this:
public IQueriable<MyObject> GetMyObjects(int someParameterA, int someParameterB)
{...}
Basically, a method that, depending on the passed parameters, will output a collection of rather complex objects.
Since the application is under development, I can use a local SQL instance and I've created a method which will populate this DB with some sample data, so the service has something to work with.
I don't have much experience in writing unit tests. OK, I'll be honest, I don't have ANY experience in writing unit tests. -_- And most of the examples I saw were for methods that do some calculations and return a single result. It is thus possible to attach a data source for the test with test cases. If a method was to return the sum of two numbers, the data source would consist of three columns: the two numbers and the expected result.
So, with my limited knowledge about unit tests, I'm trying to apply the same logic to test a method that returns a collection... and I've no idea what the test should consist of (I know I could easily test the number of returned elements), let alone what the test data source with test cases should look like.
I know the VS2010 has CollectionAssert, but I guess my problem is that I don't know how to create the "expected" values in this case.
What's the best way to approach unit tests for such methods?

Create a mock collection for the data source. Either full-blown objects, or if they are complex to create in tests then look at using a mocking framework perhaps, such as Moq, or Rhino Mocks.
As long as your data source contains a sufficient range of objects to cover positive, negative and exception cases then you can write a suite of tests against this data source to cover all expected outcomes from the different input states that are possible in GetMyObjects.
You want this data to be as it would be when the application is running, so even if you don't have ALL the data you would have normally, you've just got to have enough in there to cover the eventualities you want to test against, such as:
What happens when there's no data in the source.
Do we get an empty collection, or an exception?
What happens when there's data in the source, but doesn't match the params you pass in
What happens when there's data in the source, but only one of the params match
What happens when there's data in the source and you pass in params that should return data
What happens when you pass in erroneous data to the method?
etc....

How to unit test Entity Framework?

I'm trying to test my code using EntityFramework code first. In order to make it testable and to allow isolation testing, I created an interface which my DbContext implements. I'm not testing the DbContext class - I'm going to assume EF code works as expected.
Now, consider the following method:
public IEnumerable<User> GetOddId()
{
return context_.Users.Where((u, i) => i % 2 == 1).AsEnumerable();
}
This method will pass with my mock FakeDbSet (because it would use the in-memory LINQ provider) whereas it would fail with an Exception when using the EF/LINQ to SQL drivers.
Would you leave it as it is and hope people know enough not to write such queries? Would you give up isolation testing and test on an actual db?
Would the LocalDb with DataMigrations (perhaps with appropriate seeds) help with testing on an actual db?
Please justify the answer(s).
TLDR: How to test EntityFramework code, considering the differences between in-memory LINQ and SQL LINQ?
Much later edit: I've since found a very good framework that does exactly what I need. I wrote a blog post about unit testing with Effort. Also please note all this might not be needed in the upcoming EF6, which promises a some unit testing features.

We use SQLite's in-memory databases for this purpose. They are extremely quick to create, query and tear down and barely have any impact on overall test speed. Once you've set yourself up a test framework to create a database and inject data, tests are quick to write.
Of course, SQLite is a much simpler database than most, so complex queries may fail to translate to its version of SQL, but for testing 90% of cases, it works well.
Do these tests constitute integration tests? I don't think so. They are still only testing one unit of your code, namely the bit that generates a LINQ query. You're testing for two things: 1) that the query returns the correct data (but you could check this using an in-memory collection as you stated), and 2) that the query can be translated into valid SQL by Entity Framework. The only real way to test the latter is to fire the query at a real Entity Framework but with a stubbed database.
Whilst you could argue that a true unit test should test just the output of your code (i.e. parse and check the expression tree that has been generated), as well as being harder to write, it doesn't really prove anything. If, for example, you modify the code to generate an inner join instead of a subquery, would you want the test to break? Only if it returns different results, I would have thought.

Where I work, we have a dev/beta/production SQL server. Sometimes we'll create tests against beta and seed test data (e.g. insert before testing specific selects and such) before executing tests on an actual database. People will draw a distinction between unit and integration testing, but it at least lets us test our logic, which is better than just crossing fingers and hoping for the best at the data-access layer.
What good is an in-memory provider that's easy to test for but doesn't actually represent the live system in some important cases?
EDIT: We don't use EF, btw...

You might want to use a mocking framework like Telerik's JustMock (or choose from many others).
This would give you lots of control over what happens in your test code. (Short introduction here.)
Instead of implementing a query to a real database you could 'simulate' the query and return a pre-defined collection of objects.
You could, for example, create multiple unit tests that call your GetOddId() method, and define different return collections that cover all the test cases you need (an empty list, correct content, wrong contents, throwing an exception, whatever, ...).
There is also a free 'Lite' version here or via NuGet.

Differences between database/entity framework and in memory lists when mocking in unit tests

I have been doing a lot of unit testing lately with mocking. The one thing that strikes me as a bit of a problem are the differences between querying against an in memory list (via a mock of my repository) and querying directly against the database via entity framework.
Some of these situations might be:
Testing a filter parameter which would be case insensitive against a database but case sensitive
against an in memory collection leading to a false fail.
Linq statements that might pass against an in memory collection but would fail against entity framework because they arent supported leading to a false pass.
What is the correct way to handle or account for these differences so that there are not false passes or fails in tests? I really like mocking as it makes things so much quicker and easier to test. But it seems to me that the only way to get a really accurate test would be to just test against a the entity framework/database environment.

Besides the unit tests you do you should also create integration tests which run against a real database setup as encountered in production.
I'm not an expert for EF but with NHibernate for example you can create a configuration which points to an in-memory instance of SQLite where you then run your quick tests against (i.e. during a development cycle where you want to get through the test suite as fast as possible). When you want to run your integration tests against a real database you simply change the NHibernate config to point to a real database setup and run the same tests again.
Would be surprising if you could not achieve something similar with EF.

You can use DevMagicFake, this framework will fake the DB for you and can also generate data so you can test your application without testing the DB

First and most important is you can define any behavior data within your mock. Second is speed. From unit testing perspective testing speed counts. Database connections are bottleneck most of time so that's why you mock it with tests.
To implement testing properly you need to work on your overall arch first.
For instance to access data layer I use repository pattern sometimes. It's described really good in Eric Evans DDD book.
So let's say if your repository is defined as below
interface IRepository: IQueryable, ICollection
you can handle linq queries pretty straightforward.
Further reading Repository

I would make my mocks more granular, so that you don't actually query against a larger set in a mock repository.
I typically have setters on my mock repository that I set in each test to control the output of the mocked repository.
This way you don't have to rely on writing queries against a generic mock, and your focus can be on testing the logic in the method under test

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 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.

Unit Testing (C#)

I am unit testing some CRUD operations. My questions are:
1) If I need to test the Add, Get, and Delete methods. The persistence layer is a database. Since I need to have a test object to Get and Delete, should I combine all 3 of these into one [TestMethod], or separate these into 3 methods and re-add the object before the Get and Delete tests?

Ideally you should have individual tests for each case.
You should use some sort of mocking - either via a framework or by setting up the database yourself - to set the initial conditions for each test.
So to test add you would start with a blank database and then add some new data, try to add the same data again (it should fail), add incomplete data etc.
Then to test get and delete you would start with a pre-populated database and perform the various tests you need.

I'd generally make a separate test. If I'm testing a "get" type method, the test setup would insert the object (generally by way of some mock framework) I expect to get as necessary, it just wouldn't be asserted against in the same way the actual get would.
This does mean that if the add implementation breaks, both the tests for the get and the add will fail in one way or another, assuming proper coverage. But that's kind of what you want anyhow, right?

If you are writing you own ORM to handle CRUD, I suggest you separate each action in a different test. Don't create big tests, that has many points of failure and many reasons to change, because it will turn your test project hard to maintain. Test each feature separately.
Now, if you are using some third part ORM to deal with CRUD, you should not test the tool at all, unless you don't trust it. But, in this case, you should find a better alternative. :)
You can do some Acceptance Tests to check if everything is working and, at this time, you will really reach the database.

Whatever makes testing easier for you :) as long as you get a return stating which method passed/failed then it should be good.

Hello :) I'd separate and test individually, and set up cleanly before and clear up after each.