책 발췌 – 구글의 테스트 타입을 구분하는 용어
출처: 책 How Google Tests Software, James Whittaker, Jason Arbon, Jeff Carollo, 2012년
구글에서 조직 구성원 간 테스트 용어로 인한 혼란을 피하기 위해 테스트 규모(범위)를 기준으로 테스트 타입을 표준화한 것을 소개
테스트 타입(Types of Tests)
구글이 성장하고 신규 직원 채용이 늘어나면서 단위 테스트, 코드 기반 테스트, 화이트 박스 테스트, 통합 테스트, 시스템 테스트, 종단(end-to-end) 테스트 등의 테스트 타입에 대한 다양한 명명법으로 인한 혼란이 있었다. 이를 해소하기 위해 구글은 형식보다 범위를 강조한 스몰 테스트, 미디엄 테스트, 라지 테스트라는 표준 용어를 정의하였다.
스몰 테스트(Small tests)
스몰 테스트는 (항상은 아니더라도) 대부분 자동화되고 단일 함수 또는 모듈 내에서 코드를 실행한다. 테스트 초점은 전형적인 기능 이슈, 데이터 손상, 에러 조건, off-by-one 실수 등에 있다. 스몰 테스트는 짧은 기간 동안 실행된다(일반적으로 몇 초 이내). 이를 SWE가 작성할 가능성이 가장 높고, 빈도는 낮지만 간혹 SET가 작성기도 하며, TE에 의해 작성되는 경우는 거의 없다. 스몰 테스트는 일반적으로 실행을 위해서 모형(mock) 및 가짜 환경이 필요하다. 즉, 종속 관계에 있는 실제 모듈이 아직 존재하지 않거나, 버그가 너무 많아서 신뢰하기 어렵거나, 또는 에러 조건을 에뮬레이트 하기가 너무 어렵거나 등의 이유로 이를 대신하여 자리를 차지하는 스터브가 필요하다. TE가 스몰 테스트를 작성하는 경우는 드물지만 특정 오류 진단을 위해서 이를 실행하기도 한다. 스몰 테스트가 답하고자 하는 바는 "코드가 자신이 수행하기로 된 것을 정말 수행하는가(Does this code do what it is supposed to do)?" 이다.
미디엄 테스트(Medium tests)
미디엄 테스트는 일반적으로 자동화되며 둘 이상의 인터액션하는 기능들과 관련 있다. 서로를 호출하거나 또는 직접 인터액션하는 기능 간의 상호 작용을 테스트하는 것에 초점을 둔다(이런 것들을 가장 가까운 이웃 함수라고 칭함). 미디엄 테스트는 상호 작용하는 다수의 코드 단위들을 가짜 환경 또는 실제 환경에서 실행한다. SET는 제품 주기 초기에 이러한 테스트의 개발을 주도하며, 실제 이 테스트를 작성하고 디버깅하고 유지 관리하는 것은 SWE가 크게 관여한다. 미디엄 테스트가 실패하거나 중단되면 개발자가 이를 자체적으로 처리한다. 개발 주기 후반에 TE는 수동으로(테스트가 어렵거나 자동화하기에 엄청나게 비용이 많이 드는 경우) 또는 자동화를 통해 미디엄 테스트를 실행할 수 있다. 미디엄 테스트가 답하고자 하는 바는 "일련의 이웃 함수들이 의도한 대로 서로 상호운용 하는가(Does a set of near neighbor functions interoperate with each other the way they are supposed to)?" 이다.
라지 테스트(Large tests)
라지 테스트는 3개 이상 다수의 기능을 커버한다. 이 테스트가 실제 사용자 시나리오를 나타내며, 실제 생산 환경에서 실제 사용자 데이터 소스를 사용한다. 이를 실행하는 데 몇 시간 또는 그 이상이 걸릴 수 있다. 기능의 전반적 통합에 대해 일부 관심을 기울이기도 하지만 라지 테스트는 좀 더 결과 중심적인 경향이 있다(즉, 소프트웨어가 사용자 요구를 충족하는지를 확인함). 구글 엔지니어의 세 가지 유형 모두 라지 테스트 작성에 관여하며, 자동화에서부터 탐색적 테스트에 이르는 모든 것이 라지 테스트를 달성하는 수단이 될 수 있다. 라지 테스트가 답하고자 하는 것은 "제품이 사용자가 기대하는 방식으로 작동하고 의도한 결과를 생성하는가(Does the product operate the way a user would expect and produce the desired results)?" 이다. 완전한 전체 제품/서비스 상에서 작동하는 종단 간 시나리오(end-to-end scenarios)가 라지 테스트이다.
| 스몰 테스트 (Small Tests) |
미디엄 테스트 (Medium Tests) |
라지 테스트 (Large Tests) |
거대 테스트 (Enormous Tests) |
|
| 시간 목표 | 100밀리초 이내에 실행 | 1초 이내에 실행 | 최대한 빨리 실행 | 최대한 빨리 실행 |
| 시간 제한 | 1분 후에 스몰 테스트 대상 죽임(강제 종료) | 5분 후에 미디엄 테스트 대상 죽임 | 15분 후에 라지 테스트 대상 죽임 | 1시간 후에 거대 테스트 대상 죽임 |
표 2.1 테스트 크기별 테스트 실행 시간 목표 및 제한
| 리소스 | 라지 테스트 | 미디엄 테스트 | 스몰 테스트 |
| 네트워크 서비스(소켓 열기) | Yes | localhost only(로컬호스트만) | Mocked(모형으로 대체) |
| 데이터베이스 | Yes | Yes | Mocked |
| 파일 시스템 액세스 | Yes | Yes | Mocked |
| 사용자 대면 시스템에 액세스 | Yes | 권장 안함 | Mocked |
| Syscall 호출 | Yes | 권장 안함 | No |
| 다중 스레드 | Yes | Yes | 권장 안함 |
| Sleep 문장 | Yes | Yes | No |
| 시스템 속성 | Yes | Yes | No |
표 2.2 테스트 크기별 리소스 사용
스몰, 미디엄, 라지라는 단어 자체는 그다지 중요하지 않다. 이런 용어가 의미하는 바를 구성원 모두가 동의하기만 한다면 그게 뭐가 되었든 원하는 대로 부르면 된다. 중요한 것은 구글 테스터들이 우리가 지금 무엇을 테스트하고 있고 이 테스트의 범위가 어디인지에 대해 의사소통할 수 있는 공통 언어를 공유한다는 점이다.
70-20-10 규칙
스몰 테스트는 코드 품질, 우수한 예외 처리, 우수한 에러 보고를 도모하고, 라지 테스트는 전반적인 제품 품질 및 데이터 유효성 검사를 도모한다. 이 중 어떤 하나만으로 프로젝트의 모든 테스트 요구사항을 해결할 수 없으며 따라서 구글에서는 프로젝트 테스트스위트(test suite)가 이들의 적절한 배합을 유지하는 것을 권장한다. 즉, 프로젝트가 대규모 엔드투엔드 테스트 프레임워크를 통해 모든 것을 자동화하는 것도 좋지 않고, 역으로 작은 단위 테스트만 제공하는 것도 역시 좋지 않다.
구글에는 다양한 유형의 프로젝트가 있고 이것들의 테스트 요구사항이 매우 다르기 때문에 스몰-미디엄-라지 테스트의 정확한 비율은 각 팀에게 달려 있다(즉, 이에 대한 규정이 정해져 있지 않다). 다만 어림잡아 70-20-10의 규칙으로 시작하는 것이 일반적이다. 테스트의 70%는 스몰 테스트(단일 클래스 또는 기능의 동작을 확인), 20%는 미디엄 테스트(하나 이상의 애플리케이션 모듈의 통합을 확인), 그리고 10%는 라지 테스트(상위 레벨에서 동작하며 애플리케이션이 전체적으로 작동하는지 확인)가 차지한다. 프로젝트가 사용자를 대면하는 것이거나, 높은 수준의 통합이 요구되거나, 또는 복잡한 사용자 인터페이스를 가지는 경우라면 미디엄과 라지 테스트가 더 많아야 한다. 반면 인덱싱 또는 크롤링과 같은 인프라구조 또는 데이터 중심 프로젝트라면 매우 많은 수의 스몰 테스트와 훨씬 적은 수의 미디엄 또는 라지 테스트를 가진다.
자동 vs 수동 배합
자동 테스트와 수동 테스트 간 배합은 세 가지 크기의 테스트 모두에서 전자를 선호한다. 자동화가 가능하고 인간의 영리함과 직관을 필요로 하지 않는 문제라면 그것이 자동화되어야 한다. 사용자 인터페이스의 아름다움이나 일부 데이터 노출이 개인 정보 보호 문제인지 여부 같은 특별히 인간 판단이 필요한 범주의 문제만 수동 테스트 영역에 남아 있도록 한다.