[TIL] 클린코드(Clean Code) - 9장. 단위 테스트

📌 오늘 TIL 3줄 요약

• 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.
• 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.
• 테스트 함수 하나는 개념 하나만 테스트하라.

📆 TIL (Today I Learned) 날짜

2022.03.05

📚 오늘 읽은 범위

9장. 단위 테스트

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

• TDD 법칙 세 가지
  • 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  • 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  • 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
• 테스트 코드가 지저분할수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다. 실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해, 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다. 그래서 테스트 코드는 계속해서 늘어나는 부담이 돼버린다.
• 테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 이류 시민이 아니다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.
• 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 이유는 단순하다. 테스트 케이스가 있으면 변경이 두렵지 않으니까! 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍처가 아무리 유연하더라도, 설계를 아무리 잘 나눴더라도, 테스트 케이스가 없으면 개발자는 변경을 주저한다. 버그가 숨어들까 두렵기 때문이다.
• 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다. 테스트 코드가 지저분할수록 실제 코드도 지저분해진다. 결국 테스트 코드를 잃어버리고 실제 코드도 망가진다.
• 테스트 코드에서 가독성을 높이려면 여느 코드와 마찬가지로 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.
• BUILD - OPERATE - CHECK 패턴
  • BUILD : 테스트 자료를 만든다.
  • OPERATE : 테스트 자료를 조작한다.
  • CHECK : 조작한 결과가 올바른지 확인한다.
• 도메인에 특화된 언어(DSL)로 테스트 코드를 구현하는 방법이 있다. 흔히 쓰는 시스템 조작 API를 사용하는 대신 API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하므로 테스트 코드를 짜기도 읽기도 쉬워진다. 이렇게 구현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 된다. 즉, 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어다.
• 이중 표준 : 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다.
• 테스트당 assert 하나 : 이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다. 여러 개념을 한 함수로 몰아넣으면 독자가 각 절이 거기에 존재하는 이유와 각 절이 테스트하는 개념을 모두 이해해야 한다. 가장 좋은 규칙은 "개념 당 assert 문 수를 최소로 줄여라"와 "테스트 함수 하나는 개념 하나만 테스트하라"라 하겠다.
• 깨끗한 테스트의 다섯 자기 규칙 F.I.R.S.T
  • FAST(빠르게) : 테스트는 빨리 돌아야 한다.
  • Independent(독립적으로) : 각 테스트는 서로 의존하면 안 된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안된다.
  • Repeatable(반복가능하게) : 테스트는 어떤 환경에서도 반복 가능해야 한다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
  • Self-Validating(자가검증하는) : 테스트는 부울(bool) 값으로 결과를 내야 한다. 성공 아니면 실패다. 테스트가 스스로 성공과 실패를 가늠하지 않는 다면 판단은 주관적이 되며 지루한 수작업 평가가 필요하게 된다.
  • Timely(적시에) : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
• 테스트 API를 구현해 도메인 특화 언어(Domain Specific Language, DSL)를 만들자. 그러면 그만큼 테스트 코드를 짜기가 쉬워진다.
• 테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자.

😀 오늘 읽은 소감 및 떠오르는 생각

• 단위 테스트 코드를 제대로 작성해서 테스트를 해본적이 없다. 그저 산출물로 작성해둔 단위 테스트 케이스 문서만 보고 화면에서 눌러본 테스트가 전부다.
• 단위 테스트는 실제 코드를 구현하기 직전에 구현해야 한다는 것을 알았다. 몰랐다면 실제 코드를 전부 작성하고 단위 테스트 코드를 작성했을 것이다.
• TDD(테스트 주도 개발) 말만 많이 들어봤지 실제로 해본적이 없다. 현재 시작되고 있는 프로젝트에서는 꼭 TDD를 적용시켜봐야겠다.

🤔 궁금한 내용 및 잘 이해되지 않는 내용

• TDD를 해보지 않아서 TDD를 하게 되면 어떤 효과가 있을지가 가장 궁금하다. 꼭 실행에 옮겨봐야지!

🔎 오늘 읽은 다른 사람의 TIL

• devilzcough님의 TIL (https://nomadcoders.co/community/thread/3326)
• roghado님의 TIL (https://nomadcoders.co/community/thread/3325)