Skip to content

5 different ways to compare lists of custom objects

When writing unit and integration tests, there will be scenarios when we want to compare and asserts collection of custom objects. There are many ways how we could solve this problem, and in this article I would like to present all of them for you. For basic assertions I use the NFluent library, but you can use any library other as well. Let’s bring it on!

The quick and dirty solution

The easiest and dirties solution for comparing custom objects collections is just to retrieve the elements one by one and execute assertions for each element. Let’s say we have a product domain entity as follows:

And now let’s see how we could compare a collecting containing products,:

Although this solution is quick and does its job, it is not so clean and we can have easily issues with the hard-coded indexes when our collection is populated with new items.

Custom solution #1

There is a custom solution I used extensively in the past when developed a warehouse management system for a customer. This custom solution worked like charm, especially when we wanted to compare domain objects having different types but inheriting from the same parent type. It looks as the following:

At the first look, the assertion logic complicated, but its usage is relative simple:

The only thing we need the implement is an assert method for a single domain object. The freedom what we gain from this solution is that we can freely specify which domain properties we want to use for assertions. The only drawback is that all the entries are asserted using the same logic, and there can be scenarios when we want to assert different properties of each elements.

Native solutions #1 – NFluent

NFluent is an awesome library which can make our unit test assertions very clean and solid. It has many great features such as asserting base types, extensibility and custom error messages, just to name a few. Next to that, it has also feature for comparing collection which can be achieved as follows:

While this solution is nice and dandy, it has a big problem, namely it is not type safe, therefore I rarely use in when writing assertions for my unit tests.

Native solutions #2 – FluentAssertions

The most popular .NET assertion library is the FluentAssertions. They have recently released a great feature for tackling our problem with collection assertion:

While this solution is really close what I would call “clean assertion”, the problem is that I am just not a big fan of having the assertions at the end of my lines because it makes the assertion parts of my unit tests less readable.

Custom solution #2 – The ultimate solution

And now I am going to present you the best way how to tackle our collection assertion issue in the most flexible way. First of all we need to create a custom product asserter class:

Then the custom assertion logic look as the following:

And last but not least we make use of this generic asserter class:

Now we have everything to assert collections having product entities. Let’s see how to use it:

Although for this solution there are more ceremony-setters (code) are required, it is the cleanest and the most flexible solution in my opinion. It makes our assertions really clean and extensible and it always what we want when writing unit tests. Next to that, this solution enables asserting different properties for each elements as well.

Published inTesting

Leave a Reply

Notify of