Thiết lập cấu hình kiểm thử nâng cao

Các bài viết Kiểm thử trong Android Studio và Kiểm thử từ dòng lệnh 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 của bạn và các yêu cầu kiểm thử của ứng dụng 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 cấu hình kiểm thử nâng cao khi muốn thực hiện những việc sau:

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

Trang này mô tả các cách định cấu hình cho hoạt động kiểm thử khi chế độ cài đặt mặc định không phù hợp với nhu cầu của bạn.

Tạo hoạt động kiểm thử đo lường cho biến thể bản dựng

Nếu dự án của bạn bao gồm các biến thể bản dựng có các nhóm tài nguyên duy nhất, thì bạn nên bao gồm các hoạt động 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 hoạt động kiểm thử áp dụng cho một biến thể bản dựng nhất định.

Để liên kết các hoạt động kiểm thử đo lường với một biến thể bản dựng, hãy đặt các hoạt động kiểm thử đó trong nhóm tài nguyên riêng tại src/androidTestVariantName.

Các hoạt động kiểm thử đo lường trong nhóm tài nguyên src/androidTest/ được áp dụng chung cho tất cả các biến thể bản dựng. 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/ và src/androidTestMyFlavor/.

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

  1. Trong cửa sổ Project (Dự án), hãy nhấp vào trình đơn và chọn khung hiển thị Project (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 New > Directory (Mới > Thư mục).
  3. Đối với tên thư mục, hãy nhập "androidTestVariableName". Ví dụ: nếu bạn có một biến thể bản dựng có tên là "MyFlavor", hãy sử dụng tên thư mục androidTestMyFlavor.
  4. Nhấp vào OK.
  5. Nhấp chuột phải vào thư mục mới rồi chọn New > Directory (Mới > Thư mục).
  6. 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 hoạt động 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 hoạt động kiểm thử mới. Khi bạn chuyển đến hộp thoại Choose Destination Directory (Chọn thư mục đích), hãy chọn 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à các 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 phù hợp
src/main/java/Example.java src/androidTest/java/AndroidExampleTest.java
src/myFlavor/java/Example.java src/androidTestMyFlavor/java/AndroidExampleTest.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ử. Trong trường hợp này, tệp AndroidExampleTest.java trong nhóm tài nguyên androidTestMyFlavor ghi đè phiên bản trong nhóm tài nguyên androidTest. Điều này là do 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.

Khi bạn chọn nhiều phiên bản trong bộ chọn biến thể bản dựng, các thư mục androidTest thích hợp sẽ xuất hiện trong khung hiển thị Android để hiển thị các thư mục được sử dụng:

Biến thể MyFlavor được chọn và thư mục androidTestMyFlavor hiển thị trong khung hiển thị Android
Hình 1. Biến thể MyFlavor được chọn; thư mục androidTestMyFlavor hiển thị trong khung hiển thị Android.

Thư mục androidTestMyFlavor không hiển thị khi một biến thể khác được chọn:

Biến thể OtherFlavor được chọn và thư mục androidTestMyFlavor không hiển thị trong khung hiển thị Android
Hình 2. Biến thể OtherFlavor được chọn; thư mục androidTestMyFlavor không hiển thị trong khung hiển thị Android.

Giao diện sẽ hơi khác nếu bạn đang sử dụng khung hiển thị Project (Dự án) nhưng áp dụng cùng một nguyên tắc:

Biến thể MyFlavor được chọn và thư mục androidTestMyFlavor đang hoạt động trong khung hiển thị Project (Dự án)
Hình 3. Biến thể MyFlavor được chọn; thư mục androidTestMyFlavor đang hoạt động trong khung hiển thị Project (Dự án).

Khi một biến thể khác được chọn, thư mục androidTestMyFlavor vẫn sẽ hiển thị, nhưng không ở trạng thái đang hoạt động:

Biến thể OtherFlavor được chọn và thư mục androidTestMyFlavor không hoạt động trong khung hiển thị (Project) Dự án
Hình 4. Biến thể OtherFlavor được chọn; thư mục androidTestMyFlavor không hoạt động trong khung hiển thị Project (Dự án).

Để 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 phần Nhóm tài nguyên.

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

Các hoạt động kiểm thử đo lường được tích hợp vào một APK riêng, có tệp AndroidManifest.xml riêng. Khi tạo APK kiểm thử cho bạn, Gradle 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ử.

Để thay đổi các chế độ cài đặt khác cho nút này, hãy 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ư minh hoạ trong mã mẫu sau. Bạn có thể xem danh sách đầy đủ các tuỳ chọn trong Tài liệu tham khảo API BaseFlavor.

Groovy

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

Kotlin

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

Mỗi phiên bản sản phẩm mà bạn định cấu hình đều có thể ghi đè các thuộc tính trong khối defaultConfig {}. Để tìm hiểu thêm, hãy chuyển đến phần Định cấu hình phiên bản sản phẩm.

Các thuộc tính trong đoạn mã là:

Chế độ cài đặt Mô tả
testApplicationId Chỉ định mã ứng dụng cho APK kiểm thử.
testInstrumentationRunner Chỉ định tên lớp đủ điều kiện của trình chạy kiểm thử đo lường.
testHandleProfiling Nếu bạn đặt thành true, hãy cho phép lớp đo lường bắt đầu và dừng phân tích.
Nếu bạn đặt thành false, quá trình phân tích sẽ diễn ra trong toàn bộ thời gian lớp đo lường chạy.
testFunctionalTest Nếu bạn đặt thành true, hãy chỉ ra rằng hệ thống Android sẽ chạy lớp đo lường dưới dạng một hoạt động kiểm thử chức năng.
Giá trị mặc định là false.

Thay đổi loại bản thử nghiệm

Theo mặc định, tất cả các hoạt động kiểm thử đo lường đều chạy cho loại bản dựng debug. Bạn có thể thay đổi loại bản dựng này sang một loại bản dựng khác bằng cách 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 hoạt động kiểm thử cho loại bản dựng staging, hãy chỉnh sửa tệp như hiển thị trong đoạn mã sau:

Groovy

android {
    ...
    testBuildType "staging"
}

Kotlin

android {
    ...
    testBuildType = "staging"
}

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

Trình bổ trợ Android cho Gradle cho phép bạn chỉ định các tuỳ chọn nhất định cho tất cả hoặc chỉ một số hoạt động 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 tuỳ chọn thay đổi cách Gradle chạy tất cả các hoạt động kiểm thử của bạn:

Groovy

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir "$rootDir/test-results"
    }
}

