TDD 법칙 세 가지
The Three Laws of TDD
1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
깨끗한 테스트 코드 유지하기
Keeping Tests Clean
지저분한 테스트 코드는 안 하느니만 못하며, 오히려 비용이 늘어날 수 있다.
테스트 코드는 실제 코드 못지 않게 중요하고, 실제 코드 못지 않게 깨끗하게 짜야 한다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다
Tests Enable the -ilities
코드에 유연성, 유지보수성, 재상용성을 제공하는 버팀목은 단위 테스트이다.
테스트 케이스가 있으면 변경이 쉬워진다.
깨끗한 테스트 코드
Clean Tests
깨끗한 테스트 코드를 만들려면 가독성, 가독성, 가독성이 필요하다.
가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요하다.
BUILD-OPERATE-CHECK 패턴이 테스트 구조에 적합하다.
도메인에 특화된 테스트 언어
Domain-Specific Testing Language
함수와 유틸리티를 구현하여 테스트 API를 만들면 테스트 코드를 짜기도 읽기도 쉬워진다.
이중 표준
A Dual Standard
실제 환경과 달리 테스트 환경은 자원이 제한적일 가능성이 낮고,
테스트 코드가 실제 코드만큼 효율적일 필요는 없다.
테스트 당 assert 하나
One Assert per Test
JUnit으로 테스트 코드를 짤 때는 함수마다 assert문을 단 하나만 사용해야 한다.
때로는 함수 하나에 여러 assert문을 넣기도 하지만, assert문 개수는 최대한 줄이는 게 좋다.
테스트 당 개념 하나
Single Concept per Test
개념 당 assert 문 수를 최소로 줄이고,
테스트 함수 하나는 개념 하나만 테스트하라.
F.I.R.S.T
F (Fast), 빠르게
테스트는 빨리 돌아야 한다.
I (Independent), 독립적으로
각 테스트는 서로 의존하면 안 되며, 독립적으로 어떤 순서로 실행해도 괜찮아야 한다.
R (Repeatable), 반복가능하게
테스트는 어떤 환경에서도 반복 가능해야 한다.
S (Self-Validating), 자가검증하는
테스트는 부울 값으로 결과를 내야 한다. 성공 아니면 실패다.
T (Timely), 적시에
단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
결론
테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다.
테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다.
그러므로 테스트 코드는 지속적으로 깨끗하게 관리하고, 표현력을 높이고 간결하게 정리하자.
테스트 API를 구현해 도메인 특화 언어(DSL)을 만들자.
📖 느낀점
여지껏 나는 실제 코드를 짜기 전에 테스트 코드를 먼저 짠 적이 있는가? 생각해보면 부끄럽지만 없다고 대답할 수 밖에 없다.
매번 'TDD를 도입해서 개발해야지'라는 막연한 생각만 가지고 아직까지도 개발을 하며 '당장 급해' 라는 핑계로 테스트 코드를 제대로 짜본 적이 없다.
이번장을 읽으며 참 많은 반성을 하게 된다. 생각만 가지는 게 아닌 TDD에 대해 더 공부하고 실제 코드를 짜기 전에 테스트 코드를 짜는 습관을 가지는 사람이 되고 싶다.
