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

TDD 법칙 세 가지

TDD: 실제 코드를 짜기 전에 단위 테스트부터 짜는 개발 방식

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

위 규칙을 따면 개발과 테스트가 약 30초 주기로 함께 나온다.

하지만 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

 

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

지저분한 테스트 코드를 짜는 것은 테스트를 안 하는 것보다 못하다.

• 실제 코드가 진화하면 테스트 코드도 변해야 한다.
  • 테스트 코드가 지저분하면 변경하기 어려워진다.
• 테스트 코드가 복잡할 수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 길어진다.
• 새 버전을 출시할 때마다 테스트 케이스를 유지 보수 하는 비용이 늘어나게 된다.

테스트 코드는 실제 코드 못지않게 깨끗하게 짜야한다.

 

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

테스트 케이스가 없으면 의도치 않은 버그가 발생할까 봐 코드 변경을 주저하게 된다.

따라서 테스트 케이스는 개발자가 안심하고 코드를 변경하여 아키텍처나 설계를 개선할 수 있도록 만든다.

 

깨끗한 테스트 코드

깨끗한 테스트 코드에서 가장 중요한 건 가독성이다. (실제 코드보다도 더!)

테스트 코드는 최소의 표현으로 많은 것을 나타내야 하기 때문에 명료성, 단순성, 풍부한 표현이 필요하다.

 

BUILD-OPERATE-CHECK 패턴

테스트를 명확히 세 부분으로 나눈다.

1. BUILD: 테스트 자료를 만든다.
2. OPERATE: 테스트 자료를 조작한다.
3. CHECK: 조작한 결과가 올바른지 확인한다.

세세한 코드는 다른 함수로 분리하여 제거하고 진짜 필요한 자료 유형과 함수만 사용하도록 짜야한다.

세세한 코드(예제에서 시스템 조작 API)를 함수로 분리한 것은 테스트 코드에서 사용하는 특수 API가 된다.

 

이중 표준

테스트 코드는 실제 환경이 아니라 테스트 환경에서 돌아가는 코드이다.

따라서 실제 코드만큼 효율적일 필요는 없다.

실제 환경이 실시간 임베디드 시스템처럼 메모리나 CPU 효율과 관련 있어도 테스트 코드는 실제 환경에 적용되는 표준을 따를 필요는 없다.

 

테스트 당 assert 하나

장점

• 결론이 하나이기 때문에 코드를 쉽고 빠르게 이해할 수 있다.

단점

• 중복 코드가 많아진다.
• 테스트 클래스가 늘어난다.

trade-off가 존재하므로 assert 문 개수는 최대한 줄이되, 여러 assert문을 넣는 것을 주저할 필요는 없다.

 

테스트 당 개념 하나

여러 개념을 연속으로 테스트하는 긴 함수는 피한다.

여러 개념이 한 함수에 존재하면 독자가 테스트 코드를 이해하는 데 시간이 오래 걸린다.

개념 당 assert문 수를 최소로 줄여라. 테스트 함수 하나는 개념 하나만 테스트하라.

 

F.I.R.S.T

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

• Fast: 테스트를 자주 돌릴 수 있도록 빨라야 한다.
• Independent: 각 테스트는 서로 의존하면 안 된다. 어떤 순서로 실행해도 괜찮아야 한다.
• Repeatable: 어떤 환경에서도 반복적으로 실행이 가능해야 한다. 환경이 테스트 실패의 이유가 되면 안된다.
• Self-Validating: 테스트는 성공 아니면 실패로 결과를 내야 한다. 개발자의 주관이 필요하면 안된다.
• Timely: 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

 

결론

• 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 강화한다.
• 테스트 코드는 표현력을 높이고 간결하게 정리하자.
• 테스트 API를 구현해 놓으면 테스트 코드를 짜기 쉬워진다.
• 테스트 코드가 망가지면 실제 코드도 망가진다. 테스트 코드를 지속적으로 깨끗하게 관리하자.

---

마무리

이전 회사에서 Django로 백엔드 개발을 맡았던 적이 있다.

그때 백엔드에 처음 유닛 테스트를 도입했었던 경험이 있어 읽는 데 무리는 없었던 것 같다.

테스트 코드를 짜고 유지보수 하면서 가장 후회했던 부분은 중복 코드가 너무 많아 가독성이 떨어지는 것이었다. 한 테스트 케이스에 너무 많은 내용을 테스트하려고 했고 테스트 코드 파일은 한없이 커져갔었다. 

 

그래서인지 이 장에서 가장 와닿았던 부분은 다음 두 가지였다.

• 테스트 API로 중복 코드와 테스트의 본질을 흐리는 세부적인 코드를 분리하는 것
• 테스트 케이스 당 하나의 개념만 테스트하라

 

이 장을 읽다 보니 내가 테스트 코드를 깔끔하게 만드는 것의 중요성을 간과하고 있었음을 깨달았다.

테스트만 잘 돌아가면 되지란 생각이 깊이 박혀있었던 것 같다. (조금 귀찮아하기도 했다🥲)

이 전의 후회와 이번에 알게 된 테스트 코드의 중요성을 발판 삼아 다음 개발 때는 훨씬 좋은 테스트 코드를 짤 수 있을 것 같다.