11. 테스트와 가독성

■ 읽거나 유지보수하기 쉽게 테스트를 만들어라

    테스트 코드가 읽기 쉬우면, 사용자는 실제 코드가 어떻게 동작하는지 그만큼 더 이해하기 쉽다.

다른 프로그래머가 수정하거나 새로운 테스트를 더하는 걸 쉽게 느낄 수 있게 테스트 코드는 읽기 쉬어야 한다.

- 코드를 수정하는 일이 두려워진다. 아니 우리는 이 코드에 손대고 싶지 않아. 테스트 케이스를 모두 변경하는 일은 너무나 끔찍하다

- 새로운 코드를 작성하면 그에 따르는 새로운 테스트를 자겅하지 않는다. 시간이 흐름이 지나면서 더 낮은 비율의 코드가 테스트되며, 

  따라서 코드에 대한 확신이 줄어들 수 밖에 없다.

자신의 코드를 사용하는 사람이 테스트코드를 편하게 느끼도록 만들어야 한다. 코드를 사용자는 새로운 코드가 왜 현재 테스트에서

실패하는지 쉽게 진단할 수 있어야하고, 새로운 테스트도 쉽게 덧붙일 수 있어야 한다.

■ 코드를 더 읽기 쉽게 만들기

    덜 중요한 세부 사항은 사용자가 볼 필요 없게 숨겨서 더 중요한 내용이 눈에 잘 띄게 해야 한다.

■ 읽기 편한 메시지 만들기

■ 좋은 테스트 입력값의 선택

    - 가능하면 가장 간단한 입력으로 코드를 완전히 검사할 수 있어야 한다.

    - 필요한 작업을 수행하는 범위에서 가장 명확하고 가단한 테스트 값을 선택하라.

1. 테스트가 너무 길고 중요하지 않은 제사한 내용으로 가득 찼다.

    테스트가 하는 일을 한 문장으로 표현할 수 있으므로 실제 테스트 구문이 지나치게 길 필요는 없다.

2. 새로운 테스트를 추가히가 쉽지 않다. 복사/붙이기/수정 방법을 쓰고 싶은 유혹을 느끼겟지만 그렇게 하면 코드를 더 길고 중복되게 한다.

3. 테스트 실패 메시기자 별로 도움이 되지 않는다. 디버깅에 유용하게 작성될 필요가 있다.

4. 모든 것을 한꺼번에 테스트 하려고 애쓰지마라

5. 테스트 입력은 최대한 간단하게

6.  테스트 입력값들이 코드를 꼼꼼하게 실행시키게 해야한다. 너무 잦은 필터링은 곤란하다.

7. 비어 있는 입력 벡터, 매우 큰 벡터 혹은 중복된 점수와 같이 빙저상적인 값을 가지는 입력도 테스트 해야하다.

8. 함수이름에도 신경을 써야한다.

■ 테스트에 친숙한 개발

어떤 코드는 다른 코드보다 테스트하기 더 쉽다. 테스트 하기 좋은 코드는 잘 정의된 인터페이스를가지고, 지나치게 많은 상태가 설정을 요구하지 않으며, 감추어진 데이터를 포함하지 않는다.

​테스트 주도 개발(Test-Driven Development TDD) 

​실제 코드를 작성하기 전에 우선 테스트 코드부터 작성하는 프로그래밍 스타일

실제 코드를 작성한 다음에 비로소 테스트 코드를 작성하는 방법보다 실제 코드의 질을 상당한 수준으로 샹상 시킨다고 주장한다.

■ 지나친 테스트

- 테스트를 가능하게 하려고 실제 코드의 가독성을 희생시킨다.

- 100% 코드 테스트에 집착하는 것

- 사실 코드를 100%테스트하는 일은 일어나지 않는다. 테스트 되지 않은 버그가 있을 수도 있고, 테스트되지 않은 기능이 있을 수도 있으며, 요구 사항이 달라졌다는 사실을 모르고 있을 수도 있기 때문이다.

- 버그가 야기하는 비용이 어느 정도 인지에 따라서, 테스트 코드를 작성하는 시간이 의미를 갖는 부분이 있고, 그렇지 않은 부분도 있기 마련이다.

- 테스트 코드로 실제 제품 개발이 차질을 빚게 되는 일,