DEV Community: Rogelio Gámez

What is code pollution and how to fix it - A dependency injection lesson

Rogelio Gámez — Sat, 22 Jun 2024 15:31:23 +0000

What is code pollution?

Code pollution is an antipattern that takes place when you introduce additional code to your production code base to enable unit testing. [1]

This antipattern appears in two forms:

As a new method only called from the unit tests.
As a flag that changes the behavior of a class to indicate that it is called from a unit test.

Remember that code is a liability, not an asset. Adding code to production for the sole purpose of unit testing decreases the project's maintainability.

Examples of code pollution

Case 1: Adding a method that is only called from the unit tests.

public class MyClass
{
    private readonly IConfiguration _configuration;

    public MyClass(IConfiguration configuration) 
    {
        _configuration = configuration;
    }

    public string Run() 
    {
        if (GetConfigurationValue() == "FooBar")
        {
            return "Do cool stuff";
        }
        return string.Empty;
    }

    // Only used for testing
    internal string GetConfigurationValue()
    {
        return _configuration["ConfigurationValue"];
    }
}

[TestClass]
public class MyTest()
{
    [TestMethod]
    public void TestConfigurationValue()
    {
        string configurationValue = "FooBar";

        IConfiguration configuration = new ConfigurationBuilder()
            .AddInMemoryCollection(
                new Dictionary<string, string>() { "ConfigurationValue", configurationValue })
            .Build();

        MyClass myClass = new MyClass(configuration);

        Assert.AreEqual(configurationValue, myClass.GetConfigurationValue());
    }
}

Case 2: Injecting a flag to change the class or method behavior.

public class MyClass
{
    private readonly IConfiguration _configuration;
    private bool _isTestEnvironment;

    public MyClass() {}

    internal MyClass(IConfiguration configuration, bool isTestEnvironment)
    {
        _configuration = configuration;
        _isTestEnvironment = isTestEnvironment;
    }

    public void Run(string createValue, string executeValue)
    {
        Repository myRepository;

        if (_isTestEnvironment)
        {
            // Stuff for test environment
            myRepository = CreateTestRepository(createValue);
        }
        else
        {
            // Stuff for normal environment
            myRepository = CreateRepository(_configuration, createValue);
        }

        myRepository.DoStuff(executeValue);
    }
}

How to fix code pollution

Case 1. Fixing method or property pollution.

If you are exposing private properties or methods, you are exposing implementation details. In that case, you should change your unit test to actually test the system's behavior.

[TestClass]
public class MyTest()
{
    [TestMethod]
    public void TestConfigurationValue()
    {
        string configurationValue = "FooBar";

        IConfiguration configuration = new ConfigurationBuilder()
            .AddInMemoryCollection(
                new Dictionary<string, string>() { "ConfigurationValue", configurationValue })
            .Build();

        MyClass myClass = new MyClass(configuration);

        Assert.AreEqual("Do cool stuff", myClass.Run());
    }
}

Case 2. Fixing injection pollution.

If you need to inject a parameter or configuration to test the system, you are not applying dependency injection properly.

In our example, we use a bool flag to indicate our program to create a test Repository instead of the normal one to avoid using production dependencies IConfiguration.

Instead, we should inject Repository as a method dependency, or inject a RepositoryBuilder as a constructor dependency.

// Method injection
public class MyClass
{
    public MyClass() {}

    public void Run(Repository repository, string executeValue)
    {
        repository.DoStuff(executeValue);
    }
}

// Constructor injection
public class MyClass
{
    private readonly RepositoryBuilder _repositoryBuilder;

    public MyClass(RepositoryBuilder repositoryBuilder) 
    {
        _repositoryBuilder = repositoryBuilder;
    }

    public void Run(string executeValue)
    {
        _respositoryBuilder.Build().DoStuff(executeValue);
    }
}

This way, we can inject the testing repo from our unit test, and the production repo in the production code base.

References

Khorikov, V. (2020). Unit testing principles, practices, and patterns. Manning Publications Company.

Using the Adapter pattern to migrate to a new library

Rogelio Gámez — Sun, 08 Oct 2023 20:01:56 +0000

Problem statement: migrating to a new library

For one reason or another, library A has been deprecated and you are tasked to migrate to library B.

The problem is that library A is spread all around your production and test codebases with direct calls to its classes without any interface in between. This poses the following challenges:

