Thiết lập kiểm thử nâng cao

Các trang Kiểm thử trong Android StudioKiểm thử từ dòng lệnh sẽ giải thích cách thiết lập và chạy các cấu hình kiểm thử cơ bản. Tuy nhiên, khi ứng dụng và các yêu cầu kiểm thử trở nên nâng cao hơn, bạn có thể cần phải điều chỉnh thêm các cấu hình kiểm thử của mình. Ví dụ: bạn có thể cần thiết lập kiểm thử nâng cao khi muốn thực hiện những việc sau:

  • Chỉ chạy kiểm thử đo lường cho một biến thể xây dựng cụ thể hoặc ghi đè lên cài đặt tệp kê khai của biến thể đó.
  • Thay đổi loại hình xây dựng mà các kiểm thử của bạn sẽ chạy hoặc định cấu hình các tùy chọn Gradle.
  • Trích xuất các kiểm thử đo lường của bạn vào mô-đun kiểm thử riêng.

Trang này mô tả các cách khác nhau để định cấu hình kiểm thử khi cài đặt mặc định không phù hợp với trường hợp sử dụng.

Tạo kiểm thử đo lường cho biến thể xây dựng

Nếu dự án của bạn bao gồm các biến thể xây dựng có các nhóm tài nguyên duy nhất, bạn có thể bao gồm các kiểm thử đo lường tương ứng với các nhóm tài nguyên đó. Việc này giúp cho mã kiểm thử của bạn luôn gọn gàng và cho phép bạn chỉ chạy các kiểm thử áp dụng cho một biến thể xây dựng nhất định.

Bạn có thể liên kết các kiểm thử đo lường với một biến thể xây dựng bằng cách đặt các biến thể đó vào nhóm tài nguyên riêng của chúng, nằm trong src/androidTestVariantName.

Tất cả các biến thể xây dựng đều dùng chung kiểm thử công cụ trong nhóm tài nguyên src/androidTest/. Khi tạo một APK kiểm thử cho biến thể "MyFlavor" của ứng dụng, Gradle sẽ kết hợp các nhóm tài nguyên src/androidTest/src/androidTestMyFlavor/.

Để thêm nhóm tài nguyên kiểm thử cho biến thể xây dựng trong Android Studio, hãy thực hiện các bước sau:

  1. Trong cửa sổ Dự án ở bên trái, nhấp vào trình đơn thả xuống và chọn chế độ xem Dự án.
  2. Trong thư mục mô-đun thích hợp, nhấp chuột phải vào thư mục src, sau đó nhấp vào Mới > Thư mục.
  3. Ở ô tên thư mục, nhập "androidTestVariableName". Ví dụ: nếu bạn có một biến thể xây dựng có tên là "MyFlavor" thì tên thư mục phải là "androidTestMyFlavor". Sau đó, nhấp vào OK.
  4. Nhấp chuột phải vào thư mục mới rồi nhấp vào Mới > Thư mục.
  5. Nhập "java" làm tên thư mục, sau đó nhấp vào OK.

Bây giờ, bạn có thể thêm các kiểm thử vào nhóm tài nguyên mới này bằng cách làm theo các bước thêm kiểm thử nghiệm. Khi bạn đến hộp thoại Chọn thư mục đích, nhóm tài nguyên kiểm thử biến thể mới.

Bảng sau đây là một ví dụ về vị trí của tệp kiểm thử đo lường trong các nhóm tài nguyên tương ứng với nhóm tài nguyên mã của ứng dụng.

Bảng 1. Mã nguồn ứng dụng và tệp kiểm thử đo lường tương ứng.

Đường dẫn đến lớp ứng dụng Đường dẫn đến lớp kiểm thử đo lường trùng khớp
src/main/java/Foo.java src/androidTest/java/AndroidFooTest.java
src/myFlavor/java/Foo.java src/androidTestMyFlavor/java/AndroidFooTest.java

