[구글 엔지니어는 이렇게 일한다: 구글러가 전하는 문화, 프로세스, 도구의 모든것] CHAPTER 14 더 큰 테스트 - 요약 & 발제문

1. 더 큰 테스트란?

더 큰 테스트의 단점

• 느릴 수 있습니다. 구글에서 대규모 테스트의 기본 타임아웃 값은 15분이나 1시간입니다. 심지어 몇 시간이나 며칠이 걸리는 테스트도 만들어 활용합니다.
• 밀폐되지 않을 수 있습니다. 대규모 테스트는 다른 테스트나 최종 사용자와 자원 및 트래픽을 공유하기도 합니다
• 비결정적일 수 있습니다. 예컨대 밀폐되지 않은 대규모 테스트라면 다른 테스트나 사용자 상태에 영향을 받을 수 있어서 완벽히 결정적이라고 보장하기가 거의 불가능합니다.

이런 단점들에도 불구하고 더 큰 테스트를 이용하는 이유는 시스템 ‘전체’가 의도대로 동작한다는 확신을 더해주는 역할을 하기 때문입니다.

1.1 충실성

더 큰 테스트가 존재하는 첫 번째 이유는 바로 충실성을 높이기 위함입니다. 그림 14-1처럼 테스트 크기가 클수록 충실성이 높아지지만 충실성이 높을수록 테스트 실패 시 입는 손해는 커집니다.

1.2 단위 테스트가 손 대기 어려운 영역

작은 테스트가 해낼 수 없는 영역이라면 더 큰 테스트가 필요합니다. 다음은 단위 테스트로는 위험 요인을 충분히 해소하기 어려운 5가지 입니다.

1. 부정확한 테스트 대역
2. 배포 설정이나 시작 스크립트 같은 설정 문제
3. 과부하 시 나타나는 문제
4. 사용자들의 예기치 못한 동작, 입력, 부작용
5. 네트워크 연결과 같은 창발적 행위와 진공효과

1.3 더 큰 테스트를 만들지 않는 이유

좋은 단위 테스트라면 높은 신뢰성, 빠른 속도, 높은 확장성의 특징을 모두 갖춰야 하는데 더 큰 테스트는 하나도 갖추지 못하는 경우도 있습니다. 따라서 더 큰 테스트는 소유권 확립과 표준화의 부족을 극복해야 됩니다.

2. 더 큰 테스트 @구글

구글은 단위 테스트와 그 외 테스트를 구분하고 있습니다.

2.1 더 큰 테스트와 수명

테스트 코드의 건강한 상태를 유지하는 핵심은 개발 시작 후 며칠 안으로 단위 테스트를 만들어 테스트 피라미드를 쌓기 시작하는 것입니다. 그런 다음 수동으로 수행하던 종단 간 테스트를 자동화된 통합 테스트로 대체해 피라미드 위층으로 올립니다. 구글은 코드를 제출하려면 ‘반드시’ 단위 테스트를 포함하도록 규정하여 해결했습니다. 오랫동안 코드를 건강하게 유지하려면 단위 테스트와 수동 테스트 사이의 간극을 메우는 데 소홀해서는 안 됩니다.

2.2 구글 규모에서의 더 큰 테스트

테스트 대상(SUT)의 구조가 복잡해질수록 버그가 생길 가능성은 기하급수적으로 증가합니다. 따라서 더 큰 테스트들은 원하는 규모에서 잘 작동하면서도 충실성이 상당히 높게 구현하는 게 관건입니다.

3. 큰 테스트의 구조

큰 테스트들은 작은 테스트의 제약 조건에 구속받지 않아서 어떤 형태로든 만들 수 있지만, 그래도 대부분은 공통된 패턴을 따릅니다.

3.1 테스트 대상 시스템(SUT)

구글에는 다양한 형태의 SUT가 존재하며, SUT의 범위가 대규모 테스트 자체의 범위를 규정하는 주된 요소입니다. SUT는 밀폐성과 충실성에 의해 결정됩니다. 하지만 이 두 요소는 다음과 같은 형태에서 충돌할 때가 많습니다.

• 단일 프로세스 SUT
• SUT가 작은 테스트로 이루어질수록 충실성 측면에서는 프로덕션의 토폴리지나 설정과 거리가 먼 테스트가 됩니다.
• 단일 머신 SUT
• 테스트와 프로덕션이 하나의 머신에서 구동하는 경우 같은 실행 설정을 그대로 사용하게 됩니다.
• 다중 머신 SUT
• 테스트 규모가 커지면서 여러 머신과 그 사이를 잇는 네트워크가 불안정성을 키워 테스트에 예기치 못한 영향을 줄 가능성이 커집니다.
• 공유 환경(스테이징과 프로덕션)
• 공유 환경을 함께 이용 중인 다른 엔지니어들과 충돌할 수 있으므로 테스트 만을 위해 임의로 변경할 수 없고 정상적인 배포 워크플로를 따라 코드가 해당 환경에 배포될 때까지 기다려야 합니다.
• 하이브리드
• SUT가 혼합된 형태