Since library A is used directly in code, it is called an implicit dependency, which obfuscates how it is being used making it harder to migrate.
If library A is used 100 times, and you happen to misuse its equivalent in library B, then you would need to go back and change all of them.
What if two years from now you now need to migrate to library C?
You may also want to swap between A and B using a feature toggle which becomes a hassle if library A is used 100 times. You can read more about feature toggles here: Don't break production when you add new features! - Feature Toggles in C# @ dev.to

Surely there is a better way to attack this problem.

Solution: implement the adapter pattern before migrating

The adapter pattern

Adapter is a structural design pattern that allows objects with different interfaces to collaborate. An adapter is a special object that converts the interface of one object so that another object can understand it. [1]

Adapter pattern image from refactoring.guru

Using the adapter pattern can help in our task by:

Since we will be refactoring to dependency injection we are making the dependency on the library explicit, making it easier to understand where it is being used.
We can swap between both libraries easily in our composition root.
If we happen to add a bug while implementing the new library, we can just fix the adapter implementation instead of the hundred implicit calls in the codebase.
If you need to migrate again to a new library, we can just implement the adapter for it. We only need to refactor to an adapter once!

Migrating to a new library

We will follow 4 straight forward steps:

Implement the adapter pattern for the existing library.
Change all dependencies of the existing library to the created adapter interface using dependency injection.
Implement the same adapter interface for the new library.
Inject the new library instead of the old library.

Example: from Newtonsoft.Json to System.Text.Json

Disclaimer: this is a purely informative/basic example. You are probably dealing with more complex situations.

You are currently using NewtonSoft.Json in your codebase and you want to migrate to System.Text.Json. You also want to avoid the already discussed problems, so you decide to implement an adapter first.

Following the steps above we do the following:

Create an adapter interface called IJsonAdapter in which we declare common methods such as Serialize and Deserialize. We then create NewtonsoftJsonAdapter where we implement the IJsonAdapter interface.
In our codebase we then inject the IJsonAdapter interface and use that instead of NewtonSoft.Json.
We now implement SystemTextJsonAdapter.
Finally, we inject SystemTextJsonAdapter instead of NewtonsoftJsonAdapter. Optional: we can use a feature toggle to swap between easily.

References

[1] Adapter. Refactoring.Guru. (n.d.). https://refactoring.guru/design-patterns/adapter

Why you should never use DateTime.Now directly - Dealing with Volatile Dependencies in C#

Rogelio Gámez — Thu, 02 Mar 2023 00:00:16 +0000

Why you should never use DateTime.Now directly

Dealing with Volatile Dependencies in C#

Problem Statement

You are happily working in your application and use the DateTime.Now property for something inoffensive like:

public int GetNumberOfDaysInCurrentMonth()
{
    return DateTime.DaysInMonth(DateTime.Now.Year, DateTime.Now.Month);
}

Some years passed by, and now you receive a bug on February 29. You start digging through your code the morning of the next day but everything is working correctly. You can probably guess what happened by now.

So now you fixed your application by adding support to leap years and you want to make sure everything will work correctly in the future by adding a unit test. How can you unit test the method above if every month will have different results? I hope you don't think of checking the current month in your unit test and assert based on that...

Volatile Dependencies

DateTime.Now is an example of volatile behavior.

A dependency can be considered volatile if any of the following criteria are true:

The dependency introduces a requirement to set up and configure a runtime environment. Example: databases, message queues, web services, file system.

The dependency doesn't yet exist, or is still in development.

The dependency isn't installed on all machines in the development organization. Example: expensive third-party libraries.

The dependency contains non-deterministic behavior. Example: random number generators, algorithms that depend on the current date or time.

– Deursen, S. V., & Seemann, M. (2019). Dependency injection: Principles, practices, and patterns. Manning Publications.

In this case DateTime.Now contains non-deterministic behavior because every time it is called, it will return a different value.

Dealing with Volatile Dependencies

Instead of using volatile dependencies directly in your code, you should introduce a new layer of abstraction, for example, an Adapter or Facade structural patterns.

In this case of the standard DateTime library, we can use a simple interface:

public interface IDateTimeProvider
{
    DateTime GetCurrentDateTime();
}

