DEV Community

Cover image for Two Alternatives to Assertion Messages — and Two Ideas if You Do Want To Keep Them
Cesar Aguirre
Cesar Aguirre

Posted on • Originally published at canro91.github.io

2 1 1

Two Alternatives to Assertion Messages — and Two Ideas if You Do Want To Keep Them

I originally posted this post on my blog a long time ago in a galaxy far, far away.


I got this question from Ankush on my contact page:

"I want to override the Assert method to avoid using Assert.True without a failure message. How can I achieve it?"

Here are 2 alternatives to assertion messages and 2 ideas if you do want them:

1. Don't use assertion messages. Write better test names instead

Test naming conventions, like the UnitOfWork_Scenario_Result, impose some order and structure to names. You won't have that inside assertion messages.

If you don't have too many assertions in your tests, with a good test name it's easy to figure out what failed and why.

2. Use assertion libraries with better messages

Like FluentAssertions or Shoudly. They have clearer and more verbose messages when an assertion fails.

Here's what MSTest, FluentAssertions, and Shoudly show when an assertion fails:

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void ADummyTestToShowFailureMessages()
    {
        var anyBool = false;

        // With MSTest
        Assert.IsTrue(anyBool);
        // Message:
        // Assert.IsTrue failed.

        // With FluentAssertions
        anyBool.Should().BeTrue();
        //  Message:
        // Expected anyBool to be True, but found False.

        // With Shouldly
        anyBool.ShouldBe(true);
        //   Message: 
        // Test method AssertionLibraries.UnitTest1.ADummyTestToShowFailureMessages threw exception: 
        // Shouldly.ShouldAssertException: anyBool
        //    should be
        // True
        //    but was
        // False
    }
}
Enter fullscreen mode Exit fullscreen mode

That's if you want assertion messages for the lack of good failure messages.

Now, if you do want assertion messages for whatever reason:

3. Write custom assertion methods

Wrap MSTest, NUnit, XUnit or the testing library you're using inside custom methods with the assertion messages as required parameters. Like,

AcmeCorp.CustomAssert.IsTrue(actual, yourMessageHereAsARequiredParam);
Enter fullscreen mode Exit fullscreen mode

If you're doing code reviews, that's something to share with your team and enforce during reviews.

4. Create a custom analyzer to check the absence of assertion messages

Code reviews can be daunting. And even if all test methods in your test suite have assertion messages, anyone can decide not to use them.

Automate the boring part with an analyzer that warns you if you're not passing a message to every assertion.

Here's an analyzer from xunit.analyzer. That's a good place to start.

Voilà!


Download your free copy of my ebook, Unit Testing 101: From Zero to Your First Tests. It covers all the basics to help you write your first unit tests in C#, from understanding unit testing to using naming conventions and avoiding common mistakes.

Billboard image

The fastest way to detect downtimes

Join Vercel, CrowdStrike, and thousands of other teams that trust Checkly to streamline monitoring.

Get started now

Top comments (0)

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs

👋 Kindness is contagious

Immerse yourself in a wealth of knowledge with this piece, supported by the inclusive DEV Community—every developer, no matter where they are in their journey, is invited to contribute to our collective wisdom.

A simple “thank you” goes a long way—express your gratitude below in the comments!

Gathering insights enriches our journey on DEV and fortifies our community ties. Did you find this article valuable? Taking a moment to thank the author can have a significant impact.

Okay