TIL: Always check for missing configuration values inside constructors

This post is part of my Advent of Code 2022.

This is a lesson I learned after trying to use a shared NuGet package in one of my client’s projects and getting an ArgumentNullException. I had no clue that I needed some configuration values in my appsettings.json file. This is what I learned.

Always check for missing configuration values inside constructors. In case they’re not set, throw a human-friendly exception message showing the name of the expected configuration value. For example: ‘Missing Section:Subsection:Value in config file’.

A missing configuration value

This is what happened. I needed to import a feature from a shared Nuget package. It had a method to register its dependencies. Something like services.AddFeature().

When calling an API endpoint that used that feature, I got an ArgumentNullException: “Value cannot be null. (Parameter ‘uriString’).” It seemed that I was missing a URI. But what URI?

Without any XML docstrings on the AddFeature() method, I had no other solution than to decompile that DLL. I found a service like this one,

public class SomeService : ISomeService
{
    private readonly Uri _anyUri;

    public SomeService(IOptions<AnyConfigOptions> options, OtherParam otherParam)
    {
        _anyUri = new Uri(options.Value.AnyConfigValue);
        //                ^^^^^^^
        // System.ArgumentNullException: Value cannot be null. (Parameter 'uriString')
    }

    public async Task DoSomethingAsync()
    {
        // Beep, beep, boop...
        // Doing something here...
    }
}

There it was! The service used the IOptions pattern to read configuration values. And I needed an URL inside a section in the appsettings.json file. How was I supposed to know?

A better exception message

Then I realized that a validation inside the constructor with a human-friendly message would have saved me (and any other future developer using that NuGet package) some time. And it would have pointed me in the right direction. I mean having something like,

public class SomeService : ISomeService
{
    private readonly Uri _anyUri;

    public SomeService(IOptions<AnyConfigOptions> options, OtherParam otherParam)
    {
        //  vvvvvvv
        if (string.IsNullOrEmpty(options?.Value?.AnyConfigValue))
        {
            throw new ArgumentNullException("Missing 'AnyConfigOptions:AnyConfigValue' in config file.");
            //                              ^^^^^^^^
            // I think this would be a better message
        }

        _anyUri = new Uri(options.Value.AnyConfigValue);
    }

    public async Task DoSomethingAsync()
    {
        // Beep, beep, boop...
        // Doing something here again...
    }
}

Even better, what if the AddFeature() method had an overload that receives the expected configuration value? Something like AddFeature(AnyConfigOptions options). This way, the client of that package could decide the source of those options. Either read them from a configuration file or hardcode them.

The book “Growing Object-Oriented Software Guided by Tests” suggests having a StupidProgrammerMistakeException or a specific exception for this type of scenario: missing configuration values. This would be a good use case for that exception type.

Voilà! That’s what I learned today: always validate configuration values inside constructors and use explicit error messages when implementing the Options pattern. It reminded me of “The given key was not present in the dictionary” and other obscure error messages. Do you write friendly and clear error messages?

To read more content about ASP.NET Core, check how to add caching with Redis and how to read configuration values.

Happy coding!

How to write tests for HttpClient using Moq

This post is part of my Advent of Code.

These days I needed to unit test a service that used the built-in HttpClient. It wasn’t as easy as creating a fake for HttpClient. This is how to write tests for HttpClient with Moq and a set of extension methods to make it easier.

To write tests for a service that requires a HttpClient, create a fake for HttpMessageHandler and set up the protected SendAsync() method to return a HttpResponseMessage. Then, create a new HttpClient passing the fake instance of HttpMessageHandler created before.

How to Create a Testable HttpClient

For example, let’s write a test for a AnyService class that receives a HttpClient, using MSTest and Moq,

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;
using Moq.Protected;
using Newtonsoft.Json;
using System.Net;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;

namespace MyProject.Services.Tests;

[TestClass]
public class AnyServiceTests
{
    [TestMethod]
    public async Task DoSomethingAsync_ByDefault_ReturnsSomethingElse()
    {
        var fakeHttpMessageHandler = new Mock<HttpMessageHandler>();
        fakeHttpMessageHandler
                .Protected()
                // ^^^^^^^
                .Setup<Task<HttpResponseMessage>>(
                    "SendAsync",
                    ItExpr.IsAny<HttpRequestMessage>(),
                    ItExpr.IsAny<CancellationToken>()
                )
                .ReturnsAsync(new HttpResponseMessage
                {
                    StatusCode = HttpStatusCode.OK,
                    Content = new StringContent(JsonConvert.SerializeObject(new AnyResponseViewModel()))
                    // We add the expected response here:                   ^^^^^
                });
        using var httpClient = new HttpClient(fakeHttpMessageHandler.Object);
        //                                    ^^^^^
        var service = new AnyService(client);

        var someResult = await service.DoSomethingAsync();

        // Assert something here...
        Assert.IsNotNull(someResult);
    }
}