public class DefaultDateTimeProvider : IDateTimeProvider
{
    public DateTime GetCurrentDateTime()
    {
        return DateTime.Now;
    }
}

Then we can inject this provider into the class that we are using.

public class DateTimeUtility
{
    IDateTimeProvider _dateTimeProvider;

    public DateTimeUtility(IDateTimeProvider dateTimeProvider)
    {
        _dateTimeProvider = dateTimeProvider;
    }

    public int GetNumberOfDaysInCurrentMonth()
    {
        return DateTime.DaysInMonth(
            _dateTimeProvider.GetCurrentDateTime().Year, 
            _dateTimeProvider.GetCurrentDateTime().Month);
    }
}

Now we are not using DateTime.Now directly in our code, but by an abstraction. We can use another IDateTimeProvider in our code without changing the current implementation.

Unit Testing DateTime.Now through an Interface

Since we are now using an interface, we can use any mocking framework to test our behavior:

Example using Moq (https://github.com/moq/moq4):

[TestMethod]
public void GivenIsLeapYear_WhenGettingNumberOfDaysInFeb_ThenWeGet29()
{
    // Arrange
    Mock<IDateTimeProvider> dateTimeProviderMock = new Mock<IDateTimeProvider>();

    dateTimeProviderMock
        .Setup(mock => mock.GetCurrentDateTime())
        .Returns(new DateTime(2024, 02, 01)); /// Return feb of leap year

    IDateTimeProvider dateTimeProvider = dateTimeProviderMock.Object;

    DateTimeUtility dateTimeUtility = new DateTimeUtility(dateTimeProvider);

    // Act
    int daysInMonth = dateTimeUtility.GetNumberOfDaysInCurrentMonth();

    // Assert
    Assert.AreEqual(29, daysInMonth);
}

Final Thoughts

This was a very simple example of a volatile dependency. Date and random number generators are both examples of non-deterministic methods, but volatile dependencies can also include third-party libraries or out-of-process dependencies such as databases. When in doubt always remember: depend on abstractions, not concretions.

References

Deursen, S. V., & Seemann, M. (2019). Dependency injection: Principles, practices, and patterns. Manning Publications.

Don't break production when you add new features! - Feature Toggles in C#

Rogelio Gámez — Sun, 26 Feb 2023 16:00:44 +0000

Problem statement: You broke production after you added a new feature ):

You just added a new feature to your application, it passed all the unit, integration, and E2E testing. It was released and for two weeks, you haven't heard anything bad about it. But now, customers are having a problem with a process that has been working for 5 years without issues. After some digging, you discover that the feature that you added, broke the application if this or that specific state is reached.

What can you do? A fix would take at least 2 to 3 days to implement and release, but your application is practically unusable for the time being.

Proposed solution: Feature Toggles

Feature Toggles or Feature Flags is one of many ways to release new features.

Feature flags (also commonly known as feature toggles) is a software engineering technique that turns select functionality on and off during runtime, without deploying new code. [1]

In code, they look like this:

public void VeryImportantMethod(IFeatureManager featureManager)
{
    if (featureManager.IsEnabled(FeatureToggles.YourNewCoolFeature))
    {
        ExecuteNewFeature();
    }

    ExecuteExistingFunctionality();
}

We have a feature manager dependency that will handle whether the feature is enabled or not. The feature manager can take this configuration from settings files, databases, services, etc.

If your feature needs to be disabled because it breaks existing functionality. You would only need to modify it from your feature toggles source.

One example of a feature toggle source is the Feature Manager in Azure App Configuration:

Image taken from Microsoft Documentation [2].

Downside of Feature Toggles

There is a big downside to using feature toggles: complexity. [3]

When you add a new feature toggle, you are branching your application execution into a new path that you will need to take into account when you are debugging. And it becomes even more complex when there are feature toggles within feature toggles.

Feature Toggles good practices

The feature toggle manager should not be a concrete object

This goes for all your dependencies in your codebase. The Dependency Inversion Principle states that we should depend on abstractions, not concretions. And feature toggles are not the exception.

Ideally, you should have a static class (or similar depending on your language) with a list of all the feature toggles in your application.

public static class FeatureToggles
{
    public const FeatureA;
    public const FeatureB;
    // ...
}

And for your feature manager, you need an interface like:

public interface IFeatureManager
{
    bool IsEnabled(string featureToggle);
}

