[Clean Code] TIL - Day 17,18

Clean Code TIL Day 17,18

1. Day 17, 18

🔖 오늘 읽은 범위 :  9장 단위 테스트(p.153 ~ p.170)

---

1.1. 😃 책에서 기억하고 싶은 내용

• TDD 법칙 세 가지(p.155)
  • 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  • 둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  • 셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
• 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다. 실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해, 실패하는 테스트 케이스를 점점 통과시키기 어려워진다.(p.156)
• 테스트 코드는 실제 코드 못지않게 중요하다.(p.157)
• 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 이유는 단순하다. 테스트 케이스가 있으면 변경이 두렵지 않으니까!(p.157)
• 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.(p.157)
• 테스트 코드가 지저분할수록 실제 코드도 지저분해진다. 결국 테스트 코드를 잃어버리고 실제 코드도 망가진다.(p.157)
• 대체로 나는 단일 assert를 지원하는 해당 분야 테스트 언어를 만들려 노력한다. 하지만 때로는 주저 없이 함수 하나에 여러 assert 문을 넣기도 한다. 단지 assert 문 개수는 최대한 줄여야 좋다는 생각이다.(p.165)
• 가장 좋은 규칙은 "개념 당 assert 문 수를 최소로 줄여라"와 "테스트 함수 하나는 개념 하나만 테스트하라"라 하겠다.(p.167)
• 깨끗한 테스트는 다음 다섯 가지 규칙을 따르는데, 각 규칙에서 첫 글자를 따오면 FIRST가 된다.(p.167 ~ p.168)
  • 빠르게(Fast): 테스트는 빨라야 한다.
  • 독립적으로:(Independent): 각 테스트는 서로 의존하면 안 된다.
  • 반복 가능하게(Repeatable): 테스트는 어떤 환경에서도 반복 가능해야 한다.
  • 자가 검증하는(Self-Validating): 테스트는 부울 값으로 결과를 내야 한다.
  • 적시에(Timely): 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현다.
• 테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자.(p.168)

1.2. 🤔 오늘 읽은 소감과 떠오르는 생각

이 부분을 읽기 전까지 TDD라는 말만 들어보고 실제로 TDD가 무엇인지 왜 해야 하는지 모르고 있었다.

직접 단위 테스트를 해본 적이 없어서 코드 예제를 봤을 때 어떤 식으로 코드가 돌아가는 건지 완벽하게 이해하지는 못했지만, 테스트 코드를 작성하게 되면 우리가 구현할 기능을 명확하게 알 수 있을뿐더러 유지보수까지 완벽하게 해낼 수 있다는 걸 알게 되었고 거의 필수라고 생각이 되었다.

다음 프로젝트를 할 때는 이 책의 규칙들을 적용해서 테스트 코드도 한번 꼭 작성해 보고 싶다.

그리고 테스트 코드를 작성하는 습관을 들여서 테스트 코드 없이는 개발을 할 수 없을 정도로 적응하고 싶고 적응할 것이다.

1.3. 🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용

x

1.3.1. 소감 3줄 요약

• 테스트 코드는 실제 코드 못지않게 중요하다.
• 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.
• 깨끗한 테스트 코드는 FIRST 규칙을 따른다.