북클럽 [구글 엔지니어는 이렇게 일한다] - 테스트의 중요성과 단위테스트

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

단위 테스트

대상자

• 초보~중급 개발자
• 테스트 코드 작성 및 유지보수에 관심 있는 개발자
• MSA환경, E2E테스트 도입 고민 중인 팀

핵심 요약

• 테스트 문화 도입은 버그 감소로 직접적인 개발 생산성 향상(구글의 사례: 1년 후 긴급 배포 건 절반 감소)
• 단위 테스트 작성 시 '공개 API만 테스트'하고, 상호작용 대신 결과 상태(State)를 검증해야 한다.
• 테스트 코드는 'DAMP 원칙'(Descriptive And Meaningful Phase)을 따르며, 메서드 이름에 의도 명시해야 한다.

섹션별 세부 요약

11장 "테스트 개요"

• 테스트 도입 배경: 구글 웹서버에서 2005년 급격한 복잡성 증가로 버그 증가 → 테스트 도입 후 릴리스 주기 단축
• 테스트 문화 활성화: 작은 테스트(1프로세스 내 실행)를 권장하며, 외부 네트워크 호출 금지
• 크기 vs 범위:

- 작은 테스트: 메모리, 시간 소요 최소 → 결정적 검증 가능

- 중간 테스트: localhost 네트워크 호출 허용 → E2E테스트와 유사

- 큰 테스트: 외부 시스템과의 호출 허용 → 비결정적 요소 많음

12장 "단위 테스트"

• 깨지기 쉬운 테스트: 리팩토링, 버그 수정 시 1% 실패율 → 10000개 테스트 중 100개 실패로 디버깅 복잡성 증가
• 테스트 의도 명확화:

- 공개 API만 테스트 → 내부 메서드(private)는 테스트 제외

- 상호작용 대신 상태(result) 검증 → A함수 실행 여부 대신 최종 결과값 집중

• 테스트 코드 작성 가이드:

- Given-When-Then 패턴 적용

- 메서드 이름에 행위 명시 (예: testCalculateSumWithNegativeNumbers())

- DAMP 원칙 적용: 중복 허용 대신 의도를 서술적으로 표현

테스트 문화의 현실 문제

• MSA 환경에서의 단위 테스트 제약: Mocking 요소 증가 → 의존성 강화, 관심사 분리 미흡
• Bypass 서비스 테스트 전략:

- 로직 없이 시스템 연결 역할 → E2E테스트 도입 권장

- 예: 외부 시스템 → G/W → Bypass 서비스 → 다른 서비스 흐름 검증

결론

• 단위 테스트는 '기능 변경' 외에는 절대 실패하지 않도록 작성해야 하며, 테스트 코드도 유지보수 대상으로 다루어야 한다.
• DAMP 원칙을 따르고, 메서드 이름에 테스트 의도 명시 → 테스트 코드가 '서비스 설명서' 역할 수행
• MSA 환경에서의 단위 테스트는 Mocking 최소화, 관심사 분리 강화를 통해 서비스 안정성과 개발자 커뮤니케이션 향상 가능