본문 바로가기

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

클린코드 9장 "단위 테스트" 정리

TDD 법칙 세가지

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

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

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

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

테스트가 체계적으로 작성되어 있지 않으면 코드 변경이 두려워지고 유연성이 떨어질뿐 아니라 코드 변경은 잠정적인 에러발생을 유발하므로 체계적인 깨끗한 테스트코드 작성은 꼭 필요하다.

<테스트 코드를 만드는데 필요한것은 첫째도 가독성 둘째도 가독성 셋째도 가독성>

이를 위해 Build-Operate-Check 패턴이 테스트 구조에 적합하여 적용된다. 각 테스트는 명확히 세 부분으로 나눠진다. 첫부분은 테스트 자료를 만든다. 두번째 부분은 테스트 자료를 조작하며, 세번째 부분은 조작한 결과가 올바른지 확인한다.

잡다하고 세세한 코드는 모두 없애고 코드를 읽는 사람은 헷갈릴필요없이 코드가 수행하는 기능을 재빨리 이해한다.

<테스트 당 assert 최소화, 개념하나>

assert문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다. assert문이 2개여야 하는 테스트는 테스트를 2개로 쪼개면된다.

<F.I.R.S.T>

Fast 빠르게 : 테스트는 빨라야한다.

Independent 독립적으로 : 각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안된다. 각 테스트는 독립적으로 그리고 어떤 순서로 진행해도 괜찮아야 한다.

Prepeatable 반복가능하게 : 테스트는 어떤 환경에서도 반복 가능해야 한다.

Self-Validating 자가검증하는 : 테스트는 부울값으로 결과를 내야 한다. 성공 아니면 실패다. 통과여부를 알려고 로그파일을 읽게 만들어서는 안된다. 

Timely 적시에 : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제코드를 구현하기 직전에 구현한다. 실제코드를 먼저 구현하고 테스트코드를 작성하면 실제코드가 테스트하기 너무 어렵다고 판명나거나 테스트가 불가능하도록 설계할지도 모른다.

<정리>

테스트코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. 테스트코드는 유연성 유지보수성 재사용성을 보존하고 강화하기때문이다. 테스트 코드를 지속적으로 깨끗하게 관리하자.