Question

Let’s say you’re developing a product using TDD. You incrementally add tests and end up with a big method. Now it’s time to refactor, so you separate the method in smaller methods. For example;

// Before refactoring.
public void SomeMethod()
{
    // ...
    int sum = numbers.Sum();
    // ...
}

// After refactoring.
public void SomeMethod()
{
    // ...
    int sum = GetSumOfNumbers(numbers);
    // ...
}

private GetSumOfNumbers(int[] numbers)
{
    return numbers.Sum();
}

After this step, should you write tests for the GetSumOfNumbers method? I think when we test SomeMethod, we already test GetSumOfNumbers. But at the same time, there may be other methods using GetSumOfNumbers and even though it works well for SomeMethod, it may not for another one. This would help us find the problem faster (as tests will give a more specific error). But at the same time, maybe this is not useful, and adds verbosity.

What do you think about it? And in the example, the GetSumOfNumbers method is private, so if you think it shouldn’t be tested just because it’s private, should it be tested if it’s public?

Answer 1

You should test the public API of your classes. Don’t test the private methods. Doing so, will create a test suite that is coupled too tightly to your classes. Every internal change in your class would break some tests in your test suite.

If you think you should test a specific private method – maybe because it performs some complex or complicated logic – that’s a smell telling you that it might be time to move that method into a new class.