4. Building Tests

장재휴

The Value of Self-testing Code

인생이 훨씬 순탄해진다!

테스트 코드를 작성하면 대부분의 시간을 창조적인 작업에 사용할 수 있다

테스트 코드를 작성하지 않으면 디버깅에 대부분의 시간을 쓰게된다

Functional Test 담당자나 사용자가 버그를 발견했을 때?

버그 리포트를 받으면 제일 먼저 그 버그를 표면화 시키는 단위 테스트부터 작성하자!

버그부터 수정하면 또 다른 버그를 만들어낼 수 있다!

의미있는 테스트를 작성하자!
(모든 public method를 테스트 하는 것은 좋지 않는 방법이다.)
테스트는 문제의 가능성이 높은 곳에 집중되어야 한다
(단순한 getter/setter는 테스트 하지 않는다. 너무 세밀한 테스트는 효과가 미미하다.)
잘못될까봐 걱정하는 부분들만 테스트 하는 것이 좋다
버그 가능성이 거의 없는 부분은 애초에 배제한다
(너무 많은 테스트를 작성하려다보면 초반에 질려서 충분한 테스트를 하지못한다.)

완벽을 기하다가 아예 테스트를 실행하지 않게 되느니
차라리 불완전한 테스트라도 작성해서 실행하는 편이 낫다

잘못될 수도 있는 경계 조건을 생각하고,
그 상황에서의 테스트에 집중하자

뭔가 잘못되게끔 되어 있을 때는
예외가 발생하는지 반드시 테스트 하자

테스트가 모든 버그를 잡아내진 않더라도
대부분의 버거는 잡아내므로 테스트 작성을 중단해선 안된다

'이 Class/Method의 정체는 뭘까?' 란 생각을 먼저 하게 된다
=> Interface(Responsibility)에 집중 => 제대로 된 OOP 실현
Input / Output에 집중
=> 동일한 Input일때 동일한 Output이 나오도록 구현하게 됨.
Test의 Fail을 무시하게 될때 Test는 하기 싫어 진다.
=> Test와 Code의 관계가 멀어지기 시작. Test를 하지 않게 됨
Test의 Fail을 무시하게 되는 시작은 Code의 오류가 아니다.
대부분 Test 실행 환경으로 인한 오류다. 그것을 바로 잡지 않는 순간 Test는 끝난다.
Test를 하지 않을 때 어떤 일이 벌어지나?
뻔하고 방대한 메쏘드들의 집합체 or 스파게티 코드
코딩의 리듬을 타야 한다!
Red / Green / Refactor

By bbugguj