자바와 Junit을 활용한 실용주의 단위 테스트 5장

5. 좋은 테스트의 조건 FIRST

5.1 FIRST

https://santim0ren0.medium.com/clean-code-unit-test-3e4b9ee63cb3

5.2 First: 빠르다

• 테스트를 빠르게 유지해야 함
• 하루에 서너번 실행하기도 버겁다면 잘못된 것
• 지속적이고 종합적인, 빠른 피드백을 주지못하면 테스트의 가치가 떨어짐
• 테스트가 느리다면, 디비와 같은 외부 의존성을 줄여라
  • 외부 의존성은 테스트를 느리게 할 뿐만 아니라 디비에서 값이 변하면 테스트 결과도 변할 것이기에 테스트 자가 불안해짐
  • 책의 예시
    • before: given절에서 테스트를 위한 데이터를 실 디비에서 가져옴
    • after:
      • 1. 디비 조회 결과를 받아서 함수에 주입해주는 방식으로(method argument) 테스트하고자하는 함수를 분리
      • 2. 테스트 코드에선 (디비 결과라고 가정된) 해시맵/리스트를 만들어 테스트
      • 3. 테스트가 빨라졌고 느린 것에 의존하는 코드도 최소화되어 더 나아졌다고 할 수 있음

 

5.3 Independent/Isolated: 고립시킨다

• 단위테스트: 검증하려는 작은 양의 코드에 집중
• 최소의 의존성
  • 테스트를 깨뜨리지 않는/ 느리게 하지 않는 / 가용성 / 접근성
• 다른 단위 테스트에 의존하지 않도록
• 순서나 시간에 관계없이 실행되어야
• SRP: 테스트가 하나 이상의 이유로 깨진다면 테스트를 분할하라

 

5.4 Repeatable: 반복 가능해야한다

• 실행할 때마다 같은 결과 보장
• 직접 통제할 수 없는 외부 환경에 있는 항목들과 격리
• 시간을 다뤄야 한다면? 
  • java8.time.Clock 객체를 주입받아(생성자나 setter로 생성시 주입) / 책의 예시

 

5.5 Self validating: 스스로 검증 가능하다

• 테스트 결과를 수동으로(로그를 눈으로 읽는다거나)하는 방식은 시간이 많이 들고 리스크가 있음
  • -> 자동화 해야
• CI(지속적 통합;저장소 감지하여 빌드와 테스트)/CD(지속적 배포;)

 

5.6 Timely: 적시에 하다

• 단위 테스트를 언제 작성하는가?
  • 단위 테스트는 좋은 습관.
  • 절대 미루지말라. 한번 미루면 다시 테스트를 작성하기는 힘들어진다.
• 팀 내 규칙을 세우라
  • ex. 테스트되지 않은 코드는 반영하지 않는다, CI 환경에 확인할 수 있도록 한다..
• 옛날 코드에 대한 테스트는 시간 낭비가 될 수도
  • 코드에 큰 결함이 없고 당장 변경 예정이 없다면 그 노력을 신규 코드에