Kiểm thử mã nền tảng bằng atest

Android Studio for Platform (ASfP) tích hợp với atest và các mô-đun kiểm thử Soong để bạn có thể chạy và gỡ lỗi các kiểm thử nền tảng trên máy chủ Linux, thiết bị thông minh đã kết nối hoặc thiết bị ảo Cuttlefish từ IDE.

Điều kiện tiên quyết

  • Mở một dự án ASfP được định cấu hình bằng đích lunch và quy trình kiểm tra AOSP.
  • Đối với các kiểm thử trên thiết bị, hãy kết nối một thiết bị thực hoặc khởi chạy một thiết bị ảo Cuttlefish đang chạy một bản dựng phù hợp.

Chạy và gỡ lỗi kiểm thử

Bạn có thể chạy các kiểm thử nền tảng và phiên gỡ lỗi ở một số nơi trong ASfP:

  • Android.bp mục tiêu kiểm thử: Mở một tệp Android.bp rồi nhấp vào Chạy trong phần lề bên cạnh bất kỳ mô-đun kiểm thử nào (*_test hoặc *_test_host):
    • Chạy: Dành cho tất cả các loại mô-đun kiểm thử Soong (android_test, java_test_host, cc_test, rust_test, python_test, sh_test và android_robolectric_test).
    • Gỡ lỗi: Dành cho các mô-đun android_test (được đính kèm với trình gỡ lỗi Java bằng atest --wait-for-debugger) và các mô-đun kiểm thử C++ hoặc Rust (cc_test, cc_test_host, rust_test và rust_test_host, được khởi chạy trong trình gỡ lỗi LLDB tích hợp của ASfP).
  • Biểu tượng rãnh tệp nguồn: Nhấp vào Run (Chạy) bên cạnh một lớp kiểm thử hoặc phương thức @Test trong mã nguồn để chạy hoặc gỡ lỗi kiểm thử cụ thể đó.
  • Trình đơn theo bối cảnh khi nhấp chuột phải: Nhấp chuột phải vào một tệp, lớp, phương thức kiểm thử hoặc mô-đun Android.bp rồi chọn Chạy hoặc Gỡ lỗi.
  • Tác nhân tích hợp (AI trong Android Studio): Trong cửa sổ công cụ Tác nhân, Tác nhân tích hợp có thể chạy các mục tiêu atest để xác minh các thay đổi sau khi chỉnh sửa mã.
  • Terminal tích hợp: Mở View > Tool Windows > Terminal (Xem > Cửa sổ công cụ > Dòng lệnh) để chạy trực tiếp các lệnh atest.

Gỡ lỗi và định cấu hình kiểm thử thông minh

Khi bạn chạy một kiểm thử từ lề hoặc trình đơn theo bối cảnh, ASfP sẽ tạo và định cấu hình một cấu hình chạy Soong Test (Kiểm thử Soong) bằng cách sử dụng biểu đồ mô-đun Android.bp.

Gỡ lỗi các mục tiêu android_test Java và Kotlin

Nhấp vào biểu tượng máng xối bên cạnh một mô-đun android_test trong Android.bp hoặc bên cạnh một lớp JUnit Java hoặc Kotlin hoặc phương thức @Test, rồi chọn Gỡ lỗi "<TestName>". Từ máng xối của tệp nguồn, ASfP sẽ chọn mô-đun android_test gần nhất có srcs bao gồm tệp và đặt tên cho cấu hình <module>, <module>:<SimpleClass> hoặc <module>:<SimpleClass>#<method>.

ASfP chạy atest với --wait-for-debugger, đọc thuộc tính đích package từ AndroidManifest.xml của mô-đun, đợi quá trình đó trên thiết bị thông minh đã kết nối và đính kèm trình gỡ lỗi Java.

Gỡ lỗi phương thức android_test từ rãnh của trình chỉnh sửa

Gỡ lỗi các mục tiêu cc_test và rust_test trong LLDB

Để gỡ lỗi mô-đun kiểm thử C++ hoặc Rust (cc_test, cc_test_host, rust_test hoặc rust_test_host), hãy nhấp vào biểu tượng máng xối Android.bp rồi chọn Gỡ lỗi "<TestName>". ASfP sẽ chạy tệp nhị phân kiểm thử đã biên dịch trong trình gỡ lỗi LLDB tích hợp sẵn thay vì chạy tệp nhị phân đó thông qua atest.

Định cấu hình cấu hình chạy thử nghiệm Soong