Notice how we used the Protected() and Setup() methods from Moq to create a fake for HtttpMessageHandler. Then, inside the ReturnsAsync() method, we created a response message with a response object. And, finally, we used the fake handler to create a new HttpClient to pass it to our AnyService instance.

That’s how we created a fake HttpClient. But, as soon as we start to write more tests, all of them get bloated with lots of duplicated code. Especially, if we create new tests by copy-pasting an existing one.

We should reduce the noise in our tests using factory methods or builders to make our tests more readable. Let’s do that!

Some extensions methods to set up the faked HttpClient

It would be great if we could reduce the Arrange phase of our sample test to one or two lines. Something like this,

[TestMethod]
public async Task DoSomethingAsync_ByDefault_ReturnsSomethingElse()
{
    using var client = new Mock<HttpMessageHandler>()
                  .WithSuccessfulResponse(new AnyResponseViewModel())
                  //                      ^^^^^
                  // Alternatively,
                  // .WithUnauthorizedResponse()
                  // or
                  // .WithException<HttpRequestException>()
                  .ToHttpClient();
    var service = new AnyService(client);

    var someResult = await service.DoSomethingAsync();

    // Assert something here...
    Assert.IsNotNull(someResult);
}

It’s not that difficult to write some extension methods on top of the Mock<HttpMessageHandler> to simplify the creation of testable HttpClient instances.

In fact, here they are,

using Moq;
using Moq.Language.Flow;
using Moq.Protected;
using Newtonsoft.Json;
using System;
using System.Net;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;

namespace HttpMessageHandlerTests.Extensions;

public static class MockHttpMessageHandlerExtensions
{
    public static Mock<HttpMessageHandler> WithSuccessfulResponse<T>(
        this Mock<HttpMessageHandler> fakeHttpMessageHandler,
        T responseContent)
    {
        fakeHttpMessageHandler
            .GetProtectedSetup()
            .ReturnsAsync(new HttpResponseMessage
            {
                StatusCode = HttpStatusCode.OK,
                Content = new StringContent(JsonConvert.SerializeObject(responseContent))
            });

        return fakeHttpMessageHandler;
    }

    public static Mock<HttpMessageHandler> WithUnauthorizedResponse(
        this Mock<HttpMessageHandler> fakeHttpMessageHandler)
    {
        fakeHttpMessageHandler
            .GetProtectedSetup()
            .ReturnsAsync(new HttpResponseMessage
            {
                StatusCode = HttpStatusCode.Unauthorized,
                RequestMessage = new HttpRequestMessage()
            });

        return fakeHttpMessageHandler;
    }

    public static Mock<HttpMessageHandler> WithDelegate(
        this Mock<HttpMessageHandler> fakeHttpMessageHandler,
        Func<HttpRequestMessage, CancellationToken, HttpResponseMessage> func)
    {
        fakeHttpMessageHandler
            .GetProtectedSetup()
            .ReturnsAsync(func);

        return fakeHttpMessageHandler;
    }

    public static Mock<HttpMessageHandler> WithException<TException>(
        this Mock<HttpMessageHandler> fakeHttpMessageHandler)
        where TException : Exception, new()
    {
        fakeHttpMessageHandler
            .GetProtectedSetup()
            .Throws<TException>();

        return fakeHttpMessageHandler;
    }

    public static HttpClient ToHttpClient(this Mock<HttpMessageHandler> fakeHttpMessageHandler)
    {
        return new HttpClient(fakeHttpMessageHandler.Object);
    }

    private static ISetup<HttpMessageHandler, Task<HttpResponseMessage>> GetProtectedSetup(
        this Mock<HttpMessageHandler> fakeHttpMessageHandler)
    {
        return fakeHttpMessageHandler
            .Protected()
            .Setup<Task<HttpResponseMessage>>(
                "SendAsync",
                ItExpr.IsAny<HttpRequestMessage>(),
                ItExpr.IsAny<CancellationToken>());
    }
}

