[Nomad Coder] 노개북 클린코드 챌린지 2기 Assignment 12

 

TIL (Today I Learned)

 

오늘 읽은 범위

9장. 단위 테스트

 

 

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

• 1997년도만 해도 TDD(Test Driven Development)라는 개념을 아무도 몰랐다.
• TDD 법칙 세 가지
  • 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  • 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  • 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
• 테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 이류 시민이 아니다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.
• 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 이유는 단순하다. 테스트 케이스가 있으면 변경이 두렵지 않으니까! 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍처가 아무리 유연하더라도, 설계를 아무리 잘 나눴더라도, 테스트 케이스가 없으면 개발자는 변경을 주저한다. 버그가 숨어들까 두렵기 때문이다.
• 깨끗한 테스트 코드를 만들려면? 세 가지가 필요하다. 가독성, 가독성, 가독성.
• test 당 assert 하나
• 불행하게도, 위에서 보듯이, 테스트를 분리하면 중복되는 코드가 많아진다. template method pattern을 사용하면 중복을 제거할 수 있다. given/when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 두면 된다. 아니면 완전히 독자적인 테스트 클래스를 만들어 @Before 함수에 given/when 부분을 넣고 @Test 함수에 then 부분을 넣어도 된다. 하지만 모두가 배보다 배꼽이 더 크다. 이것 저것 감안해보면 결국 9-2처럼 assert 문을 여럿 사용하는 편이 좋다고 생각한다.
• 테스트 당 개념 하나
• FIRST
  • Fast : 테스트는 빨라야 한다. 테스트는 빨리 돌아야 한다는 말이다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다. 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다. 코드를 마음껏 정리하지도 못한다. 결국 코드 품질이 망가지기 시작한다.
  • Independent : 각 테스트는 서로 의존하면 안 된다. 한 테스트가 다음 테스트가 실행 될 환경을 준비해서는 안 된다. 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
  • Repeatable : 테스트는 어떤 환경에서도 반복 가능해야 한다.
  • Self-Validating : 테스트는 bool 값으로 결과를 내야 한다. 성공 아니면 실패다.
  • Timely : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다.

 

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

• Given - When - Then 구조가 눈에 익숙하게 들어왔다.
• 가독성이 중요하다는 부분에서 너무 찔렸다. 근데 테스트를 가독성있게 짜는 것은 너무 어려운 것 같다. 끌어올 데이터도 많고, 가지수도 제각각이고, 그걸 다 커버하는 함수를 만들자니 인자가 너무 많이 필요하고... 데이터 셋업이 가장 더러워지기 쉬운 것 같다.

 

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• build-operate-check pattern이 뭘까?
• template-method-pattern
• 도메인 특화 언어(DSL)가 뭘까?
• BDD도 알아보고 싶다.