Kotlin

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

Thuộc tính reportDir thay đổi thư mục mà Gradle lưu báo cáo kiểm thử. Theo mặc định, Gradle sẽ lưu các báo cáo kiểm thử trong thư mục path_to_your_project/module_name /build/outputs/reports/. $rootDir đặt đường dẫn tương ứng với thư mục gốc của dự án hiện tại.

Thuộc tính resultsDir thay đổi thư mục mà Gradle lưu kết quả kiểm thử. Theo mặc định, Gradle sẽ lưu các kết quả kiểm thử trong thư mục path_to_your_project/module_name /build/outputs/test-results/. $rootDir đặt đường dẫn tương ứng với thư mục gốc của dự án hiện tại.

Để chỉ định các tuỳ chọn chỉ dành cho hoạt động 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 {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

Kotlin

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues = true

            all {
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                 if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

Theo mặc định, các hoạt động kiểm thử đơn vị cục bộ sẽ gửi một ngoại lệ bất cứ khi nào mã mà bạn đang kiểm thử cố gắng truy cập vào các API của nền tảng Android, trừ phi bạn tự mô phỏng các phần phụ thuộc Android hoặc thông qua khung kiểm thử như Mockito. Tuy nhiên, bạn có thể bật thuộc tính returnDefaultValues để hoạt động kiểm thử trả về giá trị rỗng hoặc 0 khi truy cập vào các API của nền tảng, thay vì gửi một ngoại lệ.

Khối all đóng gói các tuỳ chọn để kiểm soát cách Gradle thực thi các hoạt động kiểm thử đơn vị cục bộ. Để biết danh sách tất cả các tuỳ chọn mà bạn có thể chỉ định, hãy đọc Tài liệu tham khảo của Gradle.

Thuộc tính jvmArgs đặt (các) đối số JVM cho (các) JVM kiểm thử.

Bạn cũng có thể kiểm tra tên tác vụ để chỉ áp dụng các tuỳ chọn cho hoạt động kiểm thử mà bạn chỉ định. Trong đoạn mã mẫu, thuộc tính debug được đặt thành true nhưng chỉ dành cho tác vụ testDebugUnitTest.

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

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

Để tạo một 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. 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 nhóm tài nguyên của 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. Khi 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ẽ cố gắng kiểm thử phiên bản phù hợp trong mô-đun đích.

Theo mặc định, các mô-đun kiểm thử chỉ chứa và kiểm thử một biến thể gỡ lỗi. Tuy nhiên, bạn có thể tạo các loại bản dựng mới sao cho phù hợp với dự án ứng dụng được kiểm thử. Để mô-đun kiểm thử thực hiện hoạt động kiểm thử cho một loại bản dựng khác, chứ không phải cho loại bản dựng 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 bản dựng của một ứng dụng, thì 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ử. Điều này cũng ngăn việc mô-đun kiểm thử phải tự định cấu hình các biến thể đó.