클린 코드 - 9장 단위 테스트

10 Sep 2021

Java, CleanCode, books

Intro

초서-독서 한 내용을 그대로 적는 곳이기 때문에 책을 읽지 않은 분들이 보기에 맥락이 애매할 수 있습니다.

초서 : 책을 읽는데 그치는 것이 아닌 손을 이용해 책의 중요한 내용을 옮겨 적음으로써 능동적으로 책의 내용을 수용하고 판단하여 새로운 지식을 재창조하는 과정. 메타인지 학습법

Index

9장 단위 테스트

우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한(그리고 더욱 중요한) 사실을 놓쳐버렸다.

TDD 법칙 세 가지

첫째 법칙
실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
둘째 법칙
컴파일을 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
셋째 법칙
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

위 세 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나오게 된다. 또한 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나오게 된다. 하지만 이렇게 방대하게 쌓인 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

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

일회용 테스트 코드와 자동화된 단위 테스트 슈트, 둘 사이는 간극이 아주 크다.

지저분한 테스트 코드를 내놓으나 테스트를 안 하나 오십보 백보라는, 아니 오히려 더 못하다는 사실을 알아야 한다. 실제 코드가 진화하면 테스트 코드도 변해야 한다. 그런데 테스트 코드가 지저분할수록 변경하기 어려워진다. 그래서 테스트 코드는 계속해서 늘어나는 부담이 되버린다.

결국 테스트 케이스를 유지하고 보수하는 비용도 늘어나게 되고, 테스트 슈트를 폐기하지 않으면 안 되는 상황에 처한다. 하지만 테스트 코드 없이는 시스템 결함율이 높아지게 된다. 이 모든 실패를 초래한 원인은 테스트 코드를 막 짠 결과이다. 테스트 코드는 실제 코드 못지 않게 중요하다.

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

코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 실제 코드를 점검하는 자동화된 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다.

깨끗한 테스트 코드

깨끗한 테스트 코드를 만들기 위해 세 가지가 필요하다.

가독성, 가독성, 가독성

테스트 코드는 명료하고 단순하고 풍부한 표현으로(이 모두를 통틀어 가독성) 작성되어야 한다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.

테스트 코드의 가독성을 위해 다음을 살펴보자.

테스트와 무관한 (테스트 코드의 의도를 흐리는) 코드를 제거하자.
읽는 사람을 고려하자.
build-operate-check 패턴, given-when-then 관례를 이용하자.
테스트에 필요한 자료 유형과 함수만을 사용하자.
테스트 전처리 과정을 직관적인 내부 private 메서드로 묶어 명료하게 표현할 수 있다.
실제 코드만큼 효율적일 필요가 없다. (효율 보다는 코드의 깨끗함이 우선이다)

테스트 당 개념 하나

잡다한 개념을 연속으로 테스트하는 긴 함수는 피하는게 좋다.

F.I.R.S.T.

F (Fast) 빠르게
테스트는 빨리 돌아야 여러번 돌릴 수 있게되고, 초반에 문제를 찾아내 고칠 수 있다.
I (Independent) 독립적으로
각 테스트는 서로 의존하면 안 된다. 어떤 순서로 실행해도 괜찮아야 한다.
R (Repeatable) 반복가능하게
어떤 환경에서 실행해도 반복 가능해야 한다.
S (Self-validating) 자가검증하는
테스트 결과는 항상 부울 값을 내야 한다. (통과 여부를 알려고 로그 파일을 읽게 만들어서는 안 된다, 판단이 주관적이게 된다)
T (Timely) 적시에
코드 구현 직전에 테스트 코드를 구현한다. (순서 중요!)

Nzzi