Что происходит с тестами методов, когда этот метод становится приватным после перепроектирования в TDD?

Допустим, я начинаю разрабатывать ролевую игру с персонажами, которые атакуют других персонажей и тому подобное.

Применяя TDD, я делаю несколько тестов для проверки логики внутри Character.receiveAttack(Int)метода. Что-то вроде этого:

@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));
}

Скажем, у меня есть 10 методов тестирования receiveAttackметода. Теперь я добавляю метод Character.attack(Character)(который вызывает receiveAttackметод), и после нескольких циклов тестирования TDD я принимаю решение: Character.receiveAttack(Int)должно быть private.

Что происходит с предыдущими 10 тестами? Должен ли я удалить их? Должен ли я сохранить метод public(я так не думаю)?

Этот вопрос не о том, как тестировать частные методы, а о том, как обращаться с ними после перепроектирования при применении TDD

В TDD тесты служат исполняемой документацией вашего проекта. Ваш дизайн изменился, поэтому, очевидно, ваша документация тоже должна!

Обратите внимание, что в TDD единственный способ, которым attackмог появиться метод, - это результат неудачного прохождения теста. Это значит, attackчто проверяется другим тестом. Это означает, что косвенно receiveAttack охватывается attackтестами России. В идеале любое изменение receiveAttackдолжно нарушить хотя бы один из attackтестов.

И если это не так, то есть функциональность, receiveAttackкоторая больше не нужна и больше не должна существовать!

Таким образом, поскольку receiveAttackтестирование уже пройдено attack, не имеет значения, выполняете ли вы свои тесты или нет. Если ваша среда тестирования позволяет легко тестировать приватные методы, и если вы решите тестировать приватные методы, вы можете оставить их. Но вы также можете удалить их, не теряя тестовое покрытие и уверенность.

Если метод достаточно сложен для тестирования, он должен быть общедоступным в некотором классе. Таким образом, вы рефакторинг от:

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

чтобы:

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(...);
  }
}

Переместите текущий тест для X.complexity в ComplexityTest. Затем текст X.something, насмешливо Сложность.

По моему опыту, рефакторинг в сторону небольших классов и более коротких методов приносит огромные выгоды. Их легче понять, проще тестировать, и в итоге их используют больше, чем можно было ожидать.

Скажем, у меня есть 10 методов тестирования метода receiveAttack. Теперь я добавляю метод Character.attack (Character) (который вызывает метод receiveAttack), и после нескольких циклов тестирования TDD я принимаю решение: Character.receiveAttack (Int) должен быть закрытым.

Здесь следует иметь в виду, что решение, которое вы принимаете, заключается в удалении метода из API . Любезность обратной совместимости предполагает

1. Если вам не нужно удалять его, оставьте его в API
2. Если вам не нужно , чтобы удалить его еще , то пометить его как устаревший и , если возможно , когда документ до конца жизни будет
3. Если вам нужно удалить его, то у вас есть серьезное изменение версии

Тесты удаляются / заменяются, когда ваш API больше не поддерживает метод. На этом этапе приватный метод - это деталь реализации, которую вы должны иметь возможность рефакторинга.

В этот момент вы вернулись к стандартному вопросу о том, должен ли ваш набор тестов иметь прямой доступ к реализациям, а взаимодействовать исключительно через общедоступный API. Закрытый метод - это то, что мы можем заменить, не мешая при этом тестам . Поэтому я ожидаю, что пара тестов уйдет в прошлое - либо выйдет на пенсию, либо перейдет с реализацией к отдельному тестируемому компоненту.