9장. 단위 테스트

TDD가 보편화 되고있지만, 그 본질에 대하여

하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는

좀 더 미묘한 (그리고 더욱 중요한) 사실을 놓쳐버렸다. 그런면도 없지않아 있는듯..

TDD법칙 세가지

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

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

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

필요한 코드만 작성하는 것이 핵심!

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

테스트 코드를 깨끗하게 유지해야 한다.

깨끗하지 않으면 테스트 코드는 점점 부담이 될 것이므로, 실제 코드를 만드는 시간보다 테스트 코드를 만드는 시간이 더 들게된다.

이게 생각보다 쉽지않은것같다. 수시로, 꾸준히 관심을 가지고 관리해줘야 지켜질 수 있다.

테스트 코드를 막 짜면 안된다!

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

단순하고, 간결하고, 표현력이 풍부해야 하지만 효율적일 필요는 없다.

보통 테스트 환경에서는 자원의 제약이 크게 작용하지 않기 때문에

테스트 함수마다 한 개념만 테스트 하는 것이 좋다.

동일한 연산을 요구하더라도, 입력과 출력의 의도가 다르다면 따로 하는게 좋다. 1 개념당 1 테스트!

F.I.R.S.T

깨끗한 테스트를 만들기위한 다섯가지 규칙

Fast(빠르게)

테스트는 빨리 돌아야한다. 그래야 자주 돌려볼 수 있고 돌릴때 부담이 없다.

Independent(독립적으로)

1번 테스트가 2번 테스트 결과에 영향을 주면 안된다.

Repeatable(반복가능하게)

테스트 결과가 동일하다는 것이 보장 되어야 한다. 언제 어디서 돌리든.

특히 외부자원을 사용하는 테스트인 경우 문제가 될만하다. 로컬에서 실행되게 만들어두는 것이 좋다.

Self-Validating(자가검증하는)

log로 찍어서 확인하는 테스트는 지양하는게 좋다. 

처음에는 확인차 log로 찍어보기도 하는데 null check라도 넣어두는게 좋은 것같다.

Timely(적시에)

실제코드를 구현하기 직전에 테스트를 만든다.

이게 가장 실천하기 어려운 부분이 아닐까? 

테스트를 먼저 만들면 확실히 좋은 것은 요구사항이 어느정도 명확해지기 때문이다.

실제코드를 작성하고 테스트를 하면, 구현한 로직에 맞춰 테스트를 만들게 되는듯하다.