오늘 읽은 범위
9장. 단위 테스트
책에서 기억하고 싶은 내용
-
TDD 법칙 세 가지
- 첫번째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
- 두번째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 세번째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
=> 주의 사항 : 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 함
-
깨끗한 테스트 코드 유지하기
- 테스트 코드가 지저분할 수록 변경하기 어렵고 실패하는 테스트 코드를 통과시키기 어렵다.
- 테스트 코드는 실제 코드 못지 않게 중요하며 사고와 설계와 주의가 필요하다.
- 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
- 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.
- 테스트 커버리지가 높을 수록 별다른 우려 없이 아키텍처와 설계를 개선할수 있다. -
깨끗한 테스트 코드
- 깨끗한 테스트 코드를 만들기 위한 것은 가독성이 필요하다.
- 가독성을 높이기 위해서 필요한 것은 명료성, 단순성, 풍부한 표현력(최소한의 표현으로 많은 것을 나타냄)이 필요하다.
- 코드를 간결하고 표현력이 풍부한 코드로 리팩터링 해야한다.
- 이중 표준 : 테스트 환경은 자원이 제한적일 가능성이 낮기 때문에 실제 코드에서는 사용을 피하는 것도 테스트 코드에서는 사용할 수 있다.(코드의 깨끗함과는 철저히 무관)
-
테스트 당 assert 하나
- JUnit으로 테스트 코드를 짤 때는 함수마다 assert 문을 단 하나만 사용하자.
=> assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
- 테스트 함수마다 한 개념만 테스트하자.- 개념 당 assert문 수를 최소로 줄여라.
-
F.I.R.S.T
- Fast(빠르게) : 테스틑 빨라야 한다.
- Independent(독립적으로) : 각 테스트는 서로 의존하면 안된다.
- Repeatable(반복가능하게) : 테스트는 어떤 환경에서도 반복 가능해야 한다.
- Self-Validating(자가검증하는) : 테스트는 부울(bool)값으로 결과를 내야한다. 실패 아니면 성공으로만 나야지 판단이 주관적이 되면 지루한 수작업 평가가 필요하게 된다.
- Timely(적시에) : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
- 결론
- 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화한다.
- 테스트 코드는 지속적으로 꺠끗하고 표현력을 높여 간결하게 정리하여 관리하자.
- 테스트 API를 구현해 도메인 특화 언어(DSL)를 만들자.
오늘 읽은 소감
테스트 코드의 중요성을 알았지만 알면서도 작성하지 않고 프로젝트 기한에 맞추기에 급급해 제대로된 테스트 코드를 작성하지 않고 통합 테스트를 통해 오류를 찾고 수정해왔다.
이번 챕터를 통해 테스트 코드의 중요성을 다시금 깨닫고 실제 코드를 구현하기 전에 단위 테스트를 구현하라는 규칙을 배울 수 있게 되어 좋았다.
이직을 준비할때 면접 봤던 회사에서 간단한 API 구현 과제를 받은 적이 있는데 구현 조건 중 테스트 코드를 작성하라는 것이 있었다. 나는 코드를 구현하고 테스트 코드를 작성했는데 단위 테스트를 하려고 보니 작성하기 너무 어려웠고 결국 통합 테스트밖에 못하고 제출했던 기억이 있다.
결국 면접에서 왜 단위 테스트는 안했냐는 질문을 받았고 물론 그것때문에 떨어진 것은 아니지만 아쉬움이 많이 남았었다. 지금 생각해보니 단위 테스트를 적시에 작성하지 않아서 구현이 더 어려웠던 것 같다. 이번에 알았으니 앞으로 적시에 작성하여 단위 테스트를 작성하는 습관을 길러야겠다.
궁금한 내용 또는 잘 이해되지 않는 내용
BUILD-OPERATE-CHECK 패턴
given-when-then
TEMPLATE METHOD 패턴
