Nếu mới phát triển nền tảng Android, bạn có thể thấy ví dụ đầy đủ 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 được gọi là kiểm thử "gốc") từ đầu là hữu ích để minh hoạ quy trình làm việc điển hình liên quan. Để 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 Hello World GTest làm ví dụ. Bạn nên đọc qua mã để hiểu sơ bộ về mã đó 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 các vị trí cần kiểm tra trong mã và các vị trí cần thêm kiểm thử. Hầu hết các nhóm đều sở hữu một kho lưu trữ git duy nhất 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 chuyên dụ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ó thư mục src và tests trong đó, 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ì đang thêm một 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 thành phần src 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 trong tests do cần đóng gói các bộ 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 trong tests.
Để minh hoạ, sau đây là một cấu trúc thư mục điển hình cho các thành phần có một thư mục tests duy nhất:
\
<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à một cấu trúc 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ẽ kết thúc việc điền vào thư mục tests hoặc thư mục con mới tạo bằng các tệp tương tự như trong thư mục native trong thay đổi mẫu của gerrit. Các phần dưới đây sẽ giải thích chi tiết hơn về từng tệp.
Mã nguồn
Hãy tham khảo Hello World GTest để xem ví dụ.
Mã nguồn cho ví dụ đó được chú thích ở đây:
#include <gtest/gtest.h>
Tệp tiêu đề bao gồm cho GTest. Phần phụ thuộc của tệp include sẽ tự động được phân giải 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 kiểm thử. Cùng với tên nhị phân kiểm thử, chúng tạo thành hệ thống phân cấp sau đây 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 các bài 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 bản dựng bằng siêu dữ liệu mô-đun, các phần phụ thuộc tại thời gian biên dịch và hướng dẫn đóng gói. Trong hầu hết các trường hợp, lựa 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, hãy viết mộ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 lựa chọn thiết lập thiết bị đặc biệt và các đố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 những trường hợp phức tạp hơn đòi hỏi mức độ tuỳ chỉnh cao hơn, hãy làm theo hướng dẫn về việc đo lường.