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:
- 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).
- 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).
- Đố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
. - Nhấp vào OK.
- Nhấp chuột phải vào thư mục mới rồi chọn New > Directory (Mới > Thư mục).
- 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](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-android-view.png?authuser=9&hl=vi)
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](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-android-view.png?authuser=9&hl=vi)
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)](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-project-view.png?authuser=9&hl=vi)
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](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-project-view.png?authuser=9&hl=vi)
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 } }
Each product flavor you configure can override properties in the
defaultConfig {}
block. To learn more, go to Configure product
flavors.
The properties in the snippet are:
Setting | Description |
---|---|
testApplicationId
|
Specifies the application ID for the test APK. |
testInstrumentationRunner
|
Specifies the fully qualified class name of the test instrumentation runner. |
testHandleProfiling
|
If set to true , enables the instrumentation class
to start and stop profiling.If set to false , profiling occurs the entire time
the instrumentation class is running. |
testFunctionalTest
|
If set to true , indicates that the Android system
should run the instrumentation class as a functional
test.The default value is false . |
Change the test build type
By default, all instrumentation tests run against the debug
build type.
You can change this to another build type by using the testBuildType
property in your module-level build.gradle
file. For example, if you want
to run your tests against your staging
build type, edit the file as
shown in the following snippet:
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:
- Tạo mô-đun thư viện.
- Trong tệp
build.gradle
ở cấp mô-đun, sử dụng trình bổ trợcom.android.test
thay vìcom.android.library
. - 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ể đó.