Releasing a project without bugs is an essential part of every project. One of the quickest and easiest tools to help you achieve that goal are unit tests. Regardless of how high, or low your test coverage is, you should be writing unit tests to help you validate your code works. One of the biggest benefits of unit testing (which is also one of the most overlooked) is that the code documents what the code is supposed to be doing and why. Combined, the tests create a spec that you, or anyone on your team, can reference now, or in the future. If written well, the test code will describe what your code/classes should be doing and what they shouldn't.
Many developers just think of unit tests as a means to an end. If a class has tests, code can be deemed as 'high quality". What a lot of people fail to understand, is that well-written unit tests can be thought of as an accompanying project document that will future maintenance easier. In a year's time, if a bug appears, I can use the tests to help me debug the issue. Having a well-written suite of tests will give me a much better knowledge of the system
This all sounds great and marvellous, however, writing your unit tests so they are easy to read and understand, doesn't occur magically. You will need to define coding guidelines within your team to ensure your tests are easy to read and understand. I've worked on big monolithic projects were reading the tests and figuring out what the heck was going on, took longer than writing the tests. If you find yourself in this situation, your tests aren't giving you the benefit they should. From my experience, when people find themselves in this situation, they tend to think tests are a waste of time and give up on maintaining them. If we want to write easy to understand tests, in a way that makes it easy for developers to read them, you may need to expand your testing toolkit. This is where Fluent Assertions come in.
What Is Fluent Assertions
Fluent Assertions is a NuGet package that I've been using consistently on my projects for about 6 years. It's extremely simple to pick up and start using. Most people can get to grips with Fluent Assertions within 5-10 minutes. Why use Fluent Assertions? It will make reading your unit tests a little bit easier. Fluent Assertions is free so there really isn't a party foul for not trying it out. I think I've introduced Fluent Assertions to over 10 teams now and so far no one's complained. The biggest reason why most teams don't use it is just a lack of exposure to it. Using a standard approach a unit test may look similar to this:
There's nothing wrong with the structure of this test, however, you need to spend a second or two to understand what's going on as the code is imperative. It is written like code, rather than a sentence. Instead, using Fluent Assertations you can write the same test like this:
Hopefully, you can see that this second example takes a lot less time to read, as it reads like a sentence rather than an Assert statement. Fundamentally, this is all Fluent Assertions does. It provides a number of extension methods that make it easier to read your unit tests compared to Assert statements. I'm hoping you can understand why it's so easy to pick up. All you need to do is get the outcome of your test in a result variable, use the Should() assertion and Fluent Assertions other extensions to test for your use case. Simple!
Fluent comes with a number of different extensions depending on the data types you are testing against, there are extensions for string, int, bool, exceptions, collections, GUID, dates etc.. more information about the extensions can be found here. Happy Coding 🤘
