[클린코드 요약] 9. 단위 테스트

TDD 법칙 세 가지

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

 주의할 점은 실제 코드와 맞먹을 정도로 많은 테스트 코드는 관리가 힘들다는 것이다. 실제 코드가 변경됨에 따라 테스트 코드도 변화해야 하는데 테스크 코드가 복잡하고, 지저분할수록 테스트 코드에 대한 부담이 늘어난다.

 그렇다면 깨끗한 테스트 코드를 유지하려면 어떻게 해야 할까? 명료성, 단순성, 풍부한 표현력으로 가독성을 높이면 된다.

 그리고 또 주의할 점은 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있을 수도 있다는 것이다. 실제 환경과 테스트 환경의 요구사항은 판이하게 다르다.

 JUnit으로 테스트 코드를 짤 때는 함수마다 assert문을 단 하나만 사용해야 한다고 주장하는 학파가 있는데, 결론이 하나라서 코드를 이해하기 쉽고 빠르다는 장점이 있다. 하지만 코드의 중복이 심해지면 assert문을 여러 개 사용해도 좋다고 저자는 생각한다고 한다. 결론적으로는 assert문의 개수는 최대한 줄여야 좋다고 생각한다고 한다.

 가장 좋은 규칙은 개념 당 assert문 수를 최소로 줄이라는 것과 테스트 함수 하나는 개념 하나만 테스트하라는 것이다.

 깨끗한 테스트는 다음 다섯 가지 규칙(F.I.R.S.T)를 따른다.

1. 빠르게(Fast) : 테스트는 빨리 돌아야 한다.

2. 독립적으로(Independent) : 각 테스트는 서로 의존하면 안된다.

3. 반복가능하게(Repeatable) : 테스트는 어떤 환경에서도 반복 가능해야 한다.

4. 자가검증하는(Self-Validating) : 테스트는 부울 값으로 결과를 내야 한다.

5. 적시에(Timely) : 실제 코드를 구현하기 전에 테스트 코드를 작성해야 한다.

 테스트 API를 구현해 도메인 특화 언어(DSL)를 만들면 그만큼 테스트 코드를 짜기 쉬워진다.