TDD ‐ Managing Test Context - thought-corner/backend-roadmap GitHub Wiki

분리된 입/출력 설계

• 소프트웨어는 출력을 통해 가치를 생산한다.
• 출력되지도 않고 출력물 가공에 사용되지도 않는 입력은 쓸모가 없다.
• 입력 기능이 아무것도 출력하지 않거나 제한된 정보만 출력할 때 입력 기능 테스트를 작성하는 프로그래머는 입력된 정보가 내부 저장매체에 기대한 대로 입력되는지 검증하고 싶어 다음과 같은 유혹에 빠질 수 있다.
  • 테스트가 내부 저장매체에 접근하게 한다.
  • 입력 기능의 출력을 강화하도록 설계를 변경한다.
• 1번 방법은 경우에 따라 고려해 볼만 하지만 2번 방법은 테스트만을 위해 인터페이스 설계를 변경하는 피해야 할 결정이다.
• 충분히 더 나은 방법으로 입/출력 기능을 함께 설계하고 구현할 수 있다.

오염된 명령 생성

• 시스템은 비즈니스 규칙을 위배하는 입력을 적절하게 방어해야 하는 의무가 있다.
• 잘못된 입력 방어에 대한 테스트 시나리오에는 일부 정보가 올바르지 않은 입력 데이터가 필요하다.
• Java 언어 명세에는 레코드 클래스 인스턴스의 일부 정보만 쉽게 교체할 수 있는 기능은 없다.
• Lombok 기능도 고려해 볼 수 있지만 테스트 코드 작성을 위해 운영 코드 설게를 변경하는 것은 가급적 피하는 것이 바람직하다.

테스트 격리⭐

• 격리된 테스트의 이점
  • 테스트의 목적과 과정을 이해하기 쉽다.
  • 테스트가 실패했을 때 원인을 파악하기 쉽다.
  • 테스트 결과가 테스트 실행 범위와 순서에 영향을 받지 않는다.
• Spring 빈 범위는 Singleton, Prototype, Request 등 여러 가지가 있다.
• 기본 범위인 Singleton 범위를 적용하면 Spring 컨테이너 당 하나의 빈 정의에 하나의 인스턴스가 생성되어 사용된다.
• Prototype 범위를 적용하면 빈 요청이 있을 때마다 새로운 빈 인스턴스를 생성한다.
• @Scope 어노테이션을 사용해서 빈 범위를 지정할 수 있다.

과도한 테스트 격리의 문제는 무엇이 있을까?

• 시스템 구성요소 간 중요한 상호작용이 반영되지 않을 수 있다.
• 과도하게 테스트 대역이 사용된다.
• 부적절한 설계 왜곡이 유도된다.
• 실효성 없는 다수의 테스트가 작성될 수 있다.
• 격리된 환경을 조성하기 위해 테스트 실행 성능이 저하될 수 있다.