Clean Code_9장. 단위 테스트
#노마드코더 #북클럽 #노개북
TIL (Today I Learned)
테스트 코드의 중요성과 테스트 코드를 깔끔하게 짜는 방법에 대해서 훑어봤다.
오늘 읽은 범위
9장. 단위 테스트
책에서 기억하고 싶은 내용
TDD 법칙 세 가지
- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다
깨끗한 테스트 코드 유지하기
지저분한 테스트 코드가 테스트를 안 하는 것보다 못하다.
실제 코드가 진화하면 테스트 코드도 변해야 한다. 그런데 테스트 코드가 지저분할수록 변경하기 어려워진다.
테스트 코드는 실제 코드 못지 않게 중요하다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다
코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.
→ 테스트 케이스가 있으면 변경이 두렵지 않으니까
테스트 케이스가 없으면 모든 변경이 잠정적인 버그다.
테스트 케이스가 있으면 변경이 쉬워진다.
테스트 코드가 지저분할수록 실제 코드도 지저분해지고, 결국 테스트 코드를 읽어버리고 실제 코드도 망가진다.
깨끗한 테스트 코드
깨끗한 테스트 코드를 만들려면 가독성이 필요하다.
테스트 코드에서 가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.
테스트 코드는 본론에 돌입해 진짜 필요한 자료 유형과 함수만 사용한다.
도메인에 특화된 테스트 언어(DSL)
테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어다.
이중 표준
테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다.
단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다.
테스트 환경은 자원이 제한적일 가능성이 낮다.
실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대게 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다.
테스트 당 assert 하나
JUnit으로 테스트 코드를 짤 때는 함수마다 assert문을 단 하나만 사용해야 한다고 주장하는 학파가 있다.
assert 문이 여러 개 들어가야 하는 테스트 코드에서는 테스트를 여러 개로 쪼개 각자 assert를 수행하면 된다.
given-when-then 관례를 사용하여 테스트 코드를 읽기 쉽게 한다.
하지만 테스트 코드를 분리하면 중복되는 코드가 많아진다.
➡️ TEMPLATE METHOD 패턴 사용하면 중복을 제거할 수 있다.
반드시 하나의 assert 문만 사용한다기 보다 assert 문 개수를 최대한 줄여야 좋다는 생각이다.
테스트 당 개념 하나
“테스트 함수마다 한 개념만 테스트하라”는 규칙이 더 낫겠다.
이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.
가장 좋은 규칙은 “개념 당 assert 문 수를 최소로 줄여라”와 “테스트 함수 하나는 개념 하나만 테스트하라”라 하겠다.
F.I.R.S.T
깨끗한 테스트는 다음 다섯 가지 규칙을 따른다. (첫 글자를 따오면 FIRST가 된다)
Fast
테스트는 빨라야 한다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다.
Independent
각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안 된다.
각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
Repeatable
테스트는 어떤 환경에서도 반복 가능해야 한다.
실제 환경, QA 환경, 네트워크에 연결되지 않은 노트북 환경 등
테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
Self-Validating
테스트는 bool 값으로 결과를 내야 한다. 성공 아니면 실패다.
테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되며 지루한 수작업 평가가 필요하게 된다.
Timely
테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
오늘 읽은 소감
저자가 이 파트의 결론에서 한 말이 있다.
사실상 깨끗한 테스트 코드라는 주제는 책 한 권을 할애해도 모자랄 주제다.
나는 아직 TDD 방식으로 코드를 작성한 경험이 없다. 그렇기에 이번 파트는 완전히 이해하기 어려웠다.
하지만 테스트 코드의 중요성은 꾸준히 들어왔기에 추후에 반드시 학습을 하고 적용할 예정이다.
궁금한 내용, 잘 이해되지 않는 내용
안드로이드를 개발할 때 코틀린을 사용하기 때문에 코틀린에서의 테스트 코드 작성하는 방법을 공부하고자 한다.
Given-When-Then 패턴
출처: marginFlowler
Given
테스트에서 구체화하고자 하는 행동을 시작하기 전 테스트 상태를 설명하는 부분
When
구체화하고자 하는 그 행동
Then
어떤 특정한 행동 때문에 발생할거라고 예상되는 변화에 대해 설명하는 부분
Template Method 패턴
출처: Blog
어떤 작업을 처리하는 일부분을 서브 클래스로 캡슈로하해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴
코드 중복을 최소화 할 수 있다
DSL (Domain-Specific Languages)
출처: Jetbrain
관련 특정 분야에 최적화된 프로그래밍 언어. 해당 분야 또는 도메인의 개념과 규칙을 사용한다.
DSL은 일반적으로 Java, C, Ruby 등 범용 언어보다 덜 복잡하며 소프트웨어 개발의 특정 부분에서 훨씬 더 효율적으로 작업할 수 있다.
대표적으로 gradle, SQL과 같은 언어가 있다.