[Clean Code] 9장 단위 테스트

 

클린코드,  애자일 소프트웨어 장인정신

Robert C. Martin

 

 

 

TDD 법칙 세 가지

첫째 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

둘째 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

셋째 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

 

 

깨끗한 테스트 코드 유지하기

테스트 코드가 복잡할 수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 쉽다.

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

테스트 코드는 사고와 설계와 주의가 필요하다.

실제 코드 못지 않게 깨끗하게 짜야한다.

 

테스트는 유연성, 유지보수성, 재사용성을 제공한다.

버팀목 = 단위 테스트

테스트 커버리지가 높을수록 공포는 줄어든다.

 

 

깨끗한 테스트 코드

가독성 가독성 가독성

→ 명료성, 단순성, 풍부한 표현력 필요

 

1. 테스트 자료 만든다.

2. 테스트 자료 조작

3. 조작한 결과가 올바른지 확인

 

도메인에 특화된 테스트 언어

도메인에 특화된 언어로 테스트 코드를 구현하는 기법을 보여준다.

흔히 쓰는 시스템 조작 API를 사용하는 대신 API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하므로 테스트 코드를 짜기도 읽기도 쉬워진다. → 테스트 언어

 

숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩터링해야 마땅하다.

 

 

이중 표준

테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다.

단순/간결/표현력 풍부함 🙆‍♀️

실제 코드만큼 효율적 🙅‍♀️

 

코드의 깨끗함과는 철저히 무관하다.

 

테스트당 assert 하나

assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.

그러나 테스트를 분리하면 중복되는 코드가 많아진다.

 

template method 패턴을 사용하거나 완전히 독자적인 테스트 클래스를 만들어

@Before함수에 given/when, @Test 부분에 then 부분을 넣어도 된다.

 

때로는 주저없이 함수 하나에 여러 assert 문을 넣기도 한다.

단지 assert 문 개수는 최대한 줄여야 좋다는 생각이다.

 

테스트 당 개념 하나

여러 개념을 한 함수로  몰아 넣으면 독자가 각 절이 거기에 존재하는 이유와 각 절이 테스트하는 개념을 모두 이해해야 한다.

 

가장 좋은 규칙

개념 당 asser 문 수를 최소로 줄이자.

테스트 함수 하나는 개념 하나만 테스트하라

 

F.I.R.S.T

깨끗한 테스트는 다음 다섯 가지 규칙을 따르는데, 각 규칙에서 첫 글자를 따오면 FIRST가 된다.

 

Fast 빠르게

테스트는 빨라야한다.

 

Independent 독립적으로

각 테스트는 서로 의존하면 안된다.

어떤 순서로 실행해도 괜찮아야 한다.

서로에게 의존하면 하나가 실패할 때 나머지도 잇달아 실패하므로 원인을 진단하기 어려워지며 후반 테스트가 찾아내야 할 결함이 숨겨진다.

 

Repeatable 반복 가능하게

어떤 환경에서도 반복 가능해야 한다.

실제 환경, QA 환경, 네트워크에 연결되지 않는 환경에서도 실행할 수 있어야 한다

 

Self-Validating 자가검증하는

테스트는 bool값으로 결과를 내야 한다.

성공 아니면 실패다.

로그 파일을 읽게 만들어서는 안된다.

테스트 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되며 지루한 수작업 평가가 필요하게 된다.

 

Timely 적시에

단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다.

 

 

 

결론

테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다.

테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다.

테스트 코드는 지속적으로 깨끗하게 관리하자.

표현력을 높이고 간결하게 정리하자.

테스트 API를 구현해 도메인 특화 언어 Domain Specific Language를 만들자.

그러면 그만큼 테스트 코드를 짜기가 쉬워진다.

테스트 코드가 방치되어 망가지면 실제 코드도 망가진다.

테스트 코드를 깨끗하게 유지하자.