Giống như với nhóm tài nguyên ứng dụng, bản dựng trên Gradle sẽ hợp nhất và ghi đè các tệp từ các nhóm tài nguyên kiểm thử khác nhau. Trong trường hợp này, tệp AndroidFooTest.java trong nhóm tài nguyên androidTestMyFlavor sẽ ghi đè phiên bản trong nhóm tài nguyên androidTest. Lý do là nhóm tài nguyên phiên bản sản phẩm có mức độ ưu tiên cao hơn nhóm tài nguyên chính. Để biết thêm thông tin về cách hợp nhất các nhóm tài nguyên, hãy xem nội dung Định cấu hình bản dựng.

Định cấu hình chế độ cài đặt tệp kê khai về khả năng đo lường

Các kiểm thử đo lường được xây dựng thành một APK riêng, có tệp AndroidManifest.xml riêng. Khi Gradle tạo APK kiểm thử của bạn, tệp này sẽ tự động tạo tệp AndroidManifest.xml và định cấu hình tệp đó bằng nút <instrumentation>. Một trong những lý do Gradle định cấu hình nút này cho bạn là để đảm bảo rằng thuộc tính targetPackage chỉ định đúng tên gói của ứng dụng đang được kiểm thử. Bạn có thể thay đổi một số chế độ cài đặt khác cho nút này bằng cách tạo một tệp kê khai khác trong nhóm tài nguyên kiểm thử hoặc định cấu hình tệp build.gradle cấp mô-đun như hiển thị trong mã mẫu sau. Bạn có thể xem danh sách đầy đủ các tùy chọn trong Tài liệu tham khảo API BaseFlavor.

android {

    ...

    // Each product flavor you configure can override properties in the
    // defaultConfig {} block. To learn more, go to Configure product flavors.

    defaultConfig {

        ...

        // Specifies the application ID for the test APK.
        testApplicationId = "com.test.foo"

        // Specifies the fully-qualified class name of the test instrumentation
        // runner.
        testInstrumentationRunner = "android.test.InstrumentationTestRunner"

        // If set to true, enables the instrumentation class to start and stop profiling.
        // If set to false (default), profiling occurs the entire time the instrumentation
        // class is running.
        testHandleProfiling = true

        // If set to true, indicates that the Android system should run the instrumentation
        // class as a functional test. The default value is false.
        testFunctionalTest = true

    }
}

Thay đổi loại hình xây dựng kiểm thử

Theo mặc định, tất cả các kiểm thử đo lường đều chạy dựa trên loại hình xây dựng debug. Bạn có thể thay đổi thuộc tính này thành một loại hình xây dựng khác bằng cách sử dụng thuộc tính testBuildType trong tệp build.gradle cấp mô-đun. Ví dụ: nếu bạn muốn chạy chương trình kiểm thử theo loại bản dựng staging, hãy chỉnh sửa tệp như hiển thị trong đoạn mã sau.

android {

    ...

    testBuildType "staging"

}

Định cấu hình các tuỳ chọn kiểm thử trên Gradle

Trình bổ trợ Android cho Gradle cho phép bạn chỉ định một số tùy chọn cho tất cả hoặc chỉ một số kiểm thử của mình. Trong tệp build.gradle cấp mô-đun, hãy sử dụng khối testOptions{} để chỉ định các tùy chọn thay đổi cách Gradle chạy tất cả các kiểm thử của bạn.

Groovy

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        // Changes the directory where Gradle saves test reports. By default,
        // Gradle saves test reports in the
        // path_to_your_project/module_name/build/outputs/reports/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        reportDir "$rootDir/test-reports"
        // Changes the directory where Gradle saves test results. By default,
        // Gradle saves test results in the
        // path_to_your_project/module_name/build/outputs/test-results/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        resultsDir "$rootDir/test-results"
    }
}

Kotlin

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        // Changes the directory where Gradle saves test reports. By default,
        // Gradle saves test reports in the
        // path_to_your_project/module_name/build/outputs/reports/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        reportDir "$rootDir/test-reports"
        // Changes the directory where Gradle saves test results. By default,
        // Gradle saves test results in the
        // path_to_your_project/module_name/build/outputs/test-results/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        resultsDir = "$rootDir/test-results"
    }
}

