Co dzieje się z testami metod, gdy metoda ta staje się prywatna po przeprojektowaniu w TDD?

Załóżmy, że zaczynam rozwijać grę RPG z postaciami atakującymi inne postacie i tym podobne rzeczy.

Stosując TDD, wykonuję kilka przypadków testowych w celu przetestowania logiki wewnątrz Character.receiveAttack(Int)metody. Coś takiego:

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

Powiedz, że mam 10 metod testowania receiveAttackmetod. Teraz dodaję metodę Character.attack(Character)(która wywołuje receiveAttackmetodę) i po przetestowaniu jej przez niektóre cykle TDD podejmuję decyzję: Character.receiveAttack(Int)powinno być private.

Co dzieje się z poprzednimi 10 testami? Czy powinienem je usunąć? Czy powinienem zachować metodę public(nie sądzę)?

To pytanie nie dotyczy tego, jak przetestować prywatne metody, ale jak sobie z nimi poradzić po przeprojektowaniu podczas stosowania TDD

W TDD testy służą jako wykonywalna dokumentacja twojego projektu. Twój projekt się zmienił, więc oczywiście twoja dokumentacja również musi!

Zauważ, że w TDD jedynym sposobem, w jaki attackmetoda mogła się pojawić, jest wynik pozytywnego wyniku testu. Co oznacza, attackże jest testowany przez inny test. Co oznacza, że pośrednio receiveAttack jest objęty attacktestami. Idealnie, każda zmiana receiveAttackpowinna przerwać przynajmniej jeden z attacktestów.

A jeśli nie, to funkcjonalność receiveAttacknie jest już potrzebna i nie powinna już istnieć!

Ponieważ receiveAttackjest już przetestowany attack, nie ma znaczenia, czy zachowasz testy. Jeśli środowisko testowe ułatwia testowanie metod prywatnych, a jeśli zdecydujesz się przetestować metody prywatne, możesz je zachować. Ale możesz je również usunąć bez utraty zasięgu testu i pewności siebie.

Jeśli metoda jest na tyle złożona, że ​​wymaga testów, powinna być publiczna w niektórych klasach. Refaktoryzujesz więc z:

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

do:

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

Przenieś bieżący test X.complexity na ComplexityTest. Następnie napisz X. coś przez wyśmiewanie się ze złożoności.

Z mojego doświadczenia wynika, że ​​refaktoryzacja w kierunku mniejszych klas i krótszych metod przynosi ogromne korzyści. Są łatwiejsze do zrozumienia, łatwiejsze do przetestowania, a w końcu są wykorzystywane więcej niż można by się spodziewać.

Powiedzmy, że mam 10 metod testujących metodę receiveAttack. Teraz dodaję metodę Character.attack (Character) (która wywołuje metodę receiveAttack) i po kilku testach TDD testuję ją, podejmuję decyzję: Character.receiveAttack (Int) powinien być prywatny.

Należy pamiętać o tym, że podejmujesz decyzję o usunięciu metody z interfejsu API . Sugerują to uprzejmości związane z kompatybilnością wsteczną

1. Jeśli nie musisz go usuwać, pozostaw go w interfejsie API
2. Jeśli nie musisz go jeszcze usuwać , oznacz go jako przestarzały i, jeśli to możliwe, udokumentuj datę końca życia
3. Jeśli musisz go usunąć, oznacza to poważną zmianę wersji

Testy są usuwane / lub zastępowane, gdy interfejs API nie obsługuje już tej metody. W tym momencie metoda prywatna jest szczegółem implementacji, który powinien być w stanie refaktoryzować.

W tym momencie powracasz do standardowego pytania, czy Twój zestaw testów powinien bezpośrednio uzyskiwać dostęp do implementacji, czy raczej wchodzić w interakcje wyłącznie za pośrednictwem publicznego interfejsu API. Prywatna metoda jest czymś, co powinniśmy być w stanie zastąpić bez przeszkadzania pakietowi testów . Spodziewałbym się więc, że testy się odejdą - albo przejdzie na emeryturę, albo przejdzie wraz z implementacją do osobno testowalnego komponentu.