[소프트웨어 테스트] 10. 테스트 코드 품질

소프트웨어 테스트 시리즈의 글입니다.

테스트코드 모범사례와 테스트 스멜에 대해 알아보자

10.1 테스트 코드의 유지 보수성을 위한 원칙

10.1.1 테스트는 빨라야함

테스트 = 개발자의 안전망. 기대한대로 동작하는지 피드백을줌. 피드백은? 빠를수록 좋다. 우수한 테스트는 빠르다. 테스트가 느리다면?

모의객체, 스텁으로 느린 구성요소 대체
제품코드 재설계 (느린코드, 빠른코드 분리)
느린 테스트를 자주 실행하지 않느 다른 테스트 스위트로 옮기기

10.1.2 테스트는 응집력 있고 독립적이며 격리되어야함

하나의 테스트가 하나의 기능을 테스트하는것이 이상적. 살찐 테스트(fat test)의 경우 구현관점에서도 복잡하고, 나중에 유지보수하기도 힘들어짐 작은 테스트 여러개로 나누자. 단순하고 짧은 테스트가 더 낫다. 테스트는 다른 테스트 결과에 의존하면 안됨 격리해서 실행하든, 함께 실행하든 결과는 같아야함.

10.1.3 테스트는 존재 이유가 있어야함

쓸모없는 테스트는 아예 만들지 말자

10.1.4 테스트는 반복가능해야함

반복가능한 테스트를 작성해야하고, 실행 횟수에 상관 없이 결과가 동일해야함 불안정한 테스트는 생산성을 헤침. 신뢰도 잃음. 신뢰를 잃으면 테스트가 실패해도 배포하게됨. 불안정해지는 이유

외부자원, 공유자원에 의존하는경우
부정확한 타임아웃
다른 테스트 메서드와 예상치 못한 상호작용이 일어난 경우. ⇒ 불안정한 테스트를 감지하는 자동화 도구 (ex. DeFlaker)를 이용하거나, 불안정한 테스트 의사결정표 등을 이용해 최대한 제거하자

10.1.5 테스트 단언문은 탄탄해야함

테스트는 수행한 코드가 예상대로 동작했다고 단언하기 위해 존재 단언문을 잘 작성해야 좋은 테스트를 만들 수 있음 가능한 탄탄해야함

10.1.6 테스트는 행위가 변경될 경우 깨져야함

테스트를 통해 예상된 행위가 깨졌음을 알 수 잇어야함 일부러 버그를 내서 깨지는것을 보는것도 추천임

10.1.7 테스트는 단 하나의 명확한 이유로 실패해야함

실패하는 테스트는 좋음 버그를 알려주기때문에. 테스트에 의도와 행위를 표현하고 입력값의 가독성을 높히고 자연어로 된 변수명을 사용하여 버그 원인도 바로 파악할 수 있게 하면 좋다.

10.1.8 테스트는 작성하기 쉬워야함

테스트 대상 클래스가 너무 많은 설정을 요구한다거나 다른 클래스에 너무 의존하면 테스트 작성이 어려워짐 이런경우 인프라를 설정하고 정리하는 테스트가 필요. (ex. 테스트 부모 클래스, PO ..)

10.1.9 테스트는 읽기 쉬워야함

테스트데이터 빌더 사용
정보의미 설명 변수명 사용
단언문 명확히 작성
코드에 충분히 표현되지 않는 상황에 대한 주석 추가

10.1.10 테스트는 쉽게 수정하고 진화할 수 있어야함

중복된 메서드는 추출하여 변경점을 줄이는 방법 추천

10.2 테스트 냄새

코드냄새

길이가 긴 메서드
길이가 긴 클래스
전지전능 클래스 동일하게 테스트 냄새도 있다.. 이녀석들은 테스트 스위트의 유지보수성과 이해도를 해친다

10.2.1 과다한 중복

테스트는 종종 구조가 유사함 생산성을 떨어뜨릴수 있으니 자주 리팩터링을 추천

10.2.2 불명확한 단언문

단언문 = 테스트 실패시 개발자가 가장 먼저 살펴보는 내용 좋은 단언문은 실패의 이유를 분명히하고 읽기쉽고 구체적임 좋은 단언문을 작성하자

10.2.3 복잡하거나 외부에 있는 자원에 대한 잘못된 처리

자원 낙관주의가 테스트 스멜을 유도함 자원이 이미 올바른상태에 있다고 가정하면 안됨. 또한 외부 의존성에 대해 테스트 내에서 명확히 해야함

10.2.4 너무 범용적인 fixture

fixture: 대상 구성요소를 수행할때 사용되는 입력값의 집합 복잡한 구성요소를 테스트한다면 fixture는 복잡해 질 수 있음. 대형 fixture는 유지보수도 힘듬. 빌더패턴등으로 범용 fixture작성을 피하도록 하자

10.2.5 민감한 단언문

좋은 단언문은 테스트케이스의 핵심 너무 민감한 단언문은 테스트가 실패하지말아야할때 실패할수있음 단언문을 탄력적으로 작성해야함