Android 플랫폼 개발이 처음인 경우, 완전히 새로운 GTest 바이너리('네이티브' 테스트라고도 함)를 추가하는 방법을 보여주는 이 전체 예를 처음에 확인하면 일반적인 관련 워크플로를 아는 데 도움이 됩니다. C++용 GTest 프레임워크에 관한 자세한 내용은 GTest 프로젝트 사이트에서 추가 문서를 참고하세요.
이 가이드에서는 Hello World GTest를 예로 사용합니다. 계속 진행하기 전에 코드를 살펴서 코드를 대략적으로 이해하는 것이 좋습니다.
소스 위치 결정
일반적으로 개발팀에는 이미 코드를 체크인할 수 있는 위치 및 테스트를 추가할 수 있는 위치의 패턴이 마련되어 있습니다. 대부분의 팀에는 하나의 git 저장소가 있거나, 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용 헤더 파일의 include. include 파일 종속 항목은 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를 사용하세요.
보다 심도 깊은 맞춤설정이 필요한 복잡한 사례인 경우 계측 안내를 따르세요.