How can I unit test methods which are using static methods?

Question

Let's assume I wrote an extension method in C# for byte arrays which encodes them into hex strings, as follows:

public static class Extensions
{
    public static string ToHex(this byte[] binary)
    {
        const string chars = "0123456789abcdef";
        var resultBuilder = new StringBuilder();
        foreach(var b in binary)
        {
            resultBuilder.Append(chars[(b >> 4) & 0xf]).Append(chars[b & 0xf]);
        }
        return resultBuilder.ToString();
    }
}

I could test the method above using NUnit as follows:

[Test]
public void TestToHex_Works()
{
    var bytes = new byte[] { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef };
    Assert.AreEqual("0123456789abcdef", bytes.ToHex());
}

If I use the Extensions.ToHex inside my project, let's assume in Foo.Do method as follows:

public class Foo
{
    public bool Do(byte[] payload)
    {
        var data = "ES=" + payload.ToHex() + "ff";
        // ...
        return data.Length > 5;
    }
    // ...
}

Then all tests of Foo.Do will depend on the success of TestToHex_Works.

Using free functions in C++ the outcome will be the same: tests that test methods that use free functions will depend on the success of free function tests.

How can I handle such situations? Can I somehow resolve these test dependencies? Is there a better way to test the code snippets above?

Answer 1

Then all tests of Foo.Do will depend on the success of TestToHex_Works.

Yes. That's why you have tests for TextToHex. If those tests pass, the function meets the spec defined in those tests. So Foo.Do can safely call it and not worry about it. It's covered already.

You could add an interface, make the method an instance method and inject it into Foo. Then you could mock TextToHex. But now you have to write a mock, which may function differently. So you'll need an "integration" test to bring the two together to ensure the parts really work together. What has that achieved other than making things more complex?

The idea that unit tests should test parts of your code in isolation from other parts is a fallacy. The "unit" in a unit test is an isolated unit of execution. If two tests can be run simultaneously without affecting each other, then they run in isolation and so are unit tests. Static functions that are fast, do not have a complex set up and have no side effects such as your example are therefore fine to use directly in unit tests. If you have code that is slow, complex to set up or has side effects, then mocks are useful. They should be avoided elsewhere though.

Answer 2

Using free functions in C++ the outcome will be the same: tests that test methods that use free functions will depend on the success of free function tests.

How can I handle such situations? Can I somehow resolve these test dependencies? Is there a better way to test the code snippets above?

Well, I don't see dependency here. At least not the kind that forces us to execute one test before another. The dependency we build among tests (no matter the kind) is one confidence.

We build a piece of code (test-first or not) and we ensure tests pass. Then, we are in a position of building more code. All the code built upon this first is built upon confidence and certainty. This is more or less what @DavidArno explains (very well) in his answer.

Yes. That's why you have tests for X. If those tests pass, the function meets the spec defined in those tests. So Y can safely call it and not worry about it. It's covered already.

Unit tests should run in any order, any time, any environment and as fast as possible. Whether TestToHex_Works is executed the first or the last should not worry you.

If TestToHex_Works fails due to errors in ToHex, all tests relying on ToHex will end with different results and fail (ideally). The key here is detecting those different results. We do it making unit tests to be deterministic. As you do here

var bytes = new byte[] { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef };
Assert.AreEqual("0123456789abcdef", bytes.ToHex());

Further unit tests relying on ToHex should also be deterministic. If everything in ToHex goes well, the result should be the expected one. If you get a different one, something went wrong, somewhere and this is what you want from a unit test, to detect these subtle changes and fail fast.

Answer 3

It's a bit tricky with such a minimal example, but let's reconsider what we're doing:

Let's assume I wrote an extension method in c# for byte arrays which encodes them into hex strings, as follows:

Why did you write an extension method to do this? Unless you're writing a library to encode byte arrays into strings, this isn't likely to be the requirement you're trying to fulfill. What it looks like you were doing here was trying to fulfill the requirement "Validate some payload which is a byte array" - so the unit tests you're implementing should be "Given a valid payload X, my method returns true" and "Given an invalid payload Y, my method returns false".

So when you initially implement this, you might do the "byte-to-hex" stuff inline in the method. And that's fine. Then later you get some other requirement (e.g. "Display the payload as a hex string") which, while you're implementing it, you realise also requires you to convert a byte array to a hex string. At that point you create your extension method, refactor the old method, and call it from your new code. Your tests for the validation functionality shouldn't change. Your tests for displaying the payload should be the same whether the bytes-to-hex code was inline or in a static method. The static method is an implementation detail you shouldn't care about when writing the tests. The code in the static method will be tested by its consumers. I wouldn't even bother writing tests for it.

Answer 4

Exactly. And this is one of the problems with static methods, another one being that OOP is a much better alternative in most situations.

This is also one of the reasons Dependency Injection is used.

In your case, you may prefer having a concrete converter that you inject into a class which needs a conversion of some values to hexadecimal. An interface, implemented by this concrete class, would define the contract required to convert the values.

Not only would you be able to test your code easier, but you'll also be able to swap implementations later (since there are lots of other possible ways of converting values to hexadecimal, some of them producing different outputs).