클린코드 9장 : 단위 테스트

단위 테스트에 대한 저자의 의견이다.

 

TDD 법칙 세 가지

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

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

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

 

(단위) 테스트코드는 코드의 유연성, 유지보수성, 재사용성을 제공하는 버팀목이다. 

이런 테스트코드가 없다면, 코드를 수정하고 개선하는 능력이 떨어진다.

 

다만, 이렇게 만든 테스트코드도 여러가지 문제를 야기한다.

프로젝트가 커짐에 따라서 테스트 코드는 점점 많아져서 

 

저자의 경험에 따르면 (실제 코드처럼) 테스트 코드를 잘 깨끗하게 작성하지 않으면 점점 이를 사용하고 리팩터링 힘들어지게 되고 결국 폐기하게 된다한다.

 

그러면 테스트코드를 안전하게 운영하는 법을 알아보자.

 

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

저자가 생각하는 가장 중요한 조건은 가독성이다. 

이런 가독성을 잡기 위해서 저자는 BUILD-OPERATE-CHECK 패턴을 제안한다.

생성, 운영, 확인으로 "테스트 자료 생성 - 테스트 자료 조작(운영) - 테스트 결과 확인"으로 테스트 코드를 작성하라는 것이다.

 

* 나중에 나오는 예시를 보면, give-when-then 형식의 관례적인 이름을 붙이기도 하는 것 같다.

 

또한, 가독성을 살려야하기 때문에, 잡다하고 세세한 코드 없이 정말 필수적인 자료와 코드로 쉽고 빠르게 이해할 수 있도록 짜는 것을 권장한다.

 

이렇게 짜기 위해서 아래 몇 가지 조언을 해준다.

- 도메인 특화 테스트 언어 (DSL 등)을 잘 활용할 것.

- 간결하고 명확하게 짜되, 실제코드처럼 효율적인 필요는 없음. 

- 테스트 함수 하나 당 개념 하나만 테스트할 것. (assert 문은 최대한 줄여서 작성할 것이란 개념이기도 하다.)

 

F.I.R.S.T

깨끗한 테스트는 다음 다섯 가지 규칙을 따른다. 이 규칙의 첫 글자를 따오면 FIRST가 된다.

 

- 빠르게(Fast) : 테스트는 빨라야한다. 테스트가 느리면 자주 돌리지 않고, 문제를 잘 찾지 못한다. 코드를 정리하지도 못하고 결국 코드가 망가진다.

- 독립적으로(Independent) : 각 테스트는 의존하면 안된다. 어떤 순서로 실행해도 괜찮아야하며, 다른 테스트의 환경을 준비해서도 안된다. 의존성이 생길 경우, 하나가 실패하면 다른 테스트는 연달아 실패하여 원인을 찾기 힘들어진다.

- 반복가능하게(Repeatable) : 테스트는 어떤 환경에서도 반복가능해야한다. 테스트가 돌아가지 않은 환경이 있다면, 테스트가 실패한 이유에 대해서 변명이 생긴다. 또한 환경이 없어서, 테스트를 수행하지 못하는 상황을 직면할 수도 있다.

- 자가검증하는(Self-Validating) : 테스트는 true/false로 결과를 내야한다. 로그를 읽게 만들거나 비교하여 판단하려하면 테스트가 주관적이 되며 검증과정을 필요로 하게 된다.

- 적시에(Timely) : 테스트는 적시에 작성해야한다. 단위 테스트는 실제 코드를 구현하기 직전에 구현한다. 코드를 구현한 후에는 테스트하기 어려울 수도 있고, 어떤 코드는 불가능할 수도 있고, 테스트가 불가능하도록 코드를 만들 수도 있다.

 

느낀점(개인 의견)

- 테스트 커버리지는 높을 수록 좋다. 하지만, 반드시 100퍼일 필요는 없다는 의견을 많이 들었다. 너무 모든 코드에 테스트코드를 짜려고 집착하지는 말아야겠다.

- 프론트엔드분들이랑 이야기 했을 때는 테스트 코드를 잘 작성하는 분을 많이는 못 본 거 같다. "대부분 효율적이지 못하다" 라는 답변을 들었다. 백과 다른 프론트의 특징일지, 저자가 말한대로 제대로 운영하지 못해서 그런 것인지는 내가 해봐야 알 거 같다.