Nếu bạn mới phát triển nền tảng Android, bạn có thể thấy ví dụ hoàn chỉnh này về cách thêm một tệp nhị phân GTest hoàn toàn mới (đôi khi còn gọi là kiểm thử "gốc") từ đầu rất hữu ích để minh hoạ quy trình làm việc điển hình. Để biết thêm thông tin về khung GTest cho C++, hãy tham khảo trang web dự án GTest để xem thêm tài liệu.
Hướng dẫn này sử dụng GTest Hello World làm ví dụ. Bạn nên đọc kỹ đoạn mã để hiểu sơ bộ trước khi tiếp tục.
Quyết định vị trí nguồn
Thông thường, nhóm của bạn sẽ có sẵn một mẫu vị trí để kiểm tra mã và vị trí để thêm quy trình kiểm thử. Hầu hết các nhóm đều sở hữu một kho lưu trữ git hoặc chia sẻ một kho lưu trữ với các nhóm khác nhưng có một thư mục con riêng chứa mã nguồn thành phần.
Giả sử vị trí gốc cho nguồn thành phần của bạn là <component source
root>, hầu hết các thành phần đều có src và tests thư mục bên dưới, cũng như một số
tệp bổ sung như Android.mk (hoặc được chia thành các tệp .bp
bổ sung).
Vì bạn đang thêm một quy trình kiểm thử hoàn toàn mới, nên có thể bạn sẽ cần tạo thư mục tests bên cạnh src thành phần và điền nội dung vào thư mục đó.
Trong một số trường hợp, nhóm của bạn có thể có thêm cấu trúc thư mục bên dưới tests do cần đóng gói các bộ quy trình kiểm thử khác nhau vào các tệp nhị phân riêng lẻ.
Trong trường hợp này, bạn cần tạo một thư mục con mới bên dưới tests.
Để minh hoạ, sau đây là sơ đồ thư mục điển hình cho các thành phần có một thư mục tests:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- src (test source)
\-- foo_test.cpp
\-- ...
và đây là sơ đồ thư mục điển hình cho các thành phần có nhiều thư mục nguồn kiểm thử:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- testFoo (sub test source root)
| \-- Android.bp (sub test makefile)
| \-- src (sub test source)
| \-- test_foo.cpp
| \-- ...
\-- testBar
| \-- Android.bp
| \-- src
| \-- test_bar.cpp
| \-- ...
\-- ...
Bất kể cấu trúc nào, bạn sẽ điền tệp vào thư mục tests hoặc thư mục con mới tạo tương tự như trong thư mục native trong thay đổi gerrit mẫu. Các phần bên dưới sẽ giải thích chi tiết hơn về từng tệp.
Mã nguồn
Hãy tham khảo GTest Hello World để xem ví dụ.
Mã nguồn cho ví dụ đó được chú thích ở đây:
#include <gtest/gtest.h>
Bao gồm tệp tiêu đề cho GTest. Phần phụ thuộc tệp bao gồm sẽ tự động được giải quyết bằng cách sử dụng BUILD_NATIVE_TEST trong tệp makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTest được viết bằng cách sử dụng macro TEST: tham số đầu tiên là tên trường hợp kiểm thử và tham số thứ hai là tên quy trình kiểm thử. Cùng với tên tệp nhị phân kiểm thử, chúng tạo thành hệ phân cấp sau trong trang tổng quan kết quả:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
Để biết thêm thông tin về cách viết quy trình kiểm thử bằng GTest, hãy tham khảo tài liệu về GTest
Tệp cấu hình đơn giản
Mỗi mô-đun kiểm thử mới phải có một tệp cấu hình để hướng dẫn hệ thống xây dựng bằng siêu dữ liệu mô-đun, phần phụ thuộc tại thời điểm biên dịch và hướng dẫn đóng gói. Trong hầu hết các trường hợp, tuỳ chọn tệp Blueprint dựa trên Soong là đủ. Hãy xem phần Cấu hình kiểm thử đơn giản để biết thông tin chi tiết.
Tệp cấu hình phức tạp
Để sử dụng Trade Federation thay vì vậy, hãy viết tệp cấu hình kiểm thử cho bộ kiểm thử của Android, Trade Federation.
Cấu hình kiểm thử có thể chỉ định các tuỳ chọn thiết lập thiết bị đặc biệt và đối số mặc định để cung cấp cho lớp kiểm thử.
Xây dựng và kiểm thử cục bộ
Đối với các trường hợp sử dụng phổ biến nhất, hãy sử dụng Atest.
Đối với các trường hợp phức tạp hơn đòi hỏi khả năng tuỳ chỉnh cao hơn, hãy làm theo hướng dẫn về đo lường.