Thêm GoogleTests (GTests) mới

Nếu mới làm quen với việc phát triển nền tảng Android, bạn có thể tìm thấy ví dụ về cách thêm một tệp nhị phân GTest hoàn toàn mới (đôi khi cũng được gọi là tệp "gốc" thử nghiệm) từ đầu, hữu ích để minh hoạ quy trình làm việc điển hình có liên quan. Để thông tin bổ sung về khung GTest cho C++, hãy tham khảo dự án GTest trang web để 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ã này để nắm rõ 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 thiết lập về các địa điểm để kiểm tra trong mã và vị trí để thêm bài 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ẻ tệp với các nhóm khác nhưng có thư mục con riêng chứa mã nguồn thành phần.

Giả sử vị trí gốc của nguồn thành phần là tại <component source root>, thì hầu hết các thành phần đều có thư mục srctests bên dưới, và một số các tệp bổ sung như Android.mk (hoặc được chia thành .bp bổ sung ).

Do đang thêm một thử nghiệm hoàn toàn mới, nên có thể bạn sẽ cần phải 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 nhu cầu phải đóng gói nhiều bộ thử nghiệm thành 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 bản phác thảo 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à sau đây là bản phác thảo thư mục thông thường 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 là gì, bạn đều sẽ điền thư mục tests hoặc thư mục con mới tạo có các tệp tương tự như trong native trong thư mục thay đổi gerrit mẫu. Các phần dưới đây sẽ giải thích trong thêm thông tin chi tiết về từng tệp.

Mã nguồn

Tham khảo Hello World GTest để xem ví dụ.

Mã nguồn cho ví dụ đó được chú thích tại đây:

#include <gtest/gtest.h>

Tệp tiêu đề có chứa GTest. Phần phụ thuộc tệp "include" được tự động thêm vào được giải quyết bằng BUILD_NATIVE_TEST trong tệp makefile.

#include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}

Các GTest được viết bằng macro TEST: tham số đầu tiên là trường hợp kiểm thử và thứ hai là tên thử nghiệm. 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 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 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 để chuyển hướng hệ thống xây dựng với siêu dữ liệu mô-đun, phần phụ thuộc thời gian biên dịch và đóng gói hướng dẫn. Trong hầu hết các trường hợp, tuỳ chọn tệp Blueprint, dựa trên Soong là đủ. Xem phần Cấu hình kiểm thử đơn giản để biết chi tiết.

Tệp cấu hình phức tạp

Thay vào đó, để 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 tuỳ chọn thiết lập thiết bị đặc biệt và để cung cấp lớp kiểm thử.

Tạo bản 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 Cuộc thi.

Đối với các trường hợp phức tạp hơn đòi hỏi phải tuỳ chỉnh nhiều hơn, hãy làm theo hướng dẫn đo lường.