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

스터디 메인 페이지

- ☆ 표시가 붙은 부분은 스터디 중 나온 얘기 혹은 제 개인적인 생각이나 제가 이해한 방식을 적어놓은 것으로, 책에서 말하고자 하는 바와 다를 수 있습니다.

- 모든 이미지의 출처는 클린 코드(로버트 C. 마틴 저) 책 입니다.

 

 

---

9장 단위 테스트

⚈ TDD의 세 가지 법칙

• 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
• 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
• 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

 

⚈ 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유뱔하기도 한다.

 

⚈ 테스트 코드는 실제 코드 못지 않게 중요하다.

• 테스트를 안 하느니 지저분한 테스트 코드라도 있는 편이 좋다는 판단 -> 오히려 안하는 것 보다 못하다. 테스트 코드가 지저분할수록 실제 코드도 지저분해진다.
• 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 단위테스트다. -> 테스트 케이스가 있으면 변경이 두렵지 않기 때문.
• 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.

 

⚈ 깨끗한 테스트 코드를 만들려면? -> 가독성이 가장 중요.

 

⚈ F.I.R.S.T

• Fast 빠르게 : 빠르게 수행되야 함. 느리면 자주 돌림 엄두를 못냄.
• Independent 독립적으로 : 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안됨. 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 함.
• Repeatable 반복가능하게 : 어떤 환경에서도 반복 가능해야 한다. 테스트가 돌아가지 않는 환경이 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
• Self-Validating 자가검증하는 : 테스트는 기대하는 결과가 무엇인지 단언(assert)해야 함. 즉, 각 테스트는 성공 또는 실패여야 함. (bool 값으로 결과를 내야 함).
• Timely 적시에 : 테스트는 적시에 작성해야 함. (테스트하려는 실제 코드를 구현하기 직전에 구현). 테스트 코드를 미루지 말고 적시에 작성하자. 테스트를 제때 작성하지 않고 미루면 테스트가 불가능하도록 실제 코드를 설계하는 등 문제가 발생함.