[클린코드] 9장 단위 테스트

TDD로 구현해 본 경험이 없지만 정리하면서 이해하고자 했다.

 

---

 

TDD 법칙 세 가지

실제 코드를 짜기 전 단위 테스트부터 짜라고 요구한다.

• 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
• 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
• 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

이 법칙을 지키면 사실상 실제 코드를 전부 테스트하는 테스트 케이스가 나온다.

 

 

깨끗한 테스트 코드 유지하기

실제 코드가 진화하면 테스트 코드도 변해야 한다.

하지만 테스트 코드가 지저분할수록 변경하기 어려워진다.

 

악순환

• 지저분한 테스트 코드로 인해 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다. 
• 그래서 테스트 코드가 늘어나는 부담을 얻는다.
• 점차 테스트 코드는 개발자 사이에 가장 큰 불만으로 자리 잡는다.
• 결국 테스트 슈트를 폐기하지 않으면 안 되는 상황에 처한다.
• 하지만 테스트 슈트가 없으면 개발자는 자신이 작성한 코드가 제대로 도는지 확인할 방법이 없다.
• 점점 결함율이 높아지기 시작한다.
• 개발자는 변경을 주저한다.
• 코드가 망가진다.

테스트 코드는 실제 코드 못지않게 중요하다.

 

 

테스트는 유연성, 유지보수성, 재사용성을 제공한다.

테스트 케이스가 있으면 변경이 쉬워지기 때문이다.

• 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.
• 테스트 커버리지가 높을수록 공포는 줄어든다.
• 실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다.

 

 

깨끗한 테스트 코드

준비물 : 가독성, 가독성, 가독성

• 테스트 코드는 최소한의 표현으로 많은 것을 나타내야 한다.
• 테스트 코드는 본론에 돌입해 진짜 필요한 자료 유형과 함수만 사용한다.
• 그래야만 코드가 수행하는 기능을 재빨리 이해할 수 있다.

 

 

테스트 당 assert 하나

• assert문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽다.
• 필요에 의하면 assert문을 여러개 작성해도 된다. 하지만 assert문 개수는 최대한 줄이는 것이 좋다.

 

 

테스트 당 개념 하나

• 개념 당 assert문 수를 최소로 줄여야 한다.
• 테스트 함수 하나는 개념 하나만 테스트해야 한다.

 

 

F.I.R.S.T 규칙

Fast 빠르게

• 테스트는 빨라야 한다.
• 테스트가 느리면 자주 돌릴 엄두를 못 낸다.

 

Independent 독립적으로

• 각 테스트는 서로 의존하면 안 된다.
• 한 테스트가 다음 테스트 실행 환경을 준비해서는 안 된다.
• 각 테스트는 독립적으로, 그리고 어떤 순서로 실행해도 괜찮아야 한다.

 

Repeatable 반복 가능하게

• 테스트는 어떤 환경에서도 반복 가능해야 한다.
• 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
• 예를 들자면 버스를 타고 집으로 가는 길에 사용하는 노트북 환경에서도 실행할 수 있어야 한다.

 

Self-Validating 자가검증하는

• 테스트는 Boolean 값으로 결과를 내야 한다.
• 성공 아니면 실패다.

 

Time 적시에

• 테스트는 적시에 작성해야 한다.
• 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.