We can add other methods like WithNotFoundResponse(), WithInternalServerResponse() or WithTooManyRequestsResponse() to cover other response codes. Even, we can setup the fake HttpMessageHandler passing an Uri with a method ForUri(), for example.

Voilà! That’s how to write tests with HttpClient and Moq. With some extension methods, we could have a small DSL to write more readable tests. For a more fully-featured alternative to write tests for HttpClient, check mockhttp, “a testing layer for Microsoft’s HttpClient library.”

If you want to read more about unit testing, check my Unit Testing 101 series where we cover from what a unit test is, to fakes and mocks, to best practices.

Happy testing!

Advent of Code 2022

This year, inspired by C# Advent and 24 Pull Requests, I decided to do my own Christmas challenge: my own Advent of Code. I prefer to call it: Advent of Posts. Starting on December 1st, I’m publishing 24 posts, one post per day.

The challenge is to write an article per day in about 2 hours, including proof-reading and banner design. I’ve written some of the post in advance to avoid content pressure.

Here is my Advent of Posts:

• Day 1: How to write tests for HttpClient using Moq
• Day 2: TIL: Always check for missing configuration values inside constructors
• Day 3: TIL: How to test an ASP.NET Core Authorization filter
• Day 4: On Unit Testing Logging and Log Messages
• Day 5: I stopped using leading or tricky questions in Code Reviews
• Day 6: How to replace BackgroundServices with a lite Hangfire
• Day 7: I’m banning Get, Set, and other method and class names
• Day 8: Let’s refactor a test: Store OAuth connections
• Day 9: How to rename Visual Studio projects and folders with Git
• Day 10: TIL: How to replace keywords in a file name and content with Bash
• Day 11: TIL: How to automatically insert and update audit fields with OrmLite
• Day 12: Four things I wished I knew before becoming a software engineer
• Day 13: TIL: Five lessons I learned after working with Hangfire and Ormlite
• Day 14: How to write good unit tests: Use simple test values
• Day 15: How to create ASP.NET Core Api project structure with dotnet cli
• Day 16: Six helpful extension methods I use to work with Collections
• Day 17: Three lessons I learned after a “failed” project
• Day 18: Lessons I learned from my ex-coworkers
• Day 19: Lessons I learned as a code reviewer
• Day 20: Dump and Load to squash old migrations
• Day 21: To Value Object or Not To: How I choose Value Objects
• Day 22: Let’s refactor a test: Remove duplicated emails
• Day 23: -
• Day 24: -

Happy coding!

Monday Links: 40-year Programmer, Work and Burnout

Another five interesting links I found in past weeks. This time, I found a recurring theme while reading Hacker News: burnout, caring and statisfaction.

The Forty-Year Programmer

This post contains all the insights of 40-years a lifetime working as a programmer. These are some of my favorites:

• “Advice is expertise with all the most important bits removed.”
• “The work is good. If it stops being good, you’ll stop too. If it stops being good, that’s an emergency: you need to take a vacation…“
• “Don’t confuse work with your career. They’re not the same thing. They’re only barely related.”

Read full article

Developers Don’t Fight The Last War

This post reminded me about an ex-coworker that says that using the same skills, architecture, and tools is like being an architect who always design the same house over and over. What worked yesterady won’t work tomorrow, I guess.

“…Technology is changing all the time, but developers like to create software with the knowledge and skills they already have.”

Read full article

How to communicate effectively as a developer

Apart from social interaction, this is another challenge when working remotely. In the old days, we just tapped somebody else’s shoulders. These days of remote and asynchronous working, communication is more challenging. And we’re not teaching that when onboarding new hires. I still get plain “Hello” messages. I just ignore them.

This article shows a solution: “high resolution writing.” But, there’s another challenge with that. Often, we work with non-native speakers of the language used at work (pretty much, English everywhere). And, writing is a separate skill to master. Even for native speakers writing in his native language.

Read full article

Caring about jobs and enjoyment after burnout

I’ve seen an increasing amount of Hacker News posts about burnout and job-related problems. These are some of them:

Tips to relearn how to care about my job?: “I got a high paying job at a recognizable tech company, but plagued with exhaustion and lack of motivation, which is killing me daily life. Anything you guys have done to dig out of a rut?”

Has anyone managed to find enjoyment in their work after burnout?: “Has anyone come back from being burnt out to love what they do again? If so, how did you manage to do it?”

