테스트 작성

.

대학교에서는 테스트에 대해 많은 걸 다루지 않는다.

소프트웨어공학 시간에 단위테스트, 통합, 시스템, 화이트박스, 블랙박스 등 간단하게 넘어갔던 걸로 기억한다. (아닌가?)

아무튼 학부시절에 실제 로직을 작성하는 시간은 극히 짧았고, 문서작성 등의  코딩 외의 일과, 디버깅에 가장 많은 시간을 할애했었다.

책에서의 예처럼 테스트를 작성했다면 몇분 이내에 찾고 해결할 문제들을 몇 시간, 몇 일을 고생한 경험이 한 두번이 아니었다.

거기다 Junit과 같은 프레임워크의 도움을 받아 자동화된 테스트를 작성했다면 고통을 더 줄일 수 있었을텐데..

(그러나 이러한 경험으로 테스트의 중요성을 더 느낄 수 있지 않나 싶기도 하다)

.

.

리팩토링을 하기 위해서는 테스트가 미리 작성되어 있어야한다. 

테스트라는 안전 장치 없이 집을 뜯어 고치는 것은 정말 위험하기 때문이다.

테스트 코드를 작성하기 위해서는 또다른 고통을 감내해야 한다. 그렇지만 그로인한 이익이 크니 참도록 하자.

.

.

- 테스트는 위험을 위주로 작성해야 한다.

- T.C 작성은 지루한 작업이므로 버그 가능성이 거의 없는 부분은 애시당초 테스트 대상에서 제외시키자. (고통을 줄이자)

- 뭔가 에러가 있으리라 예상될 땐 그 예외가 정말로 발생하는 지 꼭 테스트하자.

.

.

.