정글에서 온 개발자
12/28 TIL 좋은 단위 테스트의 4대 요소 본문
4대 요소
- 회귀방지
- 리팩터링 내성
- 빠른 피드백
- 유지보수성
핵심 요약
프로젝트가 커질수록 거짓 양성(실제 실패하지 않았는데 실패했다고 알리는 테스트)을 줄이는 것이 중요하다. 이것과 관련된 것은 리팩터링 내성이다.
리팩터링 내성이 없으면 테스트가 양치기 소년이 된다.
회귀방지, 리팩터링 내성, 빠른피드백은 서로 상충하는 가치들이다. (이상적인 테스트란 없다.)
그리고 이 네가지 특성으 곱셈으로 테스트의 가치가 결정된다. - 어느 하나를 0으로 만들면 안된다.
이 중에서 리팩터링 내성은 양보할 수 없다. 리팩터링 내성은 항상 최고 수준으로 맞춘다고 생각하고 회귀방지와 빠른 피드백 중에 저울질을 해야한다.


리팩터링을 포기할 수 있는 이유는 나머지 두 요소에 비해, 리팩터링 내성은 이진 선택이기 때문이다.
포기하면 0이 되어 테스트의 가치 계산을 위한 곱셈이 0이 된다.
회귀방지
가능한 많은 코드를 실행하도록 한다.
코드의 복잡도와 도메인 유의성도 중요하다.
리팩터링은
동작을 수정하지 않고 기존 코드를 변경하는 것
비 기능적 특징을 개선하는 것. 가독성을 높히고 복잡도를 낮춘다.
이 과정에서 테스트가 깨지지 않도록 하는 것이 리팩터링 내성이다.
거짓 양성이 발생하는 이유
결과가 아닌 중간 과정을 테스트하려고 하기 때문이다.
블랙박스처럼 작성하고, 화이트박스처럼 분석하라
테스트 피라미드
단위 테스트 - 통합 테스트 - 엔드 투 엔드 테스트 순으로 양이 많다.
E2E 테스트는 가장 중요한 기능에 적용할 때와, 다른 테스트들과 동일한 수준으로 보호할 때만 적용한다.
예외
- 비즈니스 규칙, 기타 복잡도가 없는 기본 CRUD라면 단위테스트 수 = 통합테스트 수 이고 E2E테스트는 없는 직사각형처럼 될 것이다.
- 아주 단순한 예에서는 통합 테스트가 단위 테스트보다 많을 수 있다.
- 단위테스트는 비즈니스 로직이 복잡할 때만 가치가 있다.
- 반면, 하위 데이터베이스까지 잘 작동하는지 확인하는 것이 중요하기 때문에 통합테스트는 복잡하든 단순하든 가치가 잘 지켜진다.
- 외부 의존성 하나만 연결하는 API(데이터베이스 하나 등) 는 E2E와 통합테스트를 구별할 수 없다. (진입점의 유무 차이만 있다)
- 사용자 인터페이스가 없으므로 E2E가 빠르게 작동한다.
- 단일 외부 의존성이라 유지비도 크지 않다.
참고서적
단위테스트, 블라디미르 코리코프
느낀점
단위 테스트와 통합테스트, E2E 테스트를 잘 구별해야겠다.
- 단위 테스트 - 비즈니스의 동작 단위 테스트(고전파 정의)
- 통합테스트 - 단위테스트의 기준을 어기는 모든 테스트
- E2E테스트 - 통합테스트 중 외부의존성을 대다수 가지고 하는 테스트
피라미드의 예외를 읽어보면, 통합테스트는 최소한 CRUD의 갯수만큼은 있어야 하는 것 같다. 유닛테스트에와 테스트를 분리해서 생각해야겠다. 통합테스트를 경시하지 말자. 유닛테스트에 대한 책이라 유닛테스트 내용이 많을 뿐이다.
사실 현재 프로젝트에서 테스트하고 싶은건 데이터베이스 단이라 빨리 3부를 읽고 싶다.
리팩터링 내성의 중요성은 많이 설명을 했는데, 어떻게 작성하는지에 대한 기술은 더 뒤에 나온다. 매개변수 하나만 추가해도 테스트가 깨질 수 있는데 이를 극복할 수 있는 테스트가 있을까? 싶다. 아니면 테스트를 같이 리팩토링하라는 건지? 더 읽어봐야 알 것 같다.
'TIL' 카테고리의 다른 글
12/31 TIL C++ 소소한 배움 (0) | 2024.12.31 |
---|---|
12/30 TIL C++ 알고리즘을 위한 STL 소소팁 (0) | 2024.12.30 |
12/28 TIL 단위 테스트의 구조 (1) | 2024.12.28 |
12/27 TIL 게임 객체 모델의 종류 (0) | 2024.12.28 |
12/27 TIL 클린 아키텍처 15장~22장 (2) | 2024.12.28 |