DOC = 테스트가 실제 대상 코드에 의존하는 코드

• 구동에 많은 자원이 필요
  • ex. 외부 시스템에 의지하는 경우
• 환경 제어가 어려움

sut

• 인터페이스를 준수하는 대역 코드를 사용
• 대역 코드가 계약을 DOC와 동일하게 준수할 것이라고 가정

• Dummy: SUT 준비를 위해 해결되어야 하는 의존성이 테스트 대상 논리에 의해 사용되지 않는 경우에 의존 요소를 대신하는 테스트 대역

  • 특정 시나리오에서는 사용되지 않음

  

  logic이 테스트 대상, 하지만 테스트 비대상이 dependency가 있다면 테스트를 위해 해당 dependency에서 오류를 뱉지 않도록 적절하게 작성 → dummy

• stub: 간접 입력 대역, 미리 준비된 답을 출력

• Spy: 간접 출력 대역, SUT의 간접 출력을 기록

• mock: SUT 내부의 행위 검증 → test double의 의미로 쓰기도 함

• fake: 의존성 계약을 준수하는 가벼운 구현체, DOC보다 적은 부작용, 인메모리 데이터베이스 등

test double에 대해서 좀 더 정리해보자!

→ 스턴트맨을 Stunt Double이라고 하는거랑 같은 이유로 test double이라고 함

→ 원본 객체 대신 test double로 테스트를 한다는 의미

→ 아래에 나오는 여러 test double 모델?은 어떤 방식?으로 테스트를 하겠다는 의미?

• dummy
  • 객체는 전달되지만 사용되지 않는 객체
  • ex. 함수 파람에 전달되는 빈 객체 등
• stub
  • 호출된 요청에 대해 미리 준비해둔 결과를 제공
  • 테스트를 위해 프로그래밍된 내용 외에는 응답하지 않음
• spy
  • stub의 역할을 가지면서 호출된 내용에 대해 약간의 정보를 기록
  • 테스트에서 확인하기 위한 정보
  • ex. 메일링 서비스에서 발송된 메일 갯수를 기록
  • 이름을 잘 지은거 같은데...?
• fake
  • 동작하는 구현을 가지고 있지만 실제 프로덕션에는 적합하지 않은/동일하지 않은 객체
  • 단순화된 버전의 동작을 제공하기도 함
• mock
  • 호출에 대한 기대를 명세하고 해당 내용에 따라 동작하도록 프로그래밍 된 객체
  • mock을 사용하면 구현부와 결합되는 부분이 많아진다?
    • 명세하는 과정에서 구체적으로 메서드 명과 인자값이 어떻게 전달될지를 지정
    • 구현부와 결합되어 있을때 리팩토링시 방해 요소

Q. 어떤 방식인지는 알겠는데 이렇게 모델이 나눠져 있다는 것은 각 모델에 기대되는 바가 다를거 같은데 어떤 상황에서 어떤게 더 적절한지에 대한 기준이 있나?