[Clean Code] 9장 - 단위 테스트

내용 요약

• TDD 세 가지 법칙
  1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
• 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리문제를 유발하기도 함
  • 실제 코드가 진화하면 테스트 코드도 변해야하기 때문
  • 테스트 코드가 지저분할수록 변경하기 어려워짐
  • 갈수록 유지보수 비용이 늘어남
• 테스트 슈트가 없다면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다.
• 테스트 코드를 아무렇게나 짜면 없느니만 못한다. 잘 짜야한다. 테스트 코드는 실제 코드 못지 않게 중요함
• 테스트 케이스가 있으면 변경이 두렵지 않다!
• #유연성 #유지보수성 #재사용성
• 깨끗한 테스트 코드를 만들려면?
  1. 가독성
  2. 가독성
  3. 가독성
• 가독성을 위해 도메인 특화 언어 (Domain specific language, DSL) 로 작성하자.
  • given-when-then 이라는 함수 이름 관례 사용
• 테스트 당 assert 하나 : assert가 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽다. 상황에 따라 2개 이상의 assert 문을 쓸 수도 있지만, 최대한 줄이는 게 좋다.
• 테스트 당 개념 하나
• 깨끗한 테스트의 다섯 가지 규칙 (FIRST)
  1. Fast : 테스트는 빨리 돌아야 한다.
  2. Independent : 각 테스트가 서로 의존하면 안된다.
  3. Repeatable : 특정 환경에서만 테스트가 돌게 해선 안된다.
  4. Self-validating : 테스트는 bool 값으로 결과를 내야한다.
  5. Timely : 테스트는 적시에 작성해야한다. 단위테스트의 경우 테스트하려는 실제 코드를구현하기 직전에 구현한다.

느낀 점

나는 실무에서 TDD를 실천하는데 어려움을 느끼고 있다. 실무에서는 실제 코드를 작성하고 테스트를 작성하는 경우가 대부분일 정도로 TDD에 익숙해지지 않은 상태이다. 이 부분을 공부하면서 TDD를 잘 실천했을 때 얻을 이익은 명확해졌지만 어떻게 TDD를 실천해야할지는 감이 없는 상태여서 조금씩 실천해보면서 장점을 느껴봐야겠다.

이 책에서는 테스트 코드가 있으면 변경이 두렵지 않다고 했지만, 간단한 수정이어도 테스트 코드를 고치는 공수가 많이 들어서 쉽게 변경하기 어려운 경우도 종종 있는 것 같다. 그래서 테스트 코드를 깔끔하게 짜는 것이 실제 코드를 깔끔하게 짜는 것 만큼 중요하다고 하는 것 같다.

DSL로 작성하라는 지침과 assert 문을 줄이라는 지침이 공감이 되었다.