(클린코드) Chapter09 - 단위 테스트

## 목차 ##

우선 TDD가 무엇인지 모른다면 아래 링크를 볼 것. TDD의 기초 개념에 대한 매우 친절하고 좋은 글이다.

단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
- 테스트해야할 목록들을 나열하고 작은것부터 시작한다.(일단 함수 이름만 지어놓고 블록 내부는 비워둔다.)
- 함수의 함수의 함수.. 인 구조에서 최종 호출되는 sub함수부터 시작하는 것이다.
- 해당 함수가 통과해야할 테스트 케이스를 코드로 작성한다.
- 테스트해야하니 함수의 블록을 채우는데, 대충 아무거나 return 하도록 넣는다.
- 통과해야 할 테스트 케이스가 실패했으니 통과시키기 위해 제대로 된 코드를 작성한다.
- 이렇게 모든 테스트 케이스가 통과될 때 까지 작성
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 그래도 컴파일은 되도록 해야한다…
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
- 한 번에 다 통과하기보다 간단한 케이스부터 차례차례 통과시킨다.
- 고민해가며 빠뜨린 케이스가 없는지 추가해가며 통과시킨다.

테스트코드는 실제코드만큼 중요하다.
- 실제 코드가 진화하면 테스트코드도 진화해야한다.
- 테스트코드가 지저분하면 변경도 어려워진다. 코드가 수정되면 테스트를 통과시키기 위해 양이 계속 늘어나고 손댈 수 없을 지경에 이른다.
- 테스트에 쏟은 시간이 허사가 되지않게 하려면 애초에 깨끗한 테스트 코지를 계속 유지해야한다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다.
- 테스트 케이스가 있으면 변경이 두렵지않다.
- 테스트 케이스의 커버리지가 높을수록 공포는 줄어든다.
- 테스트 케이스가 없다면 모든 변경은 잠정적인 버그다.

가독성, 가독성, 가독성
- 테스트 코드의 가독성은 실제 코드에서만큼 아니면 오히려 더 중요하다.
테스트 코드에서 가독성을 높이려면?
- 여느 코드와 마찬가지다. 명료성, 단순성, 풍부한 표현력을 통한 이해하기 쉬운 코드.
실제 코드만큼 효율적일 필요는 없다.
- 실제 환경에서 돌아갈 코드가 아닌 테스트 환경에서만 돌아가는 코드이기 때문이다.
- ex) 문자열 연산에 의한 자원사용이 미미하다면 StringBuffer대신 읽기좋은 String을 사용한다

테스트 하나당 assert문은 하나만 있어야한다는 학파 존재
- 괜찮은 생각일 수 있다. 그러나 배보다 배꼽이 큰 어거지성 형식맞춤이 발생하기도 한다.
'테스트 당 assert 하나' 보다는 '테스트 당 개념 하나'가 더 맞는 생각이다.(저자에 의하면)
- 도메인 영역에서 확인해야하는 하나의 규칙마다 하나의 테스트 케이스를 사용

깨끗한 테스트는 5가지 규칙을 따른다.
- Fast, Independent, Repeatable, Self-Validating, Timely
Fast
- 테스트는 빨라야한다.
- 느리면 자주 돌리기 힘들다.
- 자주 돌리지 않으면 초반에 문제를 잡아내기 힘들다.
Independent
- 테스트끼리는 독립적이어야한다.
- 서로간의 순서가 없어야한다.
Repeatable
- 테스트는 어떤 환경에서도 반복 가능해야한다.
- 실제 환경, QA 환경, 원격 등
Self-Validating
- 테스트는 부울(boolean) 값으로 결과를 내야한다.(성공 or 실패)
- 테스트 결과를 알기위해 로그파일 같은것을 뒤져볼 필요가 없어야한다.
Timely
- 테스트 코드는 적시에 작성해야한다.
- 테스트하려는 코드를 구현하기 직전에 해야한다.
- 그렇지 않으면 테스트가 힘들거나 불가능하도록 코드를 설계할지도 모른다.