How to deal with burnout and its consequences?: Speaking about burnout: “I really don’t know how to get over this and how to move past it. I feel quite literally incapable of working…I’m trying to figure out what my future even looks like and how to move past this and any advice would be really appreciated.”

A lot of good advice in there.

What “Work” Looks Like

I think we’ve all been to those meetings where nobody cares or even listens to what the organizer says. Especially, those where the organizer reads a document, he could have shared in the first place. This article shows an alternative to collaborative brainstorming. Spoiler alert: it’s away from computers. Read full article

Voilà! Another Monday Links. Have you experience burnout? How did you overcome it? What’s different about work after burnout? What are you doing to prevent burnout?

Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.

Happy coding!

Unit Testing Principles, Practices, and Patterns: Takeaways

This book won’t teach you how to write a unit test step by step. But, it will teach you how unit testing fits the larger picture of a software project. Also, this book shows how to write integration tests and test the database. These are my takeaways.

1. What is a unit test?

“The goal of unit testing is to enable sustainable growth of the software project.” “It’s easy to fall into the trap of writing unit tests for the sake of unit testing without a clear picture of whether it helps the project.”

A successful test suite has the following properties:

• It’s integrated into the development cycle,
• It targets only the most important parts of your codebase: the domain model,
• It provides maximum value with minimum maintenance costs.

A unit test is an automated test with three attributes:

1. It verifies a small portion of behavior (a unit),
2. does it quickly, and,
3. in isolation from other tests

There are two groups of developers with different views about “isolation”: the London school and the Classical school.

For the London school, isolation means writing separate tests for separate classes. If a class has collaborators, we should test it using test doubles for every collaborator.

On the other hand, for the Classical school, it’s not the code that needs to be tested in isolation, but the tests. They should run in isolation from each other. It’s ok to test more than one class at a time if the tests don’t affect others by sharing state.

“A test—whether a unit test or an integration test—should be a simple sequence of steps with no branching”

A good unit test has these four attributes:

1. Protection against regressions: “Code that represents complex business logic is more important than boilerplate code.”
2. Resistance to refactoring: “The more the test is coupled to the implementation details of the system under test (SUT), the more false alarms it generates.”
3. Fast feedback: “The faster the tests, the more of them you can have in the suite and the more often you can run them.”
4. Maintainability: “How hard is to read a test” and “how hard is to run a test.”

2. What code to test?

Not all code is created equal and worth the same.

There are four types of code:

1. Domain logic and algorithms: Complex code by nature
2. Trivial code: Constructors without parameters and one-line properties
3. Controllers: Code with no business logic that coordinates other pieces
4. Overcomplicated code: Complex code with too many dependencies

Write unit tests for your domain model and algorithms. It gives you the best return for your efforts. Don’t test trivial code. Those tests have a close-to-zero value.

“Your goal is a test suite where each test adds significant value to the project. Refactor or get rid of all other tests. Don’t allow them to inflate the size of your test suite”

3. What is an integration test? And how to test the database?

An integration test is any test that is not a unit test. In the sense of verifying a single behavior, doing it quickly and in isolation from other tests.

Write integration tests to cover the longest happy path and use the same code that the “controllers” use.

Before writing integration tests for the database:

• Keep the database in the source control system. It keeps track of changes and makes the code the single source of truth
• Make reference data part of the database schema
• Have every developer roll a separate instance
• Use migration-based database delivery. Store your migrations in your version control system.

When writing integration tests for the database:

• Separate database connections from transactions. Use repositories and transactions.
• Don’t reuse database transactions or units of work between sections of the test. Integration tests should replicate the production environment as closely as possible. This means the Act part shouldn’t share connections or database context with anyone else.
• Clean up data at the beginning of each test. Create a base class and put all the deletion scripts there.
• Don’t use in-memory databases. They don’t have the same set of features. Use the same database system as production.
• Extract technical, non-business-related parts into helper methods. For Arrange parts, use object mothers. And, for Assert parts, create extension methods for data assertions, like, userFromDb.ShouldExist().
• Test only the most complex or important read operations. Forget about the rest.
• Don’t test repositories directly. Test them as part of an overarching integration test suite.

Voilà! These are my takeaways. Although this book has “Unit Testing” in its title, I really liked it covers integration tests, especially testing the database and data-access layer. I’d say this isn’t a book for beginners. You would take more out of this book if you read The Art Of Unit Testing first.

If you want to read more about unit testing, check my Unit Testing 101 series where I cover from what unit testing is to unit testing best practices.

Happy testing!