테스트 속도 개선

이승한·2020년 1월 21일

Book - Effective Unit Testing

목록 보기

9/9

이 장의 내용
- 빌드가 느려지는 근본 원인 찾기
- 테스트 코드 속도 개선 기법
- 자동 빌드 속도 최적화 기법

좋은 단위 테스트는 수행 시간도 짧다.

속도 개선을 위해서

테스트 시간이 너무 길어지면 사고 흐름을 놓칠 때까지 멍하니 화면만 응시하고 있거나, 빌드를 걸어놓고 다른 작업을 시작해야 한다. 문제를 발견하고 대응하기 까지의 시간이 늦어질 것이다.
피드백이 늦어질 수록 피해가 더 커진다. 개발자는 검증 결과를 기다리게 된다. 집중력을 잃고 생산성도 떨어진다.
느린 테스트와 느린 빌드에 대한 접근 방식은 기본적으로 같다. 어떻게 실행되는지 분석하여 정확한 상황 데이터를 구하고 주요한 병목지점을 찾은 다음 알고 있는 수단을 총동원해서 해결한다.

빌드 프로파일링
테스트 프로파일링

테스트 코드 속도 높이기

피곤하지 않다면 잠들지 말라

테스트가 필요 이상으로 멈춰 있게 해서는 안된다. (잠자는 달팽이 냄새)
Thread.sleep 을 사용하지 말라.
대신 도익화 객체를 사용하면 훨씬 신뢰할 수 있는 결과를 얻을 수 있다.

덩치 큰 기반 클래스를 경계하라.

기반 클래는 편리하지만 숨겨짓 대가를 치러야만 한다.

구조적 성능 저하 요인

클래스 계층 구조가 깊어질수록 셋업과 티어다운 메서드가 누적되어 느려지게 한다.
계층이 복잡해 질 때 단점
- 리팩토링이 까다롭다. 상위 계층 중 하나라도 리팩토링 하게 되면 그 파장이 상당히 커진다.
- 말단 클래스 모두 상위 클래스에서 제공하는 유틸리티 전부를 필요로 하지 않는다.
상속보다는 컴포지션을 이용하라.
정적 임포트를 사용하라.
유틸리티 메서드나 셋업/티어다운을 위해서는 @Rule 기능을 활용하자.

불필요한 셋업과 티어다운을 경계하라

@Before 과 @After는 메서드당 한번씩 실행된다. @BeforeClass 로 바꾸자.
셋업과 티어다운 에서 시간을 얼마나 잡아 먹는지 그리고 이유없이 실행되고 있진 않은지 확인 해보자.

테스트에 초대할 손님은 까다롭게 선택하라.

테스트 시간을 단축 하려면 테스트가 수행하는 코드 양을 줄여라
협력 객체를 테스트 더블로 대체하자.
계산량이 많은 컴포넌트를 더블로 교체하면 테스트가 훨씬 빨리 끝난다.

로컬하게, 그리고 빠르게 유지하라.

네트워크 사용을 배제하자. 클라우드 서비스에서 데이터를 가져오려면 지역벼수를 읽는 것보다 10만배는 더 걸린다.
테스트 더블로 채체하면 테스트를 격리할 수 있고 불확실한 외부 요소가 사라져서 신뢰성이 높아진다.
네트워크 장애나 타임아웃 같은 특수 상황도 시뮬레이션 할 수 있다.
단위테스트에서는 네트워크를 호출하지 않는 것을 기본 원칙으로 한다.

데이터 베이스의 유혹을 뿌리쳐라

되도록 테스트 대상 코드와 가까운 협력객체를 가짜 객체로 교체하는 것이 좋다.
영속 객체를 통째로 스텁으로 교체할 수 있는 아키텍쳐가 좋다. (ORM)
데이터 베이스 접근은 시간이 오래 걸리고, 그곳에 저장할 데이터도 단위 테스트 검사 내용과는 대부분 무관하기 때문이다.

파일 I/O 보다 느린 I/O 는 없다.

테스트를 빠르게 유지하려면 파일 시스템 접근을 최소화 해야 한다.
테스트 코드의 파일 접근을 피하라 (쪼개진 논리를 해결하라)
- 어쩔수 없으면 캐싱해서 한번만 읽자
대상 코드의 파일 접근을 가로 채라
- 로깅을 줄이자. 로깅만 꺼도 수십 퍼센트는 빨라진다.

빌드 속도 높이기

빌드 성능을 제한하는 요소는 CPU 아니면 I/O 다.

CPU 병목?	I/O 병목?
더 빠른 CPU 사용	더빠른 디스크를 사용
더 많은 CPU 사용	더 많은 스레드를 사용
더 많은 컴퓨터를 사용	더 많은 디스크를 사용