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다른 테스트에 의해 테스트되고 있음을 의미 합니다. 이는 의 테스트에 의해 간접적으로 적용됨을 의미합니다 . 이상적으로는로 변경하면 하나 이상의 테스트를 중단해야 합니다.receiveAttackattackreceiveAttackattack

그렇지 않은 경우 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 텍스트를 작성하십시오.

내 경험상 소규모 클래스와 짧은 메소드로 리팩토링하면 큰 이점이 있습니다. 이해하기 쉽고 테스트하기 쉬우 며 기대 이상으로 재사용됩니다.

receiveAttack 메소드를 테스트하는 10 가지 메소드가 있다고 가정 해보십시오. 이제 Character.attack (Character) 메소드 (receiveAttack 메소드를 호출 함)를 추가하고, 일부 TDD 주기로 테스트 한 후에 결정을 내립니다. Character.receiveAttack (Int)는 private이어야합니다.

여기서 명심 해야 할 것은 API에서 메소드를 제거하는 것입니다 . 이전 버전과의 호환성에 대한 제안은

1. 제거 할 필요가 없으면 API에 그대로 두십시오.
2. 아직 제거 할 필요가없는 경우 폐기 된 것으로 표시하고 가능한 경우 수명이 다한 문서를 표시하십시오.
3. 제거해야 할 경우 버전이 크게 변경되었습니다.

API가 더 이상 메소드를 지원하지 않으면 테스트가 제거되거나 교체됩니다. 이 시점에서 private 메소드는 리팩토링 할 수 있어야하는 구현 세부 사항입니다.

이 시점에서 테스트 스위트가 구현에 직접 액세스해야하는지 공개 API를 통해 순수하게 상호 작용해야하는지에 대한 표준 질문으로 돌아 왔습니다. 프라이빗 메소드는 테스트 스위트가 방해받지 않고 대체 할 수 있는 것 입니다. 따라서 테스트가 중단되거나 구현과 함께 테스트 가능한 개별 구성 요소로 이동하여 테스트가 사라질 것으로 기대합니다.