Android 플랫폼 개발을 처음 하는 경우 처음부터 완전히 새로운 네이티브 테스트를 추가하는 완벽한 예를 통해 일반적인 워크플로를 볼 수 있습니다. 또한, C++용 gtest 프레임워크를 잘 모른다면 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 네이티브 테스트의 예를 참고하세요.
주석이 달린 소스 코드는 다음과 같습니다.
#include <gtest/gtest.h>
gtest를 위해 포함되는 헤더 파일입니다. 포함되는 헤더 파일의 종속 항목은 makefile의 BUILD_NATIVE_TEST를 사용하여 자동으로 해결됩니다.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
TEST 매크로를 사용하여 작성된 gtest입니다. 첫 번째 매개변수는 테스트 사례 이름이고 두 번째 매개변수는 테스트 이름입니다. 이러한 매개변수는 결과 대시보드에 시각화될 때 테스트 바이너리 이름과 함께 아래의 계층구조를 형성합니다.
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
gtest를 사용한 테스트 작성에 대한 자세한 내용은 다음 문서를 참조하세요.
- https://github.com/google/googletest/blob/master/googletest/docs/Primer.md
간단한 구성 파일
새로운 각 테스트 모듈에는 모듈 메타데이터, 컴파일 시간 종속 항목 및 패키징 지침으로 빌드 시스템을 안내할 구성 파일이 있어야 합니다. 대부분은 Soong 기반의 Blueprint 파일 옵션으로 충분합니다. 자세한 내용은 간단한 테스트 구성을 참고하세요.
복잡한 구성 파일
Trade Federation을 대신 사용하려면 Android의 테스트 하네스인 Trade Federation용 테스트 구성 파일을 작성해야 합니다.
테스트 구성에서는 특별한 기기 설정 옵션과 테스트 클래스 공급에 사용할 기본 인수를 지정할 수 있습니다.
로컬에서 빌드 및 테스트
가장 일반적인 사용 사례에는 Atest를 사용하세요.
보다 심도 깊은 맞춤설정이 필요한 복잡한 사례인 경우 계측 안내를 따르세요.