หากคุณเพิ่งเริ่มพัฒนาแพลตฟอร์ม Android ตัวอย่างที่สมบูรณ์นี้เกี่ยวกับการเพิ่มไบนารี GTest ใหม่ (บางครั้งเรียกว่าการทดสอบ "เนทีฟ") ตั้งแต่เริ่มต้นอาจเป็นประโยชน์ในการแสดงเวิร์กโฟลว์ทั่วไปที่เกี่ยวข้อง ดูข้อมูลเพิ่มเติมเกี่ยวกับเฟรมเวิร์ก GTest สำหรับ C++ ได้ที่ เว็บไซต์โปรเจ็กต์ GTest สำหรับเอกสารประกอบเพิ่มเติม
คู่มือนี้ใช้ GTest Hello World เป็นตัวอย่าง เราขอแนะนำให้อ่านโค้ดเพื่อทำความเข้าใจคร่าวๆ ก่อนดำเนินการต่อ
เลือกตำแหน่งต้นทาง
โดยปกติแล้วทีมของคุณจะมีรูปแบบที่กำหนดไว้แล้วสำหรับตำแหน่งที่จะเช็กอินโค้ดและตำแหน่งที่จะเพิ่มการทดสอบ ทีมส่วนใหญ่เป็นเจ้าของที่เก็บ Git เดียวหรือแชร์ที่เก็บกับทีมอื่นๆ แต่มีไดเรกทอรีย่อยเฉพาะที่มีซอร์สโค้ดของคอมโพเนนต์
สมมติว่าตำแหน่งรูทสำหรับซอร์สของคอมโพเนนต์อยู่ที่ <component source
root> คอมโพเนนต์ส่วนใหญ่จะมีโฟลเดอร์ src และ tests อยู่ใต้ตำแหน่งดังกล่าว รวมถึงไฟล์เพิ่มเติมบางไฟล์ เช่น Android.mk (หรือแยกออกเป็นไฟล์ .bp เพิ่มเติม)
เนื่องจากคุณกำลังเพิ่มการทดสอบใหม่ คุณอาจต้องสร้างไดเรกทอรี tests ข้าง src ของคอมโพเนนต์และใส่เนื้อหาลงในไดเรกทอรีดังกล่าว
ในบางกรณี ทีมของคุณอาจมีโครงสร้างไดเรกทอรีเพิ่มเติมภายใต้ tests เนื่องจากต้องแพ็กเกจชุดการทดสอบต่างๆ ลงในไบนารีแต่ละรายการ
และในกรณีนี้ คุณจะต้องสร้างไดเรกทอรีย่อยใหม่ภายใต้ tests
ตัวอย่างเช่น นี่คือโครงร่างไดเรกทอรีทั่วไปสำหรับคอมโพเนนต์ที่มีโฟลเดอร์ 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
\-- ...
และนี่คือโครงร่างไดเรกทอรีทั่วไปสำหรับคอมโพเนนต์ที่มีไดเรกทอรีซอร์สของการทดสอบหลายรายการ
\
<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
| \-- ...
\-- ...
ไม่ว่าโครงสร้างจะเป็นอย่างไร คุณจะต้องใส่ไฟล์ที่คล้ายกับไฟล์ในไดเรกทอรี native ในการเปลี่ยนแปลง Gerrit ตัวอย่างลงในไดเรกทอรี tests หรือไดเรกทอรีย่อยที่สร้างขึ้นใหม่ ส่วนด้านล่างจะอธิบายรายละเอียดเพิ่มเติมของแต่ละไฟล์
ซอร์สโค้ด
ดูตัวอย่างได้ที่ GTest Hello World
ซอร์สโค้ดสำหรับตัวอย่างดังกล่าวมีคำอธิบายประกอบดังนี้
#include <gtest/gtest.h>
การรวมไฟล์ส่วนหัวสำหรับ GTest ระบบจะแก้ปัญหาการขึ้นอยู่กับไฟล์รวมโดยอัตโนมัติโดยใช้ BUILD_NATIVE_TEST ใน Makefile
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTest เขียนขึ้นโดยใช้มาโคร TEST โดยพารามิเตอร์แรกคือชื่อกรณีทดสอบ และพารามิเตอร์ที่ 2 คือชื่อการทดสอบ เมื่อรวมกับชื่อไบนารีของการทดสอบแล้ว ชื่อเหล่านี้จะสร้างลำดับชั้นต่อไปนี้ในแดชบอร์ดผลลัพธ์
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
ดูข้อมูลเพิ่มเติมเกี่ยวกับการเขียนการทดสอบด้วย GTest ได้ที่ เอกสารประกอบของ GTest
ไฟล์การกำหนดค่าอย่างง่าย
โมดูลการทดสอบใหม่แต่ละโมดูลต้องมีไฟล์การกำหนดค่าเพื่อสั่งให้ระบบบิลด์ใช้ข้อมูลเมตาของโมดูล การขึ้นอยู่กับเวลาคอมไพล์ และวิธีการแพ็กเกจ ในกรณีส่วนใหญ่ ตัวเลือกไฟล์ Blueprint ที่อิงตาม Soong ก็เพียงพอแล้ว ดูรายละเอียดได้ที่การกำหนดค่าการทดสอบอย่างง่าย
ไฟล์การกำหนดค่าที่ซับซ้อน
หากต้องการใช้ Trade Federation แทน ให้เขียนไฟล์การกำหนดค่าการทดสอบ สำหรับชุดทดสอบของ Android ซึ่งก็คือ Trade Federation
การกำหนดค่าการทดสอบสามารถระบุตัวเลือกการตั้งค่าอุปกรณ์พิเศษและอาร์กิวเมนต์เริ่มต้นเพื่อส่งไปยังคลาสการทดสอบ
สร้างและทดสอบในเครื่อง
สำหรับกรณีการใช้งานที่พบบ่อยที่สุด ให้ใช้ Atest
สำหรับกรณีที่ซับซ้อนมากขึ้นซึ่งต้องมีการปรับแต่งที่ละเอียดขึ้น ให้ทำตาม วิธีการใช้เครื่องมือวัดประสิทธิภาพ