Then you can inject it into your code:

public class CoolClass
{
    private readonly IFeatureManager _featureManager;

    public CoolClass(IFeatureManager featureManager)
    {
        _featureManager = featureManager;
    }

    public void CoolMethod()
    {
        if (_featureManager.IsEnabled(FeatureToggles.FeatureA))
        {
            ExecuteFeatureA();
        }

        ExecuteExistingFunctionality();
    }

    // ...
}

This way when you create unit tests, you can mock IFeatureManager easily to test your new feature.

You can also implement another IFeaturesManager that takes the feature toggles values from another source without affecting existing code.

In your unit tests, do not check if the feature toggle is enabled or not, mock it!

It is easy to fall into this trap while testing feature toggles:

[TestMethod]
public void TestCoolClass()
{
    // Arrange
    IFeatureManager featureManager = new ConcreteFeatureManager();
    CoolClass coolClass = new CoolClass(featureManager);

    // Act
    coolClass.CoolMethod();

    // Assert
    if (featureManager.IsEnabled(FeatureToggles.FeatureA))
    {
        // Assert FeatureA works
    }
    else
    {
        // Assert existing functionality without FeatureA
    }
}

This is an anti-pattern in unit testing, we should not have branching logic. Instead, mock the feature manager interface and test both behaviors separately.

