12/26 TIL 단위 테스트 1장~2장

단위 테스트 기초

제품 코드와 테스트 코드의 비율은 보통 1:1에서 ~1:3. 많으면 1:10까지
테스트 코드가 제품 코드보다 많아지는 것 같아 이게 맞나 싶었는데, 이게 정상이였다.

단위 테스트의 주요 목표는 소프트웨어 프로젝트의 지속 가능한 성장이다.
더 나은 설계가 주요 목표가 아니다!

테스트코드 짜기 쉬움은 좋은 설계에 대한 좋은 부정 지표지만, 좋은 긍정 지표는 아니다. (테스트 짜기 쉽다고 좋은 설계는 아닌 것)
테스트 커버리지 역시 좋은 테스트에 대한 좋은 부정 지표지만, 좋은 긍정 지표는 아니다.
커버리지에 집착하지 말자.

테스트 코드도 역시 코드고, 모든 코드는 자산이 아닌 책임(부채)이다.  좋지 않은 코드는 지우자!

모든 코드를 똑같이 작성할 필요는 없다.

테스트의 비용 요소

• 테스트 리팩토링
• 코드 변경 시 테스트 실행
• 잘못된 경고를 하는 테스트 처리
• 코드의 동작을 알기 위해 테스트를 읽는 시간

성공적인 테스트의 특성

• 개발 주기에 통합돼 있다.
• 코드베이스에서 가장 중요한 부분 (비즈니스 로직; 도메인 모델) 을 대상으로 한다.
• 최소한의 유지비로 최대의 가치를 끌어낸다.
  • 가치 있는 테스트를 식별해( Frame of reference를 이용)
  • 가치 있는 테스트를 작성해야 한다. (식별보다 어려움)

---

단위 테스트의 정의

런던파

• 작은 코드 조각을 검증하고
• 빠르게 수행하고
• 격리된 방식으로 처리하는 자동화된 테스트

고전파

• 단일 동작 단위를 검증하고
• 빠르게 수행하고
• 다른 테스트와 별도로 처리한다.

런던파 테스트는 '상호작용'을 검사한다. - 바른 호출이 있었는지
고전파 테스트는 실행후 '상태'를 검증한다.

런던파 테스트는 자연스럽게 하향식 개발을 하게 된다.
고전파 테스트는 자연스럽게 상향식 개발을 하게 된다.

저자는 고전파 테스트를 선호한다.

통합 테스트

위의 단위 테스트의 기준을 어긴 테스트. 보통 외부 프로세스와 통신을 하는 경우다.
엔드 투 엔드 테스트는 통합 테스트에 포함되는 개념이다. (테스트 대역을 아예 사용하지 않아야 하는 것은 아니다.)

의존성의 종류

• 공유 의존성
• 비공개 의존성
• 프로세스 외부 의존성
• 휘발성 의존성

참고

단위 테스트 https://product.kyobobook.co.kr/detail/S000001805070

느낀점

데이터베이스를 어떻게 분리해 테스트할지 고민하면서 책을 찾아보게 되었는데, 데이터베이스는 '공유 의존성' 이면서 '프로세스 외부 의존성' 으로 관련 객체를 모두 테스트하는 고전파 테스트에서도 배제하는 객체라는 걸 알게 되었다. 책의 중반부까지만 읽어도 현재 프로젝트에 단위 테스트를 작성하는데 많은 도움이 될 것 같다.