TIL (2022.02.06 ~ 2022.02.07)

DAY 16~17

🔖 오늘 읽은 범위 : 9장, 단위 테스트 (p.152 ~p.169)

---

😃 책에서 기억하고 싶은 내용을 써보세요.

• TDD 법칙 세 가지
  1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
  • 이렇게 일하면 매일 수십 개, 매달 수백 개, 매년 수천 개에 달하는 테스트 케이스가 나온다.
  • 하지만 실제 코드와 맞먹을 정도로 방대한 테스트크 코드는 심각한 관리 문제를 유발하기도 한다.
• 깨끗한 테스트 코드 유지하기
  • 문제는 실제 코드가 진화하면 테스트 코드도 변해야 한다는데 있다. 그런데 테스트 코드가 지저분할
    수록 변경하기 어려워진다.
  • 테스트 슈트가 없으면 시스템 이쪽을 수정해도 저쪽이 안전하다는 사실을 검증하지 못한다.
    그래서 결함율이 높아지기 시작한다.
  • 결국 테스트 슈트도 없고, 얼기설기 뒤섞인 코드에, 좌절한 고객과, 테스트에 쏟아 부은 노력이
    허사였다는 실망감만 남는다.
  • 실패를 초래한 원인은 테스트 코드를 막 짜도 좋다고 허용한 결정이었다.
  • 테스트 코드는 실제 코드 못지 않게 중요하다.
  • 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
  • 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다.
• 깨끗한 테스트 코드
  • 가독성, 가독성, 가독성
  • 가독성을 높이려면? 명료성, 단순성, 풍부한 표현력이 필요하다.
  • 도메인에 특화된 테스트 언어
    • API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하므로 테스트 코드를
      짜기도 읽기도 쉬워진다.
  • 이중 표준
    • 테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다.
    • 테스트 환경은 자원이 제한적일 가능성이 낮다. 이것이 이중 표준의 본질이다.
  • 테스트 당 assert 하나
    • 대체로 단일 assert를 지원하는 테스트 언어를 만들려 노력한다.
    • 때로는 주저 없이 함수 하나에 여러 assert 문을 넣기도 한다.
    • 단지 assert문 개수는 최대한 줄여야 좋다는 생각이다.
  • 테스트 당 개념 하나
    • “테스트 함수마다 한 개념만 테스트하라"
    • 이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.
• F.I.R.S.T
  • Fast - 테스트는 빨라야 한다.
  • Independent - 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
  • Repeatable - 테스트는 어떤 환경(실제 환경, QA 환경, 버스안에서) 에서도 반복 가능해야 한다.
  • Self-Validating - 테스트는 부울 값으로 결과를 내야 한다. 성공 아니면 실패다.
  • Timely - 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에
    구현한다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• TDD는 아직 업무에 제대로 적용해보질 못했고 단위테스트라도 열심히 작성하자! 라고 시도했다. 그리고 실패했다. 처음엔 그래도 열심히 작성했는데 바쁜 일정을 맞추려다 보니 테스트코드는 뒷전이 됐고 그렇게 돌아가지도 않는 실패된 테스트 코드 더미가 되어버렸다. 책을 읽고 테스트코드를 계속 신경 썼더라면 기능을 수정하고 추가할 때 코드를 믿고 자신감 있고 빠르게 수정 할 수 있지 않았을까? 라는 생각이 들었다... 항상 소감은 자기반성으로 끝나는 것 같다...
  

기록하신 TIL을 공유해주세요 - TIL 출석표

클린코드_스케쥴러_TIL 출석표 (노개북1기)

소감 3줄 요약

• 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
• 테스트 함수마다 한 개념만 테스트 하라.
• 깨끗한 테스트는 F.I.R.S.T 규칙을 따른다.