Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.

새로운 네이티브 테스트 예 추가

Android 플랫폼 개발을 처음 사용하는 경우 처음부터 완전히 새로운 네이티브 테스트를 추가하는 완전한 예제를 통해 일반적인 워크플로를 보여줄 수 있습니다. 또한 이 C++용 gtest 프레임워크에 대해 잘 모르는 분은 추가 도움말을 gtest 프로젝트 사이트에서 확인하세요.

이 가이드에서는 다음 테스트를 샘플로 제공합니다.

Hello World 네이티브 테스트

계속 진행하기 전에 먼저 코드를 탐색하여 대략적인 노출수를 파악하는 것이 좋습니다

소스 위치 결정

일반적으로 팀에는 이미 코드를 체크인할 수 있는 위치 패턴과 테스트를 추가할 수 있는 위치가 있습니다. 대부분의 팀은 단일 git 저장소를 소유하거나 다른 팀과 저장소를 공유하지만 구성요소 소스 코드가 포함된 전용 하위 디렉터리가 있습니다.

구성요소 소스의 루트 위치가 <component source root>에 있다고 가정하면 대부분의 구성요소에는 그 아래 srctests 폴더가 있고 Android.mk(또는 추가 .bp 파일로 분할) 매니페스트 파일 AndroidManifest.xml 및 테스트 구성 파일 'AndroidTest.xml'와 같은 일부 추가 파일이 있습니다.

새 테스트를 추가하기 때문에 tests 디렉토리를 구성요소 src 옆에 만들고 콘텐츠로 채워야 합니다.

경우에 따라 개별 apk에 여러 테스트 모음을 패키징해야 하므로 팀이 tests에 추가 디렉터리 구조를 보유할 수도 있습니다. 이 경우 tests에 새 하위 디렉터리를 만들어야 합니다.

다음은 단일 tests 폴더 가있는 구성요소의 일반적인 디렉터리 개요입니다.

\
     <component source root>
      \-- Android.bp (component makefile)
      \-- AndroidTest.bp (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.bp (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!");
    }
    

gtests을 사용하여 작성된 TEST 매크로: 첫 번째 매개변수는 테스트 사례 이름이고, 두 번째는 테스트 이름이고, 테스트 바이너리 이름과 함께 결과 대시보드에 시각화될 때 아래의 계층 구조를 형성합니다.

<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 기반 청사진 파일 옵션으로 충분합니다. 자세한 내용은 간단한 테스트 구성을 참조하세요.

복잡한 구성 파일

Trade Federation을 대신 사용하려면 Android의 테스트 하네스인 Trade Federation용 테스트 구성을 작성해야 합니다.

테스트 구성에서는 특수한 기기 설정 옵션과 테스트 클래스를 제공할 기본 인수를 지정할 수 있습니다.

로컬에서 빌드 및 테스트

가장 일반적인 사용 사례인 경우 Atest를 사용하세요.

보다 심도 깊은 맞춤 설정이 필요한 복잡한 사례인 경우 계측 안내를 따르세요.