3.2 테스트 데이터

대규모 테스트라면 시드 데이터와 테스트 트래픽이 필요합니다.

SUT가 독립적으로 실행되고 크기 때문에 테스트 전에 초기화합니다. 초기화하기 위한 방법으로는 도메인 데이터 사용, 현실적인 데이터셋 설정이 있습니다.

데이터는 순수하게 직접 만들거나, 프로덕션 시스템으로 부터 복사하거나, 운영 중인 서비스 데이터의 표본을 추출하여 사용합니다.

3.3 검증

SUT를 검증하기 위해 수동으로 검증하거나, 단정문을 사용하거나, 두 개의 SUT를 구동시켜 동일한 데이터를 보낸 다음 결과를 비교하는 A/B테스트가 있습니다.

4. 더 큰 테스트 유형

다음 목록은 구글에서 사용하는 더 큰 테스트의 종류입니다.

• 하나 이상의 바이너리에 대한 기능 테스트
• 브라우저와 기기 테스트
• 성능, 부하, 스트레스 테스트
• 배포 설정 테스트
• 탐색적 테스팅
• A/B 차이(회귀) 테스트
• 사용자 인수 테스트(UAT )
• 프로버와 카나리 분석
• 재해 복구와 카오스 엔지니어링
• 사용자 평가

테스트 종류가 많은 만큼 가능한 조합도 많습니다. 구글은 소프트웨어 설계의 일환으로 테스트 계획의 초안도 작성합니다. 그리고 이 계획의 핵심은 어떤 테스트가 필요하고 각각의 테스트를 얼마나 많이 수행해야 하는지에 관한 개략적인 전략 확립입니다. 테스트 전략은 주요한 위험 요소를 찾고, 찾아낸 위험 요소들을 완화해 주는 테스트 방식을 정하는 것입니다.

5. 큰 테스트와 개발자 워크플로

큰 테스트 역시 개발자 워크플로에 통합하는 일은 매우 중요합니다. 한 가지 묘안은 코드 서브밋 전과 후에 수행되는 메커니즘 갖추기 입니다. 구글은 큰 테스트들을 자동 수행하는 별도의 지속적 빌드를 갖추고 서브밋 전 단계에서 수행하도록 독려합니다. 또한 UI 변경이 포함되어 있다면 자동으로 버그가 등록되고 릴리스가 중단되게 했습니다. 서브밋 전 단계의 테스트는 개발자들을 고통스럽게 만들지만 지속적인 빌드의 신뢰성을 줍니다. 따라서 둘 사이의 절충점을 찾아야 합니다.

5.1 큰 테스트 작성하기

큰 테스트를 작성할 때 가장 좋은 방법은 명확한 라이브러리, 문서자료, 예시 코드를 참조하는 것입니다.

5.2 큰 테스트 수행하기

구글은 테스트 속도 개선하기, 불규칙한 결과에서 벗어나기, 이해되는 테스트 만들기 등을 통해서 더 큰 테스트들을 엔지니어에게 친숙한 방식으로 수행하려 노력합니다.

5.3 큰 테스트의 소유권

더 큰 테스트에는 반드시 소유자가 문서로 기록되어 있어야 합니다. 소유자란 테스트가 변경될 때 검토해 주고 테스트가 실패했을 때 지원해 줄 수 있는 사람을 뜻합니다. 구글은 일반적인 코드 소유권과 테스트별 애너테이션을 이용해 소유권 정보를 구조화하여 기록합니다.

6. 마치며

더 큰 테스트라고 해도 (충실성을 유지하면서) 되도록 작게 만들어서 개발자 워크플로에 부드럽게 녹여야 한다는 원칙은 변하지 않습니다. 시스템의 위험 요소를 찾아내는 종합적인 테스트 전략과 이를 뒷받침하는 더 큰 테스트는 대부분의 소프트웨어 프로젝트에 반드시 필요합니다.

발제문

1. 더 큰 테스트의 중요성: 더 큰 테스트는 단위 테스트에서는 파악하기 어려운 시스템 전체의 동작을 확인하는 데 중요합니다. 그러나 이들 테스트는 느리거나, 밀폐되지 않거나, 비결정적일 수 있습니다. 이런 단점들에 대한 생각은 어떠한가요?
   
   
2. 더 큰 테스트의 충실성과 단위 테스트의 한계: 더 큰 테스트는 시스템의 충실성을 높이는데 기여하지만, 테스트 실패 시 큰 손해를 입을 수 있습니다. 왜 충실성이 높으면 테스트 실패 시 큰 손해가 생길까요? 책에서 다시 한번 찾아봅시다.

본서