Để chỉ định các tùy chọn chỉ dành cho kiểm thử đơn vị cục bộ, hãy định cấu hình khối unitTests{} bên trong testOptions{}.

Groovy

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            // By default, local unit tests throw an exception any time the code
            // you are testing tries to access Android platform APIs (unless you
            /// mock Android dependencies yourself or with a testing framework like Mockito).
            // However, you can enable the following property so that the test
            // returns either null or zero when accessing platform APIs, rather
            // than throwing an exception.
            returnDefaultValues true

            // Encapsulates options for controlling how Gradle executes local
            // unit tests. For a list of all the options you can specify, read
            // Gradle's reference documentation.
            all {
                // Sets JVM argument(s) for the test JVM(s).
                jvmArgs '-XX:MaxPermSize=256m'

                // You can also check the task name to apply options to only the
                // tests you specify.
                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

Kotlin

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            // By default, local unit tests throw an exception any time the code
            // you are testing tries to access Android platform APIs (unless you
            /// mock Android dependencies yourself or with a testing framework like Mockito).
            // However, you can enable the following property so that the test
            // returns either null or zero when accessing platform APIs, rather
            // than throwing an exception.
            returnDefaultValues = true

            // Encapsulates options for controlling how Gradle executes local
            // unit tests. For a list of all the options you can specify, read
            // Gradle's reference documentation.
            all {
                // Sets JVM argument(s) for the test JVM(s).
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                // You can also check the task name to apply options to only the
                // tests you specify.
                if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

Sử dụng các mô-đun kiểm thử riêng biệt cho các kiểm thử đo lường

Nếu muốn có một mô-đun dành riêng cho các kiểm thử đo lường và tách biệt phần còn lại của mã khỏi các kiểm thử, bạn có thể tạo một mô-đun kiểm thử riêng và định cấu hình xây dựng của mô-đun đó tương tự như mô-đun của thư viện. Để tạo mô-đun kiểm thử, hãy tiến hành như sau:

  1. Tạo mô-đun thư viện.
  2. Trong tệp build.gradle cấp mô-đun, sử dụng trình bổ trợ com.android.test thay vì com.android.library.
  3. Đồng bộ hoá dự án bằng cách nhấp vào biểu tượng Đồng bộ hoá dự án

Sau khi tạo mô-đun kiểm thử , bạn có thể đưa mã kiểm thử vào nhóm tài nguyên chính hoặc biến thể (ví dụ: src/main/java hoặc src/variant/java). Nếu mô-đun ứng dụng của bạn xác định nhiều phiên bản sản phẩm, bạn có thể tạo lại các phiên bản đó trong mô-đun kiểm thử của mình và sử dụng tính năng quản lý phần phụ thuộc nhận biết biến thể, mô-đun kiểm thử sẽ kiểm thử phiên bản trùng khớp trong mô-đun mục tiêu.

Theo mặc định, các mô-đun kiểm thử chỉ chứa và kiểm tra một biến thể gỡ lỗi. Tuy nhiên, bạn có thể tạo các loại hình xây dựng mới để phù hợp với dự án ứng dụng đã kiểm thử. Để mô-đun kiểm thử thực hiện kiểm thử một loại hình xây dựng khác mà không phải kiểm thử gỡ lỗi, hãy sử dụng VariantFilter để tắt biến thể gỡ lỗi trong dự án kiểm thử, như hiển thị bên dưới:

Groovy

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

Kotlin

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

Nếu muốn một mô-đun kiểm thử chỉ nhắm mục tiêu các phiên bản nhất định hoặc các loại hình xây dựng của một ứng dụng, bạn có thể sử dụng thuộc tính matchingFallbacks để chỉ nhắm mục tiêu các biến thể mà bạn muốn kiểm thử. Việc này cũng ngăn chặn mô-đun kiểm thử không tự định cấu hình các biến thể đó.