[Clean Code] 9장, 단위 테스트

Clean Code

9장, 단위 테스트(TDD: Test Driven Development)

 

- 코드가 제대로 도는지 확인하여, 지속가능하게 사용 가능한 테스트 코드를 작성하는 것이 중요

> 테스트 케이스를 모두 구현하고 통과한 후, 다른 사람들에게 공개해야 함

 

- 애자일과 TDD로 단위 테스트를 자동화하고 제대로 된 테스트 케이스를 작성해야 함

 

 

 

1. TDD 법칙 세가지

 

1) 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않음

 

2) 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트 작성

 

3) 현재 실패하는 테스트를 통과할 정도로만 실제 코드 작성

 

- 개발과 테스트가 대략 30초 주기로 묶임

 

- 그러나 많은 테스트 코드는 심각한 관리 문제를 유발함

 

 

 

2. 깨끗한 테스트 코드 유지

 

- '지저분해도 빨리'는 이후에 테스트케이스를 유지하고 보수하는 비용도 늘어나게 됨

> 지저분한 테스트 코드는 테스트를 안하는 것보다 더 못함

 

- 테스트 슈트가 없으면 자신이 수정한 코드가 제대로 도는지 확인 할 방법이 없음

💡 테스트는 반드시 필요하므로, 처음부터 깨끗하게 해야 함

 

 

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

 

- 테스트 케이스가 있으면 변경에 두려움이 없음

➡️ 변경은 잠정적인 버그를 이끌지만, 테스트 커버리자가 높을수록 변경에 대해 우려 없이 변경할 수 있음

 

 

 

3. 깨끗한 테스트 코드

 

💡 가독성이 가장 중요함

> 명료성, 단숭성, 풍부한 표현형

 

- 중복을 제거할 것

 

- 테스트의 세 부분

1) 테스트 자료 생성

2) 테스트 자료 조작

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

 

 

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

 

- API 위에대 함수와 유틸리티를 구현한 후, 그 함수와 유틸리티를 사용

➡️ 테스트 코드에서 사용하는 특수 API가 됨

 

- 자신의 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩터링을 지속적으로 해야 함

 

 

이중 표준

 

- 테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 다름

 

- 실제 코드만큼 효율적일 필요는 없음

 

- 실제 환경에서는 절대로 안되지만 테스트 환경에서는 문제가 없는 방식이 있음(보통 메모리나 CPU 효율 문제)

 

 

 

4. 테스트 당 assert 하나

 

- 테스트를 두 개로 쪼개 각자 assert를 수행 -> 테스트 코드를 읽기 쉬워짐

 

- Template Method 패턴을 사용하여 중복을 제거

> given/when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 둠

> 또는 완전히 독자적인 테스트 클래스를 만들어 @Before 함수에 given/when을, @Test에 then을 넣어서 작성

> 그러나 assert문을 여러개 사용하는 것이 더욱 좋음

 

- 필요에 따라 assert문을 여러개 사용, 그러나 최대한 줄이는 게 좋음'

 

 

테스트 당 개념 하나

 

- 테스트 함수마다 한 개념만 테스트

> 잡다한 개념을 연속적으로 테스트하는 긴 함수를 피함

 

- 개념 당 assert 문 수를 최소로 줄이는 것이 좋음

 

 

 

5. F.I.R.S.T

- 깨끗한 테스트의 다섯가지 규칙

 

1) Fast 빠르게: 테스트는 빨리 돌아야 함, 자주 돌리지 못하면 문제를 착기 어려움

 

2) Independent 독립적으로: 각 테스트는 서로 의존적이면 안됨, 의존적일 때, 실패 원인을 찾기 어려움

ex. 한 테스트가 다음 테스트의 실행 환경을 준비❌

 

3) Repeatable 반복가능하게: 어떤 환경에서도 반복 가능해야 함

 

4) Self-Vaildating 자가검증하는: 테스트는 Bool 값으로 결과를 내야 함, 성공 or 실패

- 통과 여부를 알기 위해 로그 파일을 읽거나 비교하면 안됨

 

5) Timely 적시에: 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현

- 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드를 테스트하기 어려울 수 있음

 

 

결론

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

 

- 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화함

 

- 테스트 API를 구현하여 도메인 특화 언어 DSL을 만들어야 함