What happens with methods' tests when that method become private after re-design in TDD?

Question

Let's say I start developing a role game with characters that attack other characters and that kind of stuff.

Applying TDD, I make some test cases to test the logic inside Character.receiveAttack(Int) method. Something like this:

@Test
fun healthIsReducedWhenCharacterIsAttacked() {
    val c = Character(100) //arg is the health
    c.receiveAttack(50) //arg is the suffered attack damage
    assertThat(c.health, is(50));
}

Say I have 10 methods testing receiveAttack method. Now, I add a method Character.attack(Character) (that calls receiveAttack method), and after some TDD cycles testing it, I make a decision: Character.receiveAttack(Int) should be private.

What happens with previous 10 test-cases? Should I delete them? Should I keep method public (I don't think so)?

This question is not about how to test private methods but how to deal with them after a re-design when applying TDD

Answer 1

In TDD, the tests serve as executable documentation of your design. Your design changed, so obviously, your documentation must, too!

Note that, in TDD, the only way in which the attack method could have appeared, is as the result of making a failing test pass. Which means, attack is being tested by some other test. Which means that indirectly receiveAttack is covered by attack's tests. Ideally, any change to receiveAttack should break at least one of attack's tests.

And if it doesn't, then there is functionality in receiveAttack that is no longer needed and should no longer exist!

So, since receiveAttack is already tested through attack, it doesn't matter whether or not you keep your tests. If your testing framework makes it easy to test private methods, and if you decide to test private methods, then you can keep them. But you can also delete them without losing test coverage and confidence.

Answer 2

If the method is complex enough to need testing, it should be public in some class. So you refactor from:

public class X {
  private int complexity(...) {
    ...
  }
  public void somethingElse() {
    int c = complexity(...);
  }
}

to:

public class Complexity {
  public int calculate(...) {
    ...
  }
}

public class X {
  private Complexity complexity;
  public X(Complexity complexity) { // dependency injection happiness
    this.complexity = complexity;
  }

  public void something() {
    int c = complexity.calculate(...);
  }
}

Move the current test for X.complexity to ComplexityTest. Then text X.something by mocking Complexity.

In my experience, refactoring toward smaller classes and shorter methods pays huge benefits. They are easier to understand, easier to test, and end up being reused more than one might expect.

Answer 3

Say I have 10 methods testing receiveAttack method. Now, I add a method Character.attack(Character) (that calls receiveAttack method), and after some TDD cycles testing it, I make a decision: Character.receiveAttack(Int) should be private.

Something to keep in mind here is that the decision you are making is to remove a method from the API. The courtesies of backwards compatibility would suggest

1. If you don't need to remove it, then leave it in the API
2. If you don't need to remove it yet, then mark it as deprecated and if possible document when the end of life will happen
3. If you do need to remove it, then you have a major version change

The tests get removed / or replaced when your API no longer supports the method. At that point, the private method is an implementation detail that you should be able to refactor away.

At that point, you are back in the standard question of whether your test suite should be directly accessing implementations, rather interacting purely through the public API. A private method is something that we should be able to replace without the test suite getting in the way. So I would expect the tests couple to it to go away -- either getting retired, or moving with the implementation to a separately testable component.