Android 플랫폼 개발을 처음 접하는 경우 처음부터 완전히 새로운 GTest 바이너리("네이티브" 테스트라고도 함)를 추가하는 이 완전한 예제를 사용하여 관련된 일반적인 워크플로를 시연할 수 있습니다. C++용 GTest 프레임워크에 대한 추가 정보는 GTest 프로젝트 사이트 에서 추가 문서를 참조하십시오.
이 가이드에서는 Hello World GTest 를 예로 사용합니다. 계속하기 전에 대략적인 이해를 위해 코드를 읽는 것이 좋습니다.
소스 위치 결정
일반적으로 팀은 이미 코드를 체크인할 장소와 테스트를 추가할 장소에 대한 패턴이 설정되어 있을 것입니다. 대부분의 팀은 단일 git 리포지토리를 소유하거나 다른 팀과 공유하지만 구성 요소 소스 코드가 포함된 전용 하위 디렉터리가 있습니다.
구성 요소 소스의 루트 위치가 <component source root> 에 있다고 가정하면 대부분의 구성 요소에는 그 아래에 src 및 tests 폴더가 있으며 Android.mk (또는 추가 .bp 파일로 분할)와 같은 일부 추가 파일이 있습니다.
새로운 테스트를 추가하기 때문에 src 구성 요소 옆에 tests 디렉토리를 만들고 콘텐츠로 채워야 할 것입니다.
경우에 따라 여러 테스트 모음을 개별 바이너리로 패키징해야 하기 때문에 팀에서 tests 중인 추가 디렉터리 구조가 있을 수 있습니다. 그리고 이 경우 tests 아래에 새 하위 디렉토리를 생성해야 합니다.
설명을 위해 다음은 단일 tests 폴더가 있는 구성 요소의 일반적인 디렉터리 개요입니다.
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- src (test source)
\-- foo_test.cpp
\-- ...
다음은 여러 테스트 소스 디렉터리가 있는 구성 요소의 일반적인 디렉터리 개요입니다.
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- testFoo (sub test source root)
| \-- Android.bp (sub test makefile)
| \-- src (sub test source)
| \-- test_foo.cpp
| \-- ...
\-- testBar
| \-- Android.bp
| \-- src
| \-- test_bar.cpp
| \-- ...
\-- ...
구조에 관계없이 tests 디렉토리 또는 새로 생성된 하위 디렉토리를 샘플 gerrit 변경의 native 디렉토리에 있는 것과 유사한 파일로 채우게 됩니다. 아래 섹션에서는 각 파일에 대해 더 자세히 설명합니다.
소스 코드
예를 들어 Hello World GTest 를 참조하십시오.
해당 예제의 소스 코드는 다음과 같이 주석 처리됩니다.
#include <gtest/gtest.h>
헤더 파일에는 GTest가 포함됩니다. 포함 파일 종속성은 makefile에서 BUILD_NATIVE_TEST 를 사용하여 자동으로 해결됩니다.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTest는 TEST 매크로를 사용하여 작성됩니다. 첫 번째 매개변수는 테스트 케이스 이름이고 두 번째 매개변수는 테스트 이름입니다. 테스트 바이너리 이름과 함께 결과 대시보드에서 다음 계층을 형성합니다.
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
GTest로 테스트를 작성하는 방법에 대한 자세한 내용 은 GTest 문서 를 참조하세요.
간단한 구성 파일
각각의 새로운 테스트 모듈에는 모듈 메타데이터, 컴파일 시간 종속성 및 패키징 지침으로 빌드 시스템을 지시하는 구성 파일이 있어야 합니다. 대부분의 경우 Soong 기반의 Blueprint 파일 옵션으로 충분합니다. 자세한 내용은 단순 테스트 구성 을 참조하십시오.
복잡한 구성 파일
대신 Trade Federation을 사용하려면 Android의 테스트 장치인 Trade Federation 에 대한 테스트 구성 파일을 작성하세요.
테스트 구성은 테스트 클래스를 제공하기 위해 특수 장치 설정 옵션과 기본 인수를 지정할 수 있습니다.
로컬에서 빌드 및 테스트
가장 일반적인 사용 사례의 경우 Atest 를 사용하십시오.
더 많은 사용자 정의가 필요한 더 복잡한 케이스의 경우 계측 지침 을 따르십시오.