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

2022. 03. 06


📚 오늘 읽은 범위
9장. 단위 테스트


📖 책에서 기억하고 싶은 내용
- TDD 법칙 세 가지 (p.155)
   1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
   2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
   3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
- 문제는 실제 코드가 진화하면 테스트 코드도 변해야 한다는 데 있다. 그런데 테스트 코드가 지저분할수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다. (p.156)
- 테스트 코드는 실제 코드 못지 않게 중요하다. (p.157)
- 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. (p.157)
- 실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다. (p.157)
- 깨끗한 테스트 코드를 만들려면? 세 가지가 필요하다. 가독성, 가독성, 가독성. (p.158)
- 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. (p.158)
- BUILD-OPERATE-CHECK 패턴
   BUILD : 테스트 자료를 만든다.
   OPERATE : 테스트 자료를 조작한다.
   CHECK : 조작한 결과가 올바른지 확인한다.
- 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다. (p.164)
- given-when-then : 테스트 케이스를 작성하는 반 구조화된 방법 (p.165)
- TEMPLATE METHOD 패턴 : 알고리즘의 구조를 변경하지 않고 알고리즘의 특정 단계들을 다시 정의할 수 있게 해 줌 (p.165)
- “테스트 함수 하나는 개념 하나만 테스트하라” (p.167)
- F.I.R.S.T : 깨끗한 테스트의 다섯 가지 규칙 (p.167-168)
   빠르게 Fast : 테스트는 빨리 돌아야 한다.
   독립적으로 Independent : 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
   반복가능하게 Repeatable : 테스트는 어떤 환경에서도 반복 가능해야 한다.
   자가검증하는 Self-Validating : 테스트는 부울 bool 값으로 결과를 내야 한다.
   적시에 Timely : 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
- 테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. (p.168)
- 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하자. 테스트 API를 구현해 도메인 특화 언어 DSL를 만들자. 그러면 그만큼 테스트 코드를 짜기가 쉬워진다. (p.168)


🙌 오늘 읽은 소감
- TDD를 많이 들어보긴 했으나 아직까지 경험해보지 못했다. 그래서 그런지 이번 장은 코드 자체는 이해가 가더라도 이게 어떤 상황에서 어떻게 쓰이는지 정확하게 알기 어려웠다. 테스트 코드만 책 한 권 분량인 주제라고 하니 이런 겉핥기로 바로 이해하기는 어렵겠다는 생각이 들었다. 다음에 TDD에 대해 집중적으로 공부하고 다시 읽어보면서 이 부분을 채워나가자.
- 테스트 코드는 실제 코드만큼이나 중요하다는 글을 읽고 나니 다음 프로젝트를 진행할 때 TDD를 이용하여 진행해봐야겠다.
- 세상에는 정말 배울 게 산더미구나. 꾸준히 공부하다 보면 채워나갈 수 있겠지! 차근차근해나가다 보면 어느샌가 잘 쌓여진 내가 있을 거라고 생각한다. 하나씩 해보자!!