I have little experience with unit testing, but at the project we're working on right now we decided to do unit testing. The project is a WPF/Entity Framework application, and the part I'm being confused about is a filter function.
Our universe of entities is like this: there are Products, Evaluations and Collections.
Evaluation 1 - n Product
Collection n - m Evaluation
Collection n - m Product
Now the filter function in question is called "in collection", and the logic is like this: Include the Product if it has a Collection where Collection.Active == true, or if the Product has an Evaluation which in turn has a Collection.
So when unit testing this, I'm trying to find out the different possible corner cases, and make assertions about wether they are included in the filtered list or not. Products which has an active collection, Products which has no active collection but has an evaluation that has a collection, and so on.
The thing is, working out these corner cases is much harder work than writing a simple linq-to-entity query, and it seems that the probability of making an error in the test is much higher than making an error in the implementation of the filter.
How would you handle such situations? It doesn't seem uncommon, especially where there are tools that let you write logic in a simple way. Is it possible to benefit from unit testing here? How?