[클린 코드] Assignment #11: TIL - 9장. 단위 테스트 + 나의 최애 북틸

 

📢 DAY 14 ~ 15
🏷️ 오늘 읽은 범위: 9장. 단위 테스트

🖊️ 짧은 내용 요약

🧹 테스트 코드도 깔끔하게 유지해야 하는 이유

요즘은 TDD와 같은 테스트 주도 개발 프로세스를 따라 개발을 진행하면서 많은 테스트 코드를 작성하게 된다. 이때, 테스트 코드를 깔끔하게 작성하지 않으면 테스트 코드가 복잡하고 지저분해지면서, 실제 코드보다 짜는데 시간도 오래 걸리고, 변경도 어려워진다. 그러면 실제 코드를 테스트하기 어려워지기 때문에 실제 코드에서 결함이 발생할 가능성이 높고, 이게 걱정되어 실제 코드를 유연하게 변경하기 어려워진다. 그렇기 때문에 테스트 코드는 실제 코드 못지 않게 깨끗하게 짜야 한다.

 

💡 깨끗한 테스트 코드의 장점은?

테스트 케이스가 있으면 안정성을 제공해 실제 코드의 변경이 쉬워지면서 코드의 유연성, 유지보수성, 재사용성을 제공한다. 

 

🛠️ 깨끗한 테스트 코드를 만드려면?

• 테스트 코드의 가독성을 높이자.
  잡단한 코드를 없애서 명료하게 코드를 작성해 가독성을 높인다. ① 테스트 자료를 만들기,  ② 테스트 자료를 조작하기,  ③ 조작한 결과가 올마른지 확인하기, 이 3단계로 구분해서 작성하면 테스트 코드를 명료하게 작성할 수 있다.
• 테스트 API를 구현해 도메인 특화 언어를 만들자.
  테스트 코드르 짜기도, 읽기도 쉬워진다.
• 테스트 함수마다 한 개념만 테스트하고, 개념 하나 당 assert 문을 최소로 줄이자.

단, 테스트 코드는 결국 테스트 환경에서만 돌아가는 코드이기 때문에 실제 코드만큼 효율적일 필요는 없다. 

 

📖 깨끗한 테스트 코드가 따르는 5가지 규칙

• Fast: 테스트는 빨라야 한다.
  테스트가 빠르게 진행되지 않으면 테스트를 여러 번 하기 여려워지면서 초반에 문제를 찾아내지 어렵다.
• Independent: 테스트는 서로 의존하면 안 된다.
  테스트가 서로 의존하면 실패의 원인을 진단하기 어려워지고 테스트가 찾아내야 하는 결함을 찾지 못하게 된다.
• Repeatable: 모든 환경에서 테스트가 돌아가도록 한다.
  환경이 지원되지 않아서 테스트를 수행하지 못하는 상황을 만들지 않도록 한다.
• Self-validating: 테스트는 bool값으로 결과를 낸다.
  판단이 주관적이거나 복잡해지면 수작업을 요하면서 지루해지게 된다.
• Timely: 단위 테스트는 테스트를 하려는 실제 코드를 구현하기 직전에 만든다.
  실제 코드를 작성한 뒤 테스트 코드를 만들면, 테스트가 불가능하게 실제 코드를 설계할 수도 있어서 실제 코드를 테스트하기 어려워진다.

😀 책에서 기억하고 싶은 내용

테스트 코드가 방치되어 망가지면 실제 코드도 망가진다.
테스트 코드를 깨끗하게 유지하자. (p. 168)

하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한 (그리고 더욱 중요한) 사실을 놓쳐버렸다. (p. 155)

하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다. (p. 155)

테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 있으면 변경이 쉬워지기 때문이다. (p. 157)

테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다. 그러므로 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하자. 테스트 API를 구현해 도메인 특화 언어를 만들자. 그러면 그만큼 테스트 코드를 짜기가 쉬워진다. (p. 168)

테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자. (p. 168)

🤔 오늘 읽은 소감 & 떠오르는 생각

부끄럽게도 프로젝트는 여러 번 수행해 보았지만, 테스트 코드를 작성해본 적이 없다...그래서 이번에 졸업 프로젝트를 하면서는 테스트 코드를 꼭 작성해 봐야겠다는 생각을 했다. 테스트 코드를 작성하기 전에 깨끗하고 좋은 테스트 코드를 작성하는 방법을 먼저 배울 수 있게 되어서 좋다고 생각했다. 실제로 테스트 코드를 작성해보면 책의 내용이 더 깊게 이해될 것 같다.

🔍 새로 알았거나 잘 이해되지 않는 내용

• TDD(Test Driven Development)
  테스트 주도 개발의 약자다. 요구 사항에 맞는 테스트 케이스를 작성한 뒤 케이스를 통과하기 위한 최소한의 코드를 생성한다. 이 과정을 반복하면서 매우 짧은 사이클을 반복하는 개발 프로세스이다.
• BUILD-OPERATE-CHECK
  테스트 자료를 만든다-테스트 자료를 조작한다-조작한 결과를 확인한다
• DSL(Domain-Specific Languages)
  특정 도메인에 최적화된 프로그래밍 언어.
• given-when-then
  준비-실행-검증

💘 나의 최애 북틸

1. Jihyoung님의 [개발 도서] Clean Code :: 9장 - 단위 테스트 / 도메인에 특화된 언어 부분 이해 x
   전체 내용을 예시를 들어 잘 정리하셔서 책의 내용을 이해할 때 참고하게 되었다.
2. rancho974의 [Clean Code | 9장 단위 테스트 ] Day14
   TIL을 읽으면서 rancho974님 덕분에 '단위 테스트'와 '이펙티브 소프트웨어 테스팅'라는 새로운 책을 알게 되었다.
3. jinjanic91님의 TIL 8장 경계 ~ 9장 단위 테스트
   구체적으로 TDD를 자신의 분야에 어떻게 적용하면 좋을지 고민해보는 것이 좋은 것 같다.

📚 참고

• https://jay-flow.medium.com/tdd%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B4%EB%A9%B0-%EC%99%9C-%ED%95%84%EC%9A%94%ED%95%9C%EA%B0%80-18cb5979629c
• https://brunch.co.kr/@springboot/292