[Book - Clean Code] 9. 단위 테스트
TDD 법칙 세 가지
- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.
깨끗한 테스트 코드 유지하기
테스트 코드는 실제 코드 못지 않게 중요하므로, 깨끗하게 짜자.
테스트는 유연성, 유지보수성, 재사용성을 제공한다
코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.
테스트 케이스가 없다면 모든 변경이 잠정적인 버그이다.
이와 반대로, 테스트 케이스가 있으면 변경이 두렵지 않다!
그러므로 실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다.
깨끗한 코드
깨끗한 테스트 코드를 만들려면 가독성이 가장 중요하다.
테스트 당 assert 하나
assert 문이 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
불가피한 경우 assert 문이 늘어날 수 있겠지만, 최대한 줄여 테스트의 목적을 잃지 말자.
테스트 당 개념 하나
가장 좋은 규칙은 “개념 당 assert 문 수를 최소로 줄여라”와 “테스트 함수 하나는 개념 하나만 테스트하라”다.
F.I.R.S.T
First(빠르게)
테스트는 빨라야 한다.
Independent(독립적으로)
각 테스트는 서로 의존하면 안 된다. 즉, 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
Repeatable(반복 가능하게)
어떤 환경에서도 반복 가능해야 한다.
Self-Validating(자가검증하는)
bool 값으로 결과를 내야 한다. 즉, 성공 아니면 실패다.
Timely(적시에)
테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
결론
테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화한다.
그러므로 지속적으로 깨끗하게 관리하자.
테스트 API를 구현해 도메인 특화 언어(DSL)를 만들자.
그럴수록 테스트 코드를 짜기 쉬워진다.
테스트 코드가 방치되어 망가지면 실제 코드도 망가진다.