[Clean Code] 9장 단위테스트

TDD (Test Driven Delveopment) 법칙 ( 실제 코드를 짜기 전에 단위테스트부터 짜야한다)

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

 

위 세가지 큐직을 따르면 매일 수십개, 매달 수백개에 달하는 테스트가 나오고 사실상 전부 테스트하는 테스트 케이스가 나온다.

하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

 

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

실제 코드가 진화하면 테스트 코드도 변해야한다. 그런데 테스트 코드가 지저분할 수록 변경하기 어려워진다.

즉, 테스트 코드가 복잡할 수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 오래걸리고 유지 보수하는 비용도 들어나기 십상이다.

 

<지저분한 테스트 코드 악순환 예시>
1) 테스트 케이스를 추가하는데 시간과 유지보수 비용이 더 들어난다.
2) 유지보수 비용이 너무 많이 들어 테스트 슈트를 폐기해야 하는 상황에 처한다.

3) 테스트 슈트가 없으면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다.

4) 결함율이 높아진다.

5) 결함율이 높아지면 개발자는 변경을 주저한다. (결함율이 점점 높아지기 때문에)

6) 변경하면 득보다 해가 크다고 생각해 더 이상 코드를 정리하지 않는다.

7) 그러다보면 점점 코드가 망가지기 시작해, 테스트 슈트도 없고 지저분한 코드가 남는다..

 

위의 예시에서 얻는 교훈은 깨끗한 테스트 코드는 실제 코드 못지 않게 중요하다는 점이다.

 

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

앞서 말했다싶이 테스트 코드는 실제 코드를 유연하게 만든는 버팀목이다.

이유는 테스트 케이스가 있으면 변경이 두렵지 않기 때문이다.

그러므로 자동화 된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다.

 

깨끗한 테스트 코드

깨끗한 테스트 코드란 가독성이 가장 중요하다. 테스트 코드의 가독성은 실제 코드보다 가독성을 더더 중요하게 생각해야한다.

즉, 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.

 

테스트 케이스 구조

BUILD - OPERATE - CHECK

BUILD : 테스트 자료를 만든다.

OPERATE : 테스트 자료를 조작한다.

CHECK : 조작한 결과가 올바른지 확인한다.

 

테스트 코드는 코드를 읽는 사람이 수행하는 기능을 재빨리 이해할 수 있도록 진짜 필요한 자료 유형과 함수만 사용한다.

 

<테스트 코드에 적용하는 표준은 실제 코드에 적용하는 표준과는 확실히 다르다.
간결하고 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다>

 

테스트 당 assert 하나 && 테스트 당 개념 하나

하나의 개념당 assert문 수를 최소로 줄여라.

 

 

깨끗한 테스트는 다섯가지 규칙을 따른다

FIRST

F (fast) : 테스트는 빨라야 한다. 빨리 돌아야 한다.

I (Independent) : 각 테스트는 서로 의존하면 안된다.

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

S (Self-Validating) : 테스트는 부울(bool)값으로 결과를 내야한다. 성공 아니면 실패인지 스스로 확인하기 위해

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