<aside> 1️⃣ 테스트는 문서다

</aside>

• 개발자로서 기술에 대한 숙련도 또한 중요하지만 소프트 스킬도 중요하다.
  • 커뮤니케이션, 태도, 몰입도, 자세, 문서작성 등등
• 테스트는 production코드만큼 중요한데 이게 무엇인가 생각해보면 테스트는 문서다.

문서

• 프로덕션 기능을 설명하는 테스트 코드 문서
• 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완한다.
• 어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산으로 공유할 수 있다.

<aside> 2️⃣ DisplayName을 섬세하게 적자

</aside>

• DisplayName의 구성
  • Junit5부터 생겼다.

• 이제 어떤게 명확할지 DisplayName을 보자
  • 당연히 아래의 길게 작성한 부분이 이 코드를 처음본다 생각했을때 알아보기 쉽다.

• 명사의 나열보다는 문장으로 적자
  • a이면 b이다 → 이렇게말고
  • a이면 b가 아니고 c이다. → 이렇게 적어라
  • 그리고 위에처럼 음료 1개 추가 테스트 → 이런식으로 뒤에 테스트를 적는것을 지양해라
• 테스트 행위에 대한 결과까지 기술하자

<aside> 3️⃣ DisplayName을 섬세하게 적는방법

</aside>

• 작성 예시 → 주문 생성 테스트코드 기준
  • 특정 시간 이전에 주문을 생성하면 실패한다. (나쁜)
  • 영업 시작 시간 이전에는 주문을 생성할 수 없다. (좋은)
    • 이런 도메인 용어를 사용하여 한층 추상화된 내용을 담아라 (메서드 자체의 관점보단 도메인 정책 관점으로)
    • 테스트의 현상을 중점으로 기술하지 말자
      • (”실패한다.” → 이런식으로 적지말자 테스트하려는 내용과는 무관하다.)

<aside> 4️⃣ BDD 스타일로 작성

</aside>

• BDD: Behavior Driven Development
  • TDD에서 파생된 개발 방법
  • 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 테스트케이스(TC) 자체에 집중하여 테스트한다.
  • 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준(레벨)을 권장한다.