10. 테스트를 자동화하라
가이드라인
목표 : 테스트를 자동화하라
실천 : 테스트 프레임워크로 자동화한 테스트를 작성한다
효과 : 결과를 예측할 수 있는, 리스크가 적은 개발을 할 수 있어서 유지보수 향상
코드를 깔끔하게 유지하고 싶으면 녹색 막대를 켜두세요
-제이유닛 모토
테스트를 자동화하여 기능의 이상유무 판단.
수동 테스트나 1회성 (main)테스트는 지양
테스트 프레임워크 Junit을 활용
1. 필요성
테스트를 자동화하면 반복 테스트가 가능하다
매번 정확히, 똑같이 반복 실행이 가능
변경시에도 오류가 발생한 부분에 대해 빠르게 대처할 수 있음
테스트를 자동화하면 효율적으로 개발할 수 있다
자동화한 테스트는 수동테스트에 비해 훨씬 쉽게 실행 가능 (Maven, Gradle 등 활용)
작성된 테스트케이스 코드는 언제든지 반복으로 한번에 실행 가능
가능한 한 개발 초기 단계부터 테스트를 병행함으로써 오류를 바로잡는 수고를 아껴야 함
테스트를 자동화하면 예측 가능한 코드를 만든다
코드를 고쳤을 때, 버그의 발견을 바로 알 수 있음
코드의 실행을 확신할 수 있고, 개발이 끝난 코드 품질 역시 미래 헤아릴 수 있음
테스트할 코드를 문서화한다
단언 (assertion)은 테스트할 시스템의 올바른 작동 방식을 기술함
단언 관련 메서드코드 자체로 문서화가 됨
테스트는 시스템이 어떤 일을 해야 하는지 보여주는 하나의 실례인 셈
테스트를 작성하면 더 나은 코드를 짤 수 있다
여러가지 기능을 가진 메서드는 테스트하기가 어려운데, 테스트를 쉽게 하려면 이메서드가 하는 일을 다른 메서드로 옮겨 전체적인 유지보수성을 개선해야 함
그래서 TDD방법론에서는 테스트에 부합하는 코드를 작성하기 전, 단위테스트를 먼저 작성하라고 이야기함!! 파라미터, 리턴 값 등을 생각하면 메서드 디자인이 한결 수월 해짐
2. 적용가이드
테스트를 어떻게 자동화 할지는 테스트 유형에 따라 결정됨
유형 | 테스트 대 | 목 | 주체 |
단위테스트 | 따로 분리한 하나의 단위 기능 | 단위 코드가 의도한대로 작동 확인 | 개발자 |
통합테스트 | 적어두 클래스 2개 이상의 기능, 성능, 기타품질 특성 | 시스템을 이루는 요소들이 함께 잘 작동하는지 확인 | 개발자 |
종단테스트 | 시스템 연동(사용자 또는 다른 시스템과의 연동) | 시스템이 의도한 대로 작동하는 지 확인 | 개발자 |
회귀테스트 | 이전에 에러가 났던 단위, 클래스, 시스템 연동 부분의 로직 | 버그가 다시 나타나지 않는지 확인 | 개발자 |
인수 테스트 | 시스템 연동(사용자 또는 다른 시스템과의 연동) | 시스템이 의도한대로 작동하는지 최종 승인 | 고객 인수팀 |
자동화 프레임워크도 유형별로 제각각
단위테스트 : Junit
종단테스트 : 셀레늄
통합테스트 : SoapUI, 아파치 Jmeter 등 목적에 따라 다른 솔루션 적용
통합/종단 테스트는 전문 분야이지만, 단위테스트는 모든 개발자 필수 기술이다
단위 테스트를 올바르게 하기 위한 일반 원칙
정상 케이스, 특이 케이스 모두 테스트한다
정상케이스와 비정상 케이스각각 테스트 작성하여 확인. 실제로 특정예외를 던지는지도 확인
테스트를 비테스트 코드(일반적으로 소스 코드 같은)처럼 관리한다.
테스트는 분리하여 작성한다.
테스트 결과에는 테스트할 대상의 로직만이 반영되어 있어야 한다.
하나의 단위테스트는 오직 한 가지 기능만 테스트하고 다른테스트가 덮어 쓴 파일처럼 어떤 상태에 따라 변하는 값에 의존하면 안된다
스터빙, 모킹 같은 기법을 동원하여 해결해야할 부분은 해결
테스트가 충분한지 여부를 판단하기 위한 커버리지 측정
몇개나 만들어야할까? 충분여부는 단위테스트 커버리지라는 지표로 판단
적어도 80% 이상을 목표로 충분한 단위테스트를 작성하는 것이 좋다
80%인 이유는 불필요한 메서드도 포함되어 있기때문
ex) getter, setter 같은 메서드
즉.. 테스트코드 분량이 제품코드에 달할 정도로 충분이 작성되어야 한다
제품코드와 테스트코드 비율을 1:1로 맞출 것을 권장
메이븐 플러그인 -> Cobertura
이클립스 플러그인 -> EclEmma
OSS -> Joda
Last updated