단위테스트를 시작해보자!

단위테스트를 작성한다. 처음에는 테스트할 코드가 없으니 당연히 통과하지 못한다.

하지만 단위 테스트를 먼저 만들고 , 실제 제품에 들어갈 코드를 작성하는 것이 규칙이다. 실패하는 단위테스트를 통과하기 위해 작성한 것이 실제 코드의 모든 줄이 된다.

이 테스트 먼저 (test - first ) 기법은 극히 반벅적인 기법이다. 먼저 다섯줄이나 열줄 을 넘지 않는 단위 테스트의 작은 조각을 작성한다 . 그리고 컴파일 해보지만 아직 작성하지도 않은 코드를 사용하기 때문에 분명 컴파일이 되지 않는다 . 그러면 단위테스트 코드의 컴파일이 성공할 만큼 실제 코드를 작성한다 .아마 여섯 줄 보다 적을 것이다. 

그런다음 다시 테스트를 돌려본다. 컴파일은 되어도 아직 실제 코드를 다 작성한 것이 아니기 때문에 또 테스트를 통과하지 못한다.

실패를 확인한다음 테스트의 한 조각만 통과할 만큼 실제 코드를 작성한다 . 그조각을 통과하면 테스트에 다른 조각을 추가하고 처음부터 다시 시작한다.

이렇게 한번 도는데 걸리는 시간은 어떤 언어와 환경을 사용하느냐에 따라 1분 에서 10분정도 걸린다. 빨리 돌수록 좋다. 한번 이과정을 돌때마다 여러분은 그 모듈을 위해 작성한 '테스트를 모두 돌리게 된다.' 즉 , 지금 어떤일이 일어나든 상관없이 , 여러분의 코드가 몇분전에 완벽하게 작동하던 코드라는 뜻이다. 우리는 기능을 추가하거나 수정하느라 조각조각 찢긴 모듈들을 몇십개씩 편집창에 띄우고 제발 마지막으로 작동하던때로 돌아가도록 어떻게든 이어붙일수 있기를 기도하는 짓은 하지 않는다. 우리 코드는 '겨우 몇 분전에 모든 테스트를 완벽하게 통과한 코드다'

작업을 진행할수록 우리는 날마다 자라는 단위테스트 본체에 자꾸 테스트들을 추가한다. 하루에 몇십개 ,한주에 몇백개 , 한달이면 몇천개가 쌓인다. 이런 테스트들을 실행하기 편리한 본체안에 조직해서 넣은 다음 이것들을 언제나 돌려본다. 우리는 언제나 우리 코드의 현재 상태에 자신이 있다.

테스트는 문서화의 다른 형식이기도 하다. 특정한 api 함수를 호출하는 방법을 알고 싶다면 , 그것을 하는 테스트가 있으니 보면 된다. 어떤 객체를 만드는 방법을 알고 싶다면 역시 그것을 하는 테스트가 있으니 보면 된다. 테스트는 시스템에 있는 거의 모든 프로그래밍 작업의 예제 모음처럼 사용할 수 있다. 테스트는 뜻이 모호하지 않고 정확하고 컴파일 할수도 있으며 실행할 수도 있는 종류의 문서다.

책) UML 실전에서는 이것만쓴다. (로버트 마틴 ) 중에서