Khi kiểm thử một phần tử hoặc hệ thống các phần tử, bạn sẽ kiểm thử riêng biệt. Ví dụ: để kiểm thử ViewModel, bạn không cần khởi động trình mô phỏng và chạy giao diện người dùng vì ViewModel không (hoặc không nên) phụ thuộc vào khung Android.
Tuy nhiên, đối tượng đang được kiểm thử có thể phụ thuộc vào các đối tượng khác để hoạt động. Ví dụ: ViewModel có thể phụ thuộc vào kho lưu trữ dữ liệu để hoạt động.
Khi cần cung cấp phần phụ thuộc cho một đối tượng kiểm thử, bạn thường tạo một đối tượng kiểm thử kép (hoặc đối tượng kiểm thử). Đối tượng kiểm thử kép là các đối tượng trông giống và hoạt động như các thành phần trong ứng dụng của bạn, nhưng được tạo trong kiểm thử để cung cấp một hành vi hoặc dữ liệu cụ thể. Ưu điểm chính là các hàm này giúp bạn kiểm thử nhanh hơn và đơn giản hơn.
Các loại đối tượng kiểm thử kép
Có nhiều loại đối tượng kiểm thử kép:
| Giả mạo | Một kiểm thử đôi có cách triển khai lớp "đang hoạt động", nhưng được triển khai theo cách phù hợp với kiểm thử nhưng không phù hợp với hoạt động sản xuất.
Ví dụ: cơ sở dữ liệu trong bộ nhớ. Các đối tượng giả không yêu cầu khung mô phỏng và có kích thước nhỏ. Đây là các giá trị ưu tiên. |
|---|---|
| Mô phỏng | Một đối tượng kiểm thử kép hoạt động theo cách bạn lập trình và có những kỳ vọng về hoạt động tương tác của đối tượng đó. Mô phỏng sẽ không vượt qua được kiểm thử nếu hoạt động tương tác của mô phỏng không khớp với các yêu cầu mà bạn xác định. Mô phỏng thường được tạo bằng khung mô phỏng để đạt được tất cả những điều này.
Ví dụ: Xác minh rằng một phương thức trong cơ sở dữ liệu đã được gọi đúng một lần. |
| Mục thay thế tạm thời | Một bản sao kiểm thử hoạt động theo cách bạn lập trình nhưng không có kỳ vọng về các hoạt động tương tác của bản sao đó. Thường được tạo bằng khung mô phỏng. Bạn nên ưu tiên sử dụng dữ liệu giả hơn là dữ liệu giả lập để đơn giản hoá. |
| Dummy | Một bản sao kiểm thử được truyền xung quanh nhưng không được sử dụng, chẳng hạn như nếu bạn chỉ cần cung cấp bản sao đó dưới dạng tham số.
Ví dụ: một hàm trống được truyền dưới dạng lệnh gọi lại khi nhấp. |
| Gián điệp | Một trình bao bọc trên một đối tượng thực cũng theo dõi một số thông tin bổ sung, tương tự như mô phỏng. Chúng thường được tránh để tránh làm tăng độ phức tạp. Do đó, bạn nên ưu tiên sử dụng các lớp giả hoặc mô phỏng hơn là các lớp gián điệp. |
| Shadow | Giả mạo được sử dụng trong Robolectric. |
Ví dụ về việc sử dụng một tệp giả mạo
Giả sử bạn muốn kiểm thử đơn vị một ViewModel phụ thuộc vào một giao diện có tên là UserRepository và hiển thị tên của người dùng đầu tiên cho giao diện người dùng. Bạn có thể tạo một bản sao kiểm thử giả bằng cách triển khai giao diện và trả về dữ liệu đã biết.
object FakeUserRepository : UserRepository {
fun getUsers() = listOf(UserAlice, UserBob)
}
val const UserAlice = User("Alice")
val const UserBob = User("Bob")
UserRepository giả này không cần phụ thuộc vào các nguồn dữ liệu cục bộ và từ xa mà phiên bản chính thức sẽ sử dụng. Tệp này nằm trong nhóm tài nguyên kiểm thử và sẽ không được vận chuyển cùng với ứng dụng chính thức.
Kiểm thử sau đây xác minh rằng ViewModel hiển thị chính xác tên người dùng đầu tiên cho thành phần hiển thị.
@Test
fun viewModelA_loadsUsers_showsFirstUser() {
// Given a VM using fake data
val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init
// Verify that the exposed data is correct
assertEquals(viewModel.firstUserName, UserAlice.name)
}
Việc thay thế UserRepository bằng một giá trị giả rất dễ dàng trong kiểm thử đơn vị, vì ViewModel do người kiểm thử tạo. Tuy nhiên, có thể khó thay thế các phần tử tuỳ ý trong các kiểm thử lớn hơn.
Thay thế thành phần và chèn phần phụ thuộc
Khi các chương trình kiểm thử không có quyền kiểm soát việc tạo hệ thống đang được kiểm thử, việc thay thế các thành phần cho kiểm thử kép sẽ trở nên phức tạp hơn và yêu cầu cấu trúc của ứng dụng phải tuân theo thiết kế có thể kiểm thử.
Ngay cả các kiểm thử toàn diện lớn cũng có thể hưởng lợi từ việc sử dụng đối tượng kiểm thử kép, chẳng hạn như kiểm thử giao diện người dùng được đo lường giúp điều hướng qua toàn bộ luồng người dùng trong ứng dụng. Trong trường hợp đó, bạn nên kiểm thử khép kín. Kiểm thử kín tránh tất cả các phần phụ thuộc bên ngoài, chẳng hạn như tìm nạp dữ liệu từ Internet. Điều này giúp cải thiện độ tin cậy và hiệu suất.
Bạn có thể thiết kế ứng dụng để đạt được sự linh hoạt này theo cách thủ công, nhưng bạn nên sử dụng khung chèn phần phụ thuộc như Hilt để thay thế các thành phần trong ứng dụng tại thời điểm kiểm thử. Hãy xem hướng dẫn kiểm thử Hilt.
Các bước tiếp theo
Trang Chiến lược kiểm thử cho biết cách bạn có thể cải thiện năng suất bằng nhiều loại kiểm thử.