Written by Paul Pinder - Software Engineer based in Middlesbrough, UK
Introduction
This document talks about how we tackle unit and integration tests using MS Test assertions and Fluent Assertions. Both provide excellent coverage of how to test our development use cases.
MS Test Assertions
Software developers have used the MS Test Framework that comes installed with Visual Studio for many years. It simply allows the developer to write and run unit tests. Unit tests ensure that code meets the requirements and quality as expected before being deployed to TEST, UAT or production.
MS Test assertions uses the Microsoft.VisualStudio.TestTools.UnitTesting namepace. The test class contains the following attributes; TestClass, TestCategory, TestInitialize, DataTestMethod and DynamicData. All deriving from MS unit testing.
This document focus’s on how we test against our methods in terms actual and expected output using the Assert class. By using the Microsoft definition, the Assert class is a collection of helper classes to test various collections within unit tests. If the condition being tested is not met, an exception is thrown.
A list of methods can be used such as AreEqual or IsTrue. A full list of other methods can be found at https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.testtools.unittesting.assert?view=visualstudiosdk-2022
In an application for example we have.
Assert.IsTrue(deliveryListPaginated.Count <= pageSize);
Assert.IsNotNull(logic);
Assert.IsNotNull(deliveryInfo);
Assert.IsInstanceOfType(actualResult, typeof(IEnumerable));
Assert.AreEqual(returnValue, 1);
Fluent Assertions
Fluent Assertions is a set of .net extension methods from the AssertionExtensions deriving from FluentAssertions class. Fluent Assertions extension library cross compiles to .net framework 4.7+, along with .net core and .net standard. The assertion library supports MS Test (VS 2017+) and is used within the Test classes and test methods that are created.
The assertion library is an alternative library that is used for unit / integration tests and can be used instead of the methods that derive from the Assert class that MS provide.
A list of methods can be used such as theObject.Should().BeSameAs(otherObject) or theObject.Should().NotBeNull(). A full list of other basic assertions can be found at https://fluentassertions.com/basicassertions/.
Fluent Assertions comes with several different extensions depending on the data types you are testing against, there are extensions for string, int, bool, exceptions, collections, GUID, dates etc.
Example Comparisons
Example 1
The test case examples return a Boolean result and checks to see if it matches the expected outcome.
MS Test Assertion
Fluent Assertion
Example 1 Summary - As you can see, the Fluent Assertion example takes a lot less time to read. It reads like a sentence. Fluent Assertions provide several extension methods that make it easier to read compared to MS Test Assert statements. All that is required to do is get the expected outcome of the test in a result then use the should() assertion and other extensions to test the use case.
Example 2
Fluent assertions provide better failure messages. When a unit test fails, they show a failure message. Ideally, you’d to be able to understand why the test fails. The following test case uses the built-in assertions to check if the two references are pointing to the same object.
MS Test Assertion
Unit test failure message: Assert.AreNotSame failed
Fluent Assertion
Unit test failure message: Did not expect team.SubteamLead to refer to
CopyingObjects.Person
{
FirstName = “Paul”
LastName = “Tester”
}
Example 2 Summary - Compared to the built in MS test Assertion failed message, the fluent assertion message explains why the test failed.
Example 3
Fluent assertions simplifies asserting object equality. The following example shows two object properties that have equal values. Using the built-in assertions, you would possibly use the Assert.AreEqual to check if two values are equal.
MS Test Assertion
Unit test failure message: Assert.AreEqual failed. Expected:. Actual:
Fluent Assertion
Unit test failure message:
Expected member FirstName to be "Alexey" with a length of 6, but "Paul" has a length of 4, differs near "Paul" (index 0).
Expected member LastName to be "Test1", but "Test2" differs near "Test" (index 0).
Example 3 Summary - You may have noticed that MS Test Assertion is clear but didn’t runt the second assert. This means you will fix one failing assertion at a time. Fluent Assertion example though has one single call to Should().BeEquivalentTo() and will give all results.
Conclusion
MS Test and Fluent Assertions both provide testing mechanisms to test use cases. There will be many opinions formed on which is best to use. It may come down to preference.
From my point of view, I started testing using MS Test assertions and appreciated what the framework could offer. The framework helped my understanding of how to test my code. However, less than 2 years ago a colleague developer introduced me to Fluent Assertions. Once I started to use it, I found it easier to work with.
The first thing that stood out to me was it was more readable and less lines involved in writing the tests. Fluent assertions have also documented that it offers better failure messages, to help understand why a particular part of the code would not be working as expected.
For me personally, learning about Fluent assertions is an ongoing learning curve. I’m interested in its power/framework to enhance tests going forward.
I appreciate what fluent assertions have got to offer. Fluent Assertions have benefits of clear error messages, more readable test code and fewer lines of code needed for writing tests as iterated from the previous paragraph. The descriptive outcomes that Fluent Assertions offers also suits TDD and BDD testing methodologies.
I would consider this document as small introductory starting point, there is many pros and cons to the MS Test assertions and fluent assertions frameworks. There are other testing frameworks out there also to even consider. However, my opinion falls with Fluent Assertions.
I hope you have enjoyed reading this document.
As part of my general analysis, see links below where I formed my understanding of Fluent Assertions.
https://fluentassertions.com/basicassertions/
https://www.codeproject.com/Articles/784791/Introduction-to-Unit-Testing-with-MS-tests-NUnit-a?fbclid=IwAR1-UBzkeaVQfr9RI-GslJ70cyHtrbd8OStVFyIUrgQY2rsToUTKmos0Jd8
https://makolyte.com/csharp-use-fluentassertions-to-improve-unit-tests/?fbclid=IwAR0dLMIVayM1GZIqJLvTkIAkzJcbd0cOBHlgRmRO-LIk8mNDFAJbSvAWWfU
https://www.innovensa.co.uk/blog/fluent-assertions-10-top-tips?fbclid=IwAR3_lpSY9pLsM4fxLorrbkfaVEMmsiLVuTBgXXxS0xojD1a_OfH7QtBy7mY
https://www.jondjones.com/architecture/unit-testing/fluent-assertions/what-is-fluent-assertions-and-should-i-be-using-it/?fbclid=IwAR1Br9aHoUtkAAq5fEl4M07DddujIlA6A1owwU3gfC7FHhf4jvjqNKsXi_8