Các lựa chọn thay thế cho Tài nguyên không đồng bộ trong các kiểm thử Compose: API waitUntil (đã cập nhật)

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 nhất định. Đây là một giải pháp thay thế hiệu quả cho việc sử dụng Tài nguyên ở trạng thái rảnh trong một số trường hợp.

[Nội dung cập nhật năm 2023] Tóm tắt: sử dụng 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 bài kiểm thử nhỏ (hay kiểm thử đơn vị) tập trung vào các phần nhỏ trong ứng dụng của bạn, trong khi các bài kiểm thử lớn (hay kiểm thử từ đầu đến cuối) bao gồm một phần lớn trong ứng dụng của bạn. 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ập nhật.

Nhấn phím 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. Bạn chọn xác minh đoạn mã càng lớn thì càng khó đồng bộ hoá với kiểm thử. Trong các bài kiểm thử đơn vị, bạn có thể dễ dàng kiểm soát hoàn toàn quá trình thực thi mã để xác minh. Tuy nhiên, khi chúng ta mở rộng phạm vi để đưa thêm nhiều lớp, mô-đun và lớp, khung kiểm thử sẽ khó biết liệu ứng dụng có đang trong quá trình hoạt động hay không.

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

androidx.test và Compose Test (theo cách mở rộng) 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, họ không thể biết mọi thứ. Ví dụ: nếu bạn tải dữ liệu trong một luồng ở chế độ nền, khung kiểm thử có thể thực thi thao tác tiếp theo quá sớm, khiến kiểm thử của bạn 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 thử nghiệm trở nên không ổn định.

Lựa chọn 1: Tài nguyên rảnh

Idling Resources 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ó thể sử dụng các chỉ số này theo hai cách:

1. Cài đặt các thành phầ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 một trình lập lịch RxJava. Đây là cách nên dùng để đăng ký Tài nguyên không hoạt động vì cách này giúp bạn tách biệt rõ ràng chế độ 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õ thông tin về việc ứng dụng của bạn có đang bận hay không.

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

Điều này không lý tưởng vì bạn đang làm hỏng mã sản xuất hoặc tạo các đối tượng kiểm thử phức tạp và có một số trường hợp khó cài đặt. Ví dụ: làm cách nào để sử dụng Tài nguyên ở trạng thái rảnh trong Luồng Kotlin? Bản cập nhật nào là bản cuối cùng?

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

Cách 2: Chờ đợi mọi thứ… theo cách sai lầm

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 hoạt động khi bạn có thể chỉ cần để kiểm thử ở trạng thái ngủ trong vài giây?

Thử nghiệm 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 không đúng cách và bị giật, 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 bài kiểm thử, đây sẽ là một vấn đề lớn.

Cách 3: Chờ đợi đúng cách!

Nếu không muốn sửa đổi mã đang được kiểm thử để cho biết thời điểm mã đang bận, bạn có thể đợi cho đến khi một điều kiện nhất định được đáp ứng thay vì đợi 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.

Nội dung cập nhật ngày 22/3/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 đối tượng hỗ trợ này: 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á bài 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 tính năng này khi nào? Một trường hợp sử dụng phù hợp cho việc này là tải dữ liệu từ một đối tượng có thể quan sát (với LiveData, Kotlin Flow hoặc RxJava). Khi giao diện người dùng cần nhận nhiều nội dung cập nhật trước khi bạn coi giao diện đó ở trạng thái rảnh, 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 nhiều mục cho nó:

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ẽ coi "Đang tải" là trạng thái rảnh (giá trị ban đầu được chỉ định trong collectAsState) và tiếp tục với câu lệnh tiếp theo.

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

Chúc bạn… đợi đã… kiểm thử vui vẻ!

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

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