Example using Moq (https://github.com/moq/moq4):

[TestMethod]
public void TestFeatureA()
{
    // Arrange
    Mock<IFeatureManager> featureManagerMock = new Mock<IFeatureManager>();
    /// We make sure the feature manager mock returns true when FeatureA is requested.
    featureManagerMock
        .Setup(fm => fm.IsEnabled(FeatureToggles.FeatureA))
        .Returns(true);
    /// We get the mocked interface to pass as dependency.
    IFeatureManager featureManager = featureManagerMock.Object;
    CoolClass coolClass = new CoolClass(featureManager);

    // Act
    coolClass.CoolMethod();

    // Assert FeatureA works as expected
}

[TestMethod]
public void TestExistingFunctionality()
{
    // Arrange
    Mock<IFeatureManager> featureManagerMock = new Mock<IFeatureManager>();
    /// We make sure the feature manager mock returns false when FeatureA is requested.
    featureManagerMock
        .Setup(fm => fm.IsEnabled(FeatureToggles.FeatureA))
        .Returns(false);
    /// We get the mocked interface to pass as dependency.
    IFeatureManager featureManager = featureManagerMock.Object;
    CoolClass coolClass = new CoolClass(featureManager);

    // Act
    coolClass.CoolMethod();

    // Assert existing functionality works as expected
}

Have a formal approach to deal with feature toggles

Feature toggles are not meant to be eternal. Once your feature is well tested even in production, you will need to remove the feature toggle from your code, which is sometimes not that straightforward. Your team needs to have a formal approach to remove feature toggles once the feature becomes stable enough.

References

Buchannan, I. (n.d.). Feature flags. Atlassian. Retrieved February 24, 2023, from https://www.atlassian.com/continuous-delivery/principles/feature-flags
Maud-Lv. (n.d.). Tutorial: Use azure app configuration to manage feature flags - azure app configuration. Tutorial: Use Azure App Configuration to manage feature flags - Azure App Configuration | Microsoft Learn. Retrieved February 24, 2023, from https://learn.microsoft.com/en-us/azure/azure-app-configuration/manage-feature-flags
Fowler, M. (n.d.). Feature toggles (aka feature flags). martinfowler.com. Retrieved February 24, 2023, from https://martinfowler.com/articles/feature-toggles.html
Maud-Lv, M., et al. (n.d.). Tutorial for using feature flags in a .NET core app. Tutorial for using feature flags in a .NET Core app | Microsoft Learn. Retrieved February 24, 2023, from https://learn.microsoft.com/en-us/azure/azure-app-configuration/use-feature-flags-dotnet-core?tabs=core5x
Farley, D. (2021, January 6). Continuous integration vs feature branch workflow. YouTube. Retrieved February 24, 2023, from https://www.youtube.com/watch?v=v4Ijkq6Myfc

Stop manually iterating over your test data in your unit tests! - Parametrized tests in C# using MSTest, NUnit, and XUnit

Rogelio Gámez — Mon, 20 Feb 2023 20:47:23 +0000

Anti-pattern: manually iterating over test data

You probably have seen, or even coded yourself, a unit test that looks something like this:

[Test]
public void PokemonAreWaterType() 
{
    var pokemons = new List<string>() 
    {
        "Vaporeon",
        "Magikarp",
        "Squirtle"
    };

    foreach (var pokemon in pokemons) 
    {
        bool isWaterType = Pokedex.IsPokemonWaterType(pokemon);
        Assert.IsTrue(isWaterType, $"Pokemon '{pokemon}' should be water type.");
    }
}

You have a list of values that you want to test within the same test method, and you are looping over an array to perform the test. There are many problems with the code above:

While the above test is very simple and we can understand what is happening, this will rarely happen in real life.
We should also avoid nesting, the simpler the test, it will be easier to maintain.
If more than two test cases are failing, you will only get the results of one, as the test short circuits the first time an assert fails. Sure, you can save all the results in a results array, then assert on this array at the end, but you are again adding complexity to what should be a simple test.

Solution: parametrized testing

All the commonly used C# test frameworks support parametrized tests:

Data-driven tests, or parametrized tests, as you may wish to call them, take advantage of the test framework to simplify testing over a data source. This data source could be hardcoded values, collections, or any other data source.

We will create parametrized tests for all three common testing libraries in C#: MSTest, NUnit, and XUnit.

For the three test frameworks, we will showcase three unit test examples:

Unit test manually iterating over the test data.
Using attributes for each row of the test data.
Using a static array as the test data source.

The code used in this post can be found at: https://github.com/rogeliogamez92/blog-data-driven-testing

Example application: Pokémon Factory

We will create a Pokémon factory that takes two strings, name, and type, and tries to create a valid Pokémon. If the type is not supported by our application, it will create a Pokémon with an invalid type.

Pokémon class:

public class Pokemon
{
    public enum PokemonType
    {
        UnsupportedType,
        Grass,
        Fire,
        Water
    }

    public readonly string Name;
    public readonly PokemonType Type;

    internal Pokemon(string name, PokemonType type)
    {
        Name = name;
        Type = type;
    }
}

Pokémon factory class:

public class PokemonFactory
{
    public Pokemon CreatePokemon(string name, string type)
    {
        if (!Enum.TryParse(type, ignoreCase: true, out Pokemon.PokemonType pokemonType))
        {
            pokemonType = Pokemon.PokemonType.UnsupportedType;
        }

        return new Pokemon(name, pokemonType);
    }
}

While this is not a true implementation of the factory method pattern, if you want to know more about it, I strongly recommend you to read: https://refactoring.guru/design-patterns/factory-method.

Parametrized tests in MSTest

Let's start manually iterating over the test data:

[TestMethod]
public void IteratingOverData()
{
    /// Tuple(PokemonName, PokemonType, ExpectedPokemonType
    var pokemonData = new List<Tuple<string, string, Pokemon.PokemonType>>()
    {
        new ("Bulbasaur", "Grass", Pokemon.PokemonType.Grass),
        new ("Charmander", "Fire", Pokemon.PokemonType.Fire),
        new ("Squirtle", "Water", Pokemon.PokemonType.Water),
        new ("ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType),
    };

    var pokemonFactory = new PokemonFactory();

    foreach (var pd in pokemonData)
    {
        var pokemon = pokemonFactory.CreatePokemon(pd.Item1, pd.Item2);
        Assert.AreEqual(pokemon.Type, pd.Item3);
    }
}

We have our data in an array that we iterate and assert on each item. It works, but there is something off.

Let's see the same test using the DataRow attribute from MSTest:

[TestMethod]
[DataRow("Bulbasaur", "Grass", Pokemon.PokemonType.Grass)]
[DataRow("Charmander", "Fire", Pokemon.PokemonType.Fire)]
[DataRow("Squirtle", "Water", Pokemon.PokemonType.Water)]
[DataRow("ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType)]
public void UsingDataRow(string pokemonName, string pokemonType, Pokemon.PokemonType expectedPokemonType)
{
    var pokemonFactory = new PokemonFactory();

    var pokemon = pokemonFactory.CreatePokemon(pokemonName, pokemonType);

    Assert.AreEqual(pokemon.Type, expectedPokemonType);
}

At first glance, we can see an aesthetic improvement. That ugly foreach is no more.

Now, what happens when there are errors in the Fire and Water test cases? We will append "Error" to both input strings for type.

[TestMethod]
public void IteratingOverData()
{
    /// Tuple(PokemonName, PokemonType, ExpectedPokemonType
    var pokemonData = new List<Tuple<string, string, Pokemon.PokemonType>>()
    {
        new ("Bulbasaur", "Grass", Pokemon.PokemonType.Grass),
        new ("Charmander", "FireError", Pokemon.PokemonType.Fire), // ERROR
        new ("Squirtle", "WaterError", Pokemon.PokemonType.Water), // ERROR
        new ("ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType),
    };

    ///...

[TestMethod]
[DataRow("Bulbasaur", "Grass", Pokemon.PokemonType.Grass)]
[DataRow("Charmander", "FireError", Pokemon.PokemonType.Fire)] // ERROR
[DataRow("Squirtle", "WaterError", Pokemon.PokemonType.Water)] // ERROR
[DataRow("ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType)]
public void UsingDataRow(string pokemonName, string pokemonType, Pokemon.PokemonType expectedPokemonType)
{
    ///...

Let's see the difference in Visual Studio 2022 Test Explorer:

Using DataRow is so much better! If we manually iterate we would need to jump through hoops in code to try to give a similar report as the method using DataRow.

What if we want to reuse the test data? In MSTest we first declare the test data array, and reference it using the DynamicData attribute:

public static IEnumerable<object[]> PokemonData => new[]
{
    new object[] { "Bulbasaur", "Grass", Pokemon.PokemonType.Grass },
    new object[] { "Charmander", "Fire", Pokemon.PokemonType.Fire },
    new object[] { "Squirtle", "Water", Pokemon.PokemonType.Water },
    new object[] { "ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType },
};

[TestMethod]
[DynamicData(nameof(PokemonData))]
public void UsingDynamicData(string pokemonName, string pokemonType, Pokemon.PokemonType expectedPokemonType)
{
    var pokemonFactory = new PokemonFactory();

    var pokemon = pokemonFactory.CreatePokemon(pokemonName, pokemonType);

    Assert.AreEqual(expectedPokemonType, pokemon.Type);
}

Now we can reference that same array in as many tests as we want.

Parametrized tests in NUnit

For NUnit, we use the TestCase attribute instead of DataRow:

[TestCase("Bulbasaur", "Grass", Pokemon.PokemonType.Grass)]
[TestCase("Charmander", "Fire", Pokemon.PokemonType.Fire)]
[TestCase("Squirtle", "Water", Pokemon.PokemonType.Water)]
[TestCase("ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType)]
public void UsingTestCase(string pokemonName, string pokemonType, Pokemon.PokemonType expectedPokemonType)
{
    var pokemonFactory = new PokemonFactory();

    var pokemon = pokemonFactory.CreatePokemon(pokemonName, pokemonType);

    Assert.AreEqual(expectedPokemonType, pokemon.Type);
}

And if we want to use an array, we use the TestCaseSource:

public static IEnumerable<object[]> PokemonData => new[]
{
    new object[] { "Bulbasaur", "Grass", Pokemon.PokemonType.Grass },
    new object[] { "Charmander", "Fire", Pokemon.PokemonType.Fire },
    new object[] { "Squirtle", "Water", Pokemon.PokemonType.Water },
    new object[] { "ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType },
};

[TestCaseSource(nameof(PokemonData))]
public void UsingTestCaseSource(string pokemonName, string pokemonType, Pokemon.PokemonType expectedPokemonType)
{
    var pokemonFactory = new PokemonFactory();

    var pokemon = pokemonFactory.CreatePokemon(pokemonName, pokemonType);

    Assert.AreEqual(expectedPokemonType, pokemon.Type);
}

Parametrized tests in XUnit

For XUnit, for parametrized tests, we use the Theory attribute instead of Fact.

Instead of DataRow we use the InlineData attribute:

[Theory]
[InlineData("Bulbasaur", "Grass", Pokemon.PokemonType.Grass)]
[InlineData("Charmander", "Fire", Pokemon.PokemonType.Fire)]
[InlineData("Squirtle", "Water", Pokemon.PokemonType.Water)]
[InlineData("ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType)]
public void UsingInlineData(string pokemonName, string pokemonType, Pokemon.PokemonType expectedPokemonType)
{
    var pokemonFactory = new PokemonFactory();

    var pokemon = pokemonFactory.CreatePokemon(pokemonName, pokemonType);

    Assert.Equal(expectedPokemonType, pokemon.Type);
}

And for a data array, the MemberData attribute:

public static IEnumerable<object[]> PokemonData => new[]
{
    new object[] { "Bulbasaur", "Grass", Pokemon.PokemonType.Grass },
    new object[] { "Charmander", "Fire", Pokemon.PokemonType.Fire },
    new object[] { "Squirtle", "Water", Pokemon.PokemonType.Water },
    new object[] { "ProfessorOak", "Human", Pokemon.PokemonType.UnsupportedType },
};

[Theory]
[MemberData(nameof(PokemonData))]
public void UsingMemberData(string pokemonName, string pokemonType, Pokemon.PokemonType expectedPokemonType)
{
    var pokemonFactory = new PokemonFactory();

    var pokemon = pokemonFactory.CreatePokemon(pokemonName, pokemonType);

    Assert.Equal(expectedPokemonType, pokemon.Type);
}

Final thoughts

In this post, we went over all the three most common C# test frameworks and showed how we can write parametrized tests to avoid manually iterating over the test data.

Do not stop with just what I showed you today. It is cool being able to share the same test data array between several tests, but these frameworks are very complete. The three of them support other types of data sources such as files and services. I encourage you to go to their site and read the documentation of your framework of choice:

MSTest: https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-with-mstest
NUnit: https://docs.nunit.org/
XUnit: https://xunit.net/#documentation

You can find the code of this post at: https://github.com/rogeliogamez92/blog-data-driven-testing

Using multiple appsettings.json to release to different platforms in .NET

Rogelio Gámez — Sat, 18 Feb 2023 22:28:54 +0000

Challenges

You need to release the same application to different platforms with different settings, for example, different log configurations. And you also want to ease up the release process instead of configuring by managing that complexity from the app itself.

There is also a request from the user to be able to overwrite these settings, but you don't want them messing up the big appsettings.json you have set up. You only want them to focus on the two or three properties that they are interested in.

Solutions

You can load different settings files depending on the build configuration using preprocessor directives.

Taking advantage of the IConfiguration file load order, we can add support for a user settings file that will only contain specific properties.

Settings files

You have an application with five different settings files:

appsettings.json: contains the global settings for the application to work correctly.
appsettings.debug.json: in this file, we have the correct settings to run the application in debug mode on your dev environment.
appsettings.azure.json: we override properties for the app to work on Azure.
appsettings.linux.json: we override properties for the app to work on Linux.
appsettings.user.json: in this file, we only have the properties that the user may want to override when they deploy the application.

appsettings.json has the following properties:

{
  "GlobalSetting": "this is a global setting",
  "PlatformSetting": "default for platform setting",
  "UserSetting": "default for user setting"
}

The properties mean:

GlobalSetting: this setting is shared between all the possible deployment platforms.
PlatformSetting: this setting is platform specific, it needs to be different in Linux, Azure, and debug.
UserSetting: this setting will be overridden by the user if they need it.

The debug, Linux, and Azure files will only configure the PlatformSetting and the user file will only configure the UserSetting.

Why do we have a specific `appsettings.user.json`?

Sometimes, the user needs to override certain settings from your application, but you have a very complex appsettings.json. Using a specific file for the user solves the following problems:

The user can only on the properties they care about, they don't need to handle your massive global settings file.
We have the option to not include the user file in our project. If we chose to not include it, we can safely update our application without overwriting the user settings file in the process.

Project build configurations

To support different platforms, we need to set up our project with different configurations:

For this example, our .csproj file has the three different configurations we support:

<PropertyGroup>
    ...
    <Configurations>Debug;ReleaseAzure;ReleaseLinux</Configurations>
</PropertyGroup>

This is how the .sln is configured:

GlobalSection(SolutionConfigurationPlatforms) = preSolution
    Debug|Any CPU = Debug|Any CPU
    ReleaseAzure|Any CPU = ReleaseAzure|Any CPU
    ReleaseLinux|Any CPU = ReleaseLinux|Any CPU
EndGlobalSection

Defining constants

Next, we need to define some constants we can use in the preprocessor directives.

If you want to know more about preprocessor directives, please visit https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives.

We can define them in the .csproj:

<PropertyGroup Condition=" '$(Configuration)' == 'ReleaseAzure' ">
    <DefineConstants>AZURE</DefineConstants>
</PropertyGroup>

<PropertyGroup Condition=" '$(Configuration)' == 'ReleaseLinux' ">
    <DefineConstants>LINUX</DefineConstants>
</PropertyGroup>

Loading settings files

First, we need to include these three NuGet packages in our project:

<ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Configuration" Version="7.0.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.Binder" Version="7.0.3" />
    <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="7.0.0" />
</ItemGroup>

Next, we will be loading the settings files using IConfiguration.AddJsonFile, and use the #if preprocessor directive to select which platform file to load.

This example uses a console application in dotnet 6. Program.cs looks like this:

using Microsoft.Extensions.Configuration;

var configurationBuilder = new ConfigurationBuilder();

configurationBuilder.AddJsonFile("appsettings.json");

#if DEBUG
configurationBuilder.AddJsonFile("appsettings.debug.json");
#elif AZURE
configurationBuilder.AddJsonFile("appsettings.azure.json");
#elif LINUX
configurationBuilder.AddJsonFile("appsettings.linux.json");
#endif

configurationBuilder.AddJsonFile("appsettings.user.json");

var configuration = configurationBuilder.Build();

Console.WriteLine(configuration.GetValue<string>("GlobalSetting"));
Console.WriteLine(configuration.GetValue<string>("PlatformSetting"));
Console.WriteLine(configuration.GetValue<string>("UserSetting"));

Testing the configurations

Now, if we run our application using the debug configuration, it will take the configuration of the debug settings file:

> dotnet run --configuration Debug
this is a global setting
this is debug
overwritten by appsettings.user.json

We can also do the same for other configurations:

> dotnet run --configuration ReleaseAzure
this is a global setting
this is azure
overwritten by appsettings.user.json

> dotnet run --configuration ReleaseLinux
this is a global setting
this is linux
overwritten by appsettings.user.json

Final thoughts

This was a very simple tutorial, but I hope you can see the advantages of this approach.

For example, in your build pipeline, you can publish for different configurations by simply changing the configuration in the command. The application already handles the complexity of different platforms within itself.

Another advantage is that you can have as many "users" settings files as you want. Your team can handle the global and platform settings files, and different teams in your org can handle their files with the properties they care about. Just don't forget to have all of them properly documented in your org knowledge base to avoid any confusion!

The code used for this post can be found at: https://github.com/rogeliogamez92/blog-multiple-apsettings.

DEV Community: Rogelio Gámez

What is code pollution and how to fix it - A dependency injection lesson

What is code pollution?

Examples of code pollution

How to fix code pollution

References

Using the Adapter pattern to migrate to a new library

Problem statement: migrating to a new library

Solution: implement the adapter pattern before migrating

The adapter pattern

Migrating to a new library

Example: from Newtonsoft.Json to System.Text.Json

References

Further reading

Why you should never use DateTime.Now directly - Dealing with Volatile Dependencies in C#

Problem Statement

Volatile Dependencies

Dealing with Volatile Dependencies

Unit Testing DateTime.Now through an Interface

Final Thoughts

References

Don't break production when you add new features! - Feature Toggles in C#

Problem statement: You broke production after you added a new feature ):

Proposed solution: Feature Toggles

Downside of Feature Toggles

Feature Toggles good practices

The feature toggle manager should not be a concrete object

In your unit tests, do not check if the feature toggle is enabled or not, mock it!

Have a formal approach to deal with feature toggles

References

Stop manually iterating over your test data in your unit tests! - Parametrized tests in C# using MSTest, NUnit, and XUnit

Anti-pattern: manually iterating over test data

Solution: parametrized testing

Example application: Pokémon Factory

Parametrized tests in MSTest

Parametrized tests in NUnit

Parametrized tests in XUnit

Final thoughts

Using multiple appsettings.json to release to different platforms in .NET

Challenges

Solutions

Settings files

Why do we have a specific appsettings.user.json?

Project build configurations

Defining constants

Loading settings files

Testing the configurations

Final thoughts

Why do we have a specific `appsettings.user.json`?