Mở Run > Edit Configurations (Chạy > Chỉnh sửa cấu hình) rồi chọn một cấu hình Soong Test (Kiểm thử Soong) để tuỳ chỉnh cách kiểm thử tạo, triển khai và khởi chạy:

  • Tính năng tự động hoàn thành mô-đun và điều hướng Android.bp: Trường Mô-đun tự động hoàn thành từ các mô-đun kiểm thử Soong được lập chỉ mục trong dự án của bạn. Nhấp vào Go to Android.bp (Chuyển đến Android.bp) bên cạnh trường để chuyển đến phần khai báo của mô-đun trong Android.bp.
  • Chạy trên: Thiết bị hoặc Máy chủ (bao gồm cả host_supported: true): ASfP đánh giá quy tắc mô-đun và chuỗi defaults bắc cầu của quy tắc đó (host_supported, device_supported, enabled, target.android.enabled và target.host.enabled):
    • Kiểm thử nhắm đến hai mục tiêu (cc_test và rust_test có host_supported: true): Cả nút chọn Thiết bị và Máy chủ lưu trữ đều có sẵn (mặc định là Thiết bị). Device (Thiết bị) và Host (Máy chủ lưu trữ) duy trì mẫu trình gỡ lỗi LLDB độc lập của riêng mình. Việc chuyển đổi Chạy trên giữa Thiết bị và Máy chủ lưu trữ sẽ hoán đổi giữa cấu hình lldb-server của thiết bị từ xa và cấu hình nhị phân của máy chủ lưu trữ cục bộ trong khi vẫn giữ nguyên các chế độ tuỳ chỉnh được thực hiện trên mỗi mục tiêu.
    • Thử nghiệm một mục tiêu: Nếu một thử nghiệm C++ hoặc Rust chỉ được tạo cho một môi trường (chẳng hạn như cc_test chỉ dành cho thiết bị hoặc cc_test_host hoặc rust_test_host chỉ dành cho máy chủ lưu trữ), thì ASfP sẽ chọn mục tiêu được hỗ trợ và tắt nút chọn không được hỗ trợ bằng một chú thích giải thích: "<module> (<ruleType>) doesn't build for the host or device."
  • Các tác vụ trước khi ra mắt (Tạo mô-đun kiểm thử gốc và Triển khai bằng atest): Theo mặc định, mọi cấu hình Soong Test đều có 2 tác vụ Trước khi ra mắt:
    • Build Native Test Module (Tạo mô-đun kiểm thử gốc): Tạo <module>-target (cho Thiết bị) hoặc <module>-host (cho Máy chủ lưu trữ) trước khi bắt đầu LLDB.
    • Triển khai bằng atest: Khi gỡ lỗi trên Thiết bị, hãy chạy atest <module> --collect-tests-only --disable-teardown -it -s <serial> -- --abi <abi> để Tradefed đẩy các phần phụ thuộc kiểm thử và thực thi các trình chuẩn bị mục tiêu trước khi LLDB khởi chạy tệp nhị phân. Giữ con trỏ trên khối Triển khai bằng atest để xem trước lệnh atest chính xác. Để có thể lặp lại nhanh hơn khi các phần phụ thuộc đã có trên thiết bị, hãy xoá Triển khai bằng atest để ASfP chỉ đẩy trực tiếp tệp nhị phân kiểm thử. Khi bạn chọn Run on: Host (Chạy trên: Máy chủ), ASfP sẽ tự động bỏ qua Deploy with atest (Triển khai bằng atest).
  • Sửa đổi các lựa chọn và Trình gỡ lỗi (thẻ lựa chọn LLDB): Sử dụng Sửa đổi các lựa chọn để thêm các trường cấu hình không bắt buộc:
    • Đối số chương trình (Hệ điều hành, chỉ kiểm thử C++ và Rust): Các đối số bổ sung được truyền trực tiếp đến tệp nhị phân cc_test hoặc rust_test sau bộ lọc --gtest_filter hoặc libtest khi gỡ lỗi.
    • đối số atest (Kiểm thử): Các cờ bổ sung được truyền đến atest khi chạy kiểm thử hoặc khi chuẩn bị thiết bị bằng Triển khai bằng atest.
    • Trình gỡ lỗi (Chỉ kiểm thử C++ và Rust): Xuất hiện khi Module (Mô-đun) là mục tiêu cc_test* hoặc rust_test*. Bật/tắt thẻ LLDB options (Các lựa chọn LLDB) (chẳng hạn như Stop on entry (Dừng khi nhập), Cache symbols across sessions (Lưu biểu tượng vào bộ nhớ đệm trên các phiên), Load symbols on demand (Tải biểu tượng theo yêu cầu) hoặc With Rust visualizers (Với trình trực quan hoá Rust) cho các kiểm thử Rust), nhấp vào Reset to defaults (Đặt lại về mặc định) để đặt lại mẫu Device (Thiết bị) hoặc Host (Máy chủ) đang hoạt động, hoặc thêm Symbol directories (Thư mục biểu tượng), Init, Pre-run, Post-run, or Exit commands (Lệnh Khởi động, Trước khi chạy, Sau khi chạy hoặc Thoát) và Launch JSON (Khởi chạy JSON) (DAP Settings (Cài đặt DAP)) từ Modify options > Debugger (Sửa đổi lựa chọn > Trình gỡ lỗi).

Cấu hình chạy Kiểm thử Soong cho thấy các tác vụ Trước khi khởi chạy, mục tiêu Thiết bị hoặc Máy chủ lưu trữ và các lựa chọn LLDB

Xem kết quả thử nghiệm

Tiến trình phiên chạy thử nghiệm, trạng thái thành công hoặc thất bại, dấu vết ngăn xếp và nhật ký thiết bị xuất hiện theo thời gian thực trong cửa sổ công cụ Run (Chạy) hoặc Debug (Gỡ lỗi) trong ASfP.

Mẹo thử nghiệm

  • Chạy các kiểm thử có mục tiêu: Kiểm thử các phương thức riêng lẻ từ phần định hướng của trình chỉnh sửa mà không cần chạy toàn bộ bộ kiểm thử.
  • Sử dụng ảnh chụp nhanh Cuttlefish: Khi chạy kiểm thử thiết bị trên thiết bị ảo Cuttlefish, hãy sử dụng ảnh chụp nhanh để khôi phục trạng thái thiết bị sạch giữa các lần chạy.
  • Kiểm tra nhật ký bản dựng Soong: Nếu một kiểm thử không biên dịch được trước khi chạy, hãy kiểm tra cửa sổ công cụ Soong để biết thông tin chẩn đoán của trình biên dịch.