4장 테스트 구축하기
테스트 작성으로 리팩터링 효율을 높일 수 있다
About
리팩터링을 제대로 하려면 불가피하게 실수를 저지르는 실수를 잡아주는 견고한 테스트 스위트(test suite)가 뒷받침돼야 한다.
테스트 작성을 하면 시간을 빼앗기지만 효율이 높아지는 이유를 살펴보자.
자가 테스트 코드의 가치
실제로 코드를 작성하는 시간의 비중은 그리 크지 않음을 알 수 있다. 대부분의 시간은 디버깅에 쓴다.
버그를 잡는 과정에 다른 버그를 심기도 하고, 그 사실을 한참 뒤에 알아내기도 한다.
모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자.
이렇게 하니 테스트가 컴파일만큼 쉬워졌다.
컴파일할 때마다 테스트도 함께 했고, 곧바로 생산성도 급상승했다. 디버깅 시간이 크게 줄어든 것이다.
테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다.
저자처럼 기능을 추가할 때 테스트를 먼저 작성하는 것도 좋다. (Test-Driven Development by 켄트 벡)
구현보다 인터페이스에 집중하게 된다. (무조건 좋은 일이다.)
코딩이 완료되는 시점(테스트를 모두 통과한 시점)을 정확하게 판단할 수 있다.
리팩토링에는 테스트가 필요하고, 반드시 작성해야 한다.
테스트 팁
실패해야 할 상황에서는 반드시 실패하게 만들자.
테스트가 실패하는 모습을 한 번씩은 확인해보자.
저자가 자주 쓰는 방식처럼 일시적으로 코드에 오류를 주입해봐도 좋다.
자주 테스트하라. 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고, 적어도 하루에 한 번은 전체 테스트를 돌려보자.
실패한 테스트가 하나라도 있으면 리팩터링하면 안 된다.
완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성하는 게 낫다.
문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트해보자.
스스로 코드를 망가뜨리는 방법을 모색해보자.
어차피 모든 버그를 잡을 수 없다고 생각해 테스트를 작성하지 않는다면 대다수 버그를 잡을 수 있는 기회를 날리는 셈이다.
그러면 어느 수준까지 해야 할까?
명확한 기준은 없다.
너무 빠져들 필요는 없다. 테스트에도 수확 체감 법칙(law of diminishing returns)이 존재한다.
테스트 커버리지는 숫자일 뿐이다.
테스트 때문에 개발 속도가 느려진다고 생각되면 테스트를 과하게 적은 건 아닌지 의심해보자.
하지만 대부분 너무 많은 경우보단 너무 적은 경우가 훨씬 많다.
버그 고치기
버그 리포트를 받으면 가장 먼저 그 버그를 드러내는 단위 테스트부터 작성하자.
Last updated