Що відбувається з тестами методів, коли цей метод стає приватним після перепроектування в 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. щось щось, глузуючи зі Складності.

З мого досвіду, переорієнтація на менші класи та більш короткі методи приносить величезні переваги. Їх простіше зрозуміти, їх легше перевірити, і в кінцевому підсумку використовувати повторно більше, ніж можна було очікувати.

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

Тут слід пам’ятати, що рішення, яке ви приймаєте, - це видалити метод з API . Ввічливість зворотної сумісності підказала б

1. Якщо вам не потрібно його видаляти, залиште його в API
2. Якщо вам не потрібно , щоб видалити його ще , то помітити його як застарілий і , якщо можливо , коли документ до кінця життя буде
3. Якщо вам потрібно його видалити, то у вас є основна зміна версії

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

Після цього ви повертаєтесь до стандартного питання про те, чи повинен ваш тестовий набір мати прямий доступ до реалізацій, а не взаємодіяти лише через загальнодоступний API. Приватний метод - це те, що ми повинні бути в змозі замінити без тест-пакету . Тож я б очікував, що пара тестів до неї піде - або вийдуть на пенсію, або переходять із впровадженням до окремо перевіряемого компонента.