Trong bài viết này, bạn sẽ tìm hiểu cách sử dụng API kiểm thử waitUntil trong Compose để chờ đáp ứng một số điều kiện. Đây là một lựa chọn thay thế tốt cho việc sử dụng Tài nguyên không đồng bộ trong một số trường hợp.

[Bản cập nhật năm 2023] Tóm lại: sử dụng các API waitUntil mới để đồng bộ hoá trong các kiểm thử Compose (phiên bản 1.4.0 trở lên).

Đồng bộ hoá là gì?

Một cách để phân loại các kiểm thử là theo phạm vi của chúng. Các kiểm thử nhỏ (hay kiểm thử đơn vị) tập trung vào các phần nhỏ của ứng dụng, trong khi các kiểm thử lớn (hay kiểm thử từ đầu đến cuối) bao gồm một phần lớn của ứng dụng. Bạn có thể đọc về loại kiểm thử này và các loại kiểm thử khác trong tài liệu kiểm thử mới được cập nhật.

Nhấn Enter hoặc nhấp để xem hình ảnh ở kích thước đầy đủ

Đồng bộ hoá là cơ chế cho phép kiểm thử biết thời điểm chạy thao tác tiếp theo. Phần mã bạn chọn để xác minh càng lớn thì càng khó đồng bộ hoá với kiểm thử. Trong các kiểm thử đơn vị, bạn có thể dễ dàng kiểm soát hoàn toàn việc thực thi mã để xác minh. Tuy nhiên, khi chúng ta mở rộng phạm vi để bao gồm nhiều lớp, mô-đun và lớp hơn, thì khung kiểm thử sẽ khó biết liệu ứng dụng có đang thực hiện một thao tác hay không.

Nhấn Enter hoặc nhấp để xem hình ảnh ở kích thước đầy đủ

androidx.test và theo đó là Kiểm thử Compose, sử dụng một số thủ thuật để bạn không phải lo lắng quá nhiều về vấn đề này. Ví dụ: nếu luồng chính đang bận, thì kiểm thử sẽ tạm dừng cho đến khi có thể thực thi dòng tiếp theo.

Tuy nhiên, chúng không thể biết mọi thứ. Ví dụ: nếu bạn tải dữ liệu trong một luồng nền, thì khung kiểm thử có thể thực thi thao tác tiếp theo quá sớm, khiến kiểm thử không thành công. Tình huống tệ nhất là khi điều này chỉ xảy ra trong một tỷ lệ nhỏ thời gian, khiến kiểm thử không ổn định.

Lựa chọn 1: Tài nguyên không đồng bộ

Tài nguyên không đồng bộ là một tính năng của Espresso cho phép bạn (nhà phát triển) quyết định thời điểm ứng dụng đang bận. Bạn có 2 cách để sử dụng các tài nguyên này:

1. Cài đặt các tài nguyên này trong khung hoặc thư viện đang thực hiện công việc mà kiểm thử không thể thấy.

Một ví dụ điển hình về điều này là RxIdler, gói trình lập lịch RxJava. Đây là cách ưu tiên để đăng ký Tài nguyên không đồng bộ vì cách này cho phép bạn tách biệt rõ ràng quá trình thiết lập kiểm thử khỏi mã kiểm thử.

2. Sửa đổi mã đang được kiểm thử để hiển thị rõ ràng thông tin về việc ứng dụng có đang bận hay không.

Ví dụ: bạn có thể sửa đổi kho lưu trữ (hoặc một kiểm thử kép) để cho biết đang bận trong khi tải dữ liệu từ một nguồn dữ liệu:

Cách này không lý tưởng vì bạn đang làm ô nhiễm mã sản xuất hoặc tạo các kiểm thử kép phức tạp, đồng thời có một số trường hợp khó cài đặt. Ví dụ: bạn sẽ sử dụng Tài nguyên không đồng bộ trong Flow của Kotlin như thế nào? Bản cập nhật nào là bản cập nhật cuối cùng?

Thay vào đó, chúng ta có thể chờ mọi thứ.

Lựa chọn 2: Chờ đợi mọi thứ… theo cách sai

Việc tải dữ liệu thường diễn ra nhanh chóng, đặc biệt là khi sử dụng dữ liệu giả. Vậy tại sao bạn lại lãng phí thời gian với các tài nguyên không đồng bộ khi chỉ cần cho kiểm thử ngủ trong vài giây?

Kiểm thử này sẽ chạy chậm hơn mức cần thiết hoặc không thành công. Khi có hàng trăm hoặc hàng nghìn kiểm thử giao diện người dùng, bạn muốn các kiểm thử diễn ra nhanh nhất có thể.

Ngoài ra, đôi khi trình mô phỏng hoặc thiết bị hoạt động sai và giật lag, khiến thao tác đó mất nhiều thời gian hơn 2000 mili giây, làm hỏng bản dựng của bạn. Khi bạn có hàng trăm kiểm thử, điều này sẽ trở thành một vấn đề lớn.

Lựa chọn 3: Chờ đợi mọi thứ theo cách đúng!

Nếu không muốn sửa đổi mã đang được kiểm thử để hiển thị thời điểm mã đang bận, thì bạn có thể chọn chờ cho đến khi đáp ứng một điều kiện nhất định, thay vì chờ một khoảng thời gian tuỳ ý.

Trong Compose, bạn có thể tận dụng hàm waitUntil, hàm này nhận một hàm khác tạo ra giá trị boolean.

Bản cập nhật ngày 22/03/2023: kể từ Compose 1.4.0, chúng tôi đã thêm một bộ API waitUntil mới:

[Trước phiên bản 1.4.0: Sử dụng các trình trợ giúp sau: waitUntilExists, waitUntilNodeCount]

…và sử dụng chúng như sau:

Chỉ sử dụng các API này khi bạn cần đồng bộ hoá kiểm thử với giao diện người dùng. Việc đồng bộ hoá trên mọi câu lệnh kiểm thử sẽ làm ô nhiễm mã kiểm thử một cách không cần thiết, khiến việc duy trì trở nên khó khăn hơn.

Vậy thì bạn nên sử dụng API này khi nào? Một trường hợp sử dụng tốt cho API này là tải dữ liệu từ một đối tượng có thể quan sát (với LiveData, Flow của Kotlin hoặc RxJava). Khi giao diện người dùng cần nhận nhiều bản cập nhật trước khi bạn coi giao diện đó là không đồng bộ, bạn có thể muốn đơn giản hoá quá trình đồng bộ hoá bằng cách sử dụng waitUntil.

Ví dụ: khi bạn thu thập một Flow từ một khung hiển thị:

Và bạn phát ra nhiều mục cho Flow đó:

Nếu repository mất một khoảng thời gian không xác định để trả về kết quả đầu tiên, thì khung kiểm thử sẽ cho rằng "Đang tải" là trạng thái không đồng bộ (giá trị ban đầu được gán trong collectAsState) và tiếp tục với câu lệnh tiếp theo.

Vì vậy, bạn có thể làm cho kiểm thử đáng tin cậy hơn nhiều nếu đảm bảo rằng giao diện người dùng không hiển thị chỉ báo tải:

Chúc bạn… chờ một chút… kiểm thử vui vẻ!

Giấy phép đoạn mã:

  Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0