클린 코드 독서일지 - Day 17

도메인에 특화된 테스트 언어

가독성을 위해 테스트 코드에서만 사용하는 특수 API를 사용하는 것도 좋다.

이중 표준

실제 환경과 테스트 환경은 요구사항이 다르다.
=> 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있음(메모리나 CPU 효율과 관련 있는 경우 등)

테스트 당 assert 하나

함수마다 assert 문을 단 하나만 사용해야 한다고 주장하는 의견들이 있음
assert문이 하나인 함수는 결론이 하나라 코드를 이해하기 쉽고 빠르지만, 꼭 지켜야만 하는 법칙은 아니다.
=> 테스트 코드를 짜다 보면 assert를 여럿 두는 편이 가장 간결하고 이해하기 쉬울 때가 있음.
다만 assert문 개수는 최대한 줄이는 편이 좋다.

테스트 당 개념 하나

테스트 함수마다 한 개념을 테스트하라는 규칙은 지키는 게 좋다.
=> 여러 개념을 한 함수로 몰아넣으면 독자가 각 절이 거기에 존재하는 이유와 각 절이 테스트하는 개념을 모두 이해해야 함

F.I.R.S.T.

깨끗한 테스트가 따르는 다섯 가지 규칙을 FIRST라고 함

1. 빠르게(Fast) : 테스트는 빨리 돌아야 한다.
   => 느린 테스트 코드는 자주 돌릴 엄두를 못 내어, 결국 테스트 적용이 힘들게 된다.
2. 독립적으로(Independent) : 각 테스트는 서로 의존하면 안 되며, 어떤 순서로 실행해도 괜찮아야 한다.
   => 테스트가 서로에게 의존하면 하나가 실패할 때 나머지도 잇달아 실패하므로 원인을 진단하기 어려워진다.
3. 반복가능하게(Repeatable) : 테스트는 어떤 환경에서도 반복 가능해야 한다.
   => 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
4. 자가검증하는(Self-Validating) : 테스트는 성공 혹은 실패를 나타내는 부울 값으로 결과를 내야 한다.
   => 테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되며 수작업 평가가 필요하게 된다.
5. 적시에(Timely) : 테스트 코드는 실제 코드를 구현하기 직전에 작성해야 한다.
   => 실제 코드를 구현한 다음에 테스트 코드를 만들면 테스트가 불가능한 실제 코드를 설계할지도 모른다.

테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하며, 테스트 코드가 방치되어 망가지면 실제 코드도 망가진다.