หากคุณเพิ่งเริ่มพัฒนาแพลตฟอร์ม Android คุณอาจพบว่าตัวอย่างที่สมบูรณ์นี้ ในการเพิ่มไบนารี GTest ใหม่ (บางครั้งเรียกว่าการทดสอบ "เนทีฟ" ด้วย) ตั้งแต่ต้นมีประโยชน์ในการสาธิตเวิร์กโฟลว์ทั่วไปที่เกี่ยวข้อง ดูข้อมูลเพิ่มเติมเกี่ยวกับเฟรมเวิร์ก GTest สำหรับ C++ ได้ที่เว็บไซต์โปรเจ็กต์ GTest เพื่อดูเอกสารประกอบเพิ่มเติม
คู่มือนี้ใช้ Hello World GTest เป็นตัวอย่าง เราขอแนะนำให้อ่านโค้ดเพื่อให้เข้าใจคร่าวๆ ก่อนที่จะดำเนินการต่อ
กำหนดตำแหน่งต้นทาง
โดยปกติแล้ว ทีมของคุณจะมีรูปแบบที่กำหนดไว้แล้วสำหรับตำแหน่งที่จะเช็คอินโค้ดและตำแหน่งที่จะเพิ่มการทดสอบ ทีมส่วนใหญ่เป็นเจ้าของที่เก็บ 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
| \-- ...
\-- ...
ไม่ว่าโครงสร้างจะเป็นอย่างไร คุณจะต้องป้อนข้อมูลในไดเรกทอรี tests หรือ
ไดเรกทอรีย่อยที่สร้างขึ้นใหม่ด้วยไฟล์ที่คล้ายกับไฟล์ในไดเรกทอรี native
ในการเปลี่ยนแปลง Gerrit ตัวอย่าง ส่วนด้านล่างจะอธิบายรายละเอียดเพิ่มเติมเกี่ยวกับไฟล์แต่ละไฟล์
ซอร์สโค้ด
ดูตัวอย่างได้ที่ Hello World GTest
โค้ดแหล่งที่มาของตัวอย่างดังกล่าวมีคำอธิบายประกอบที่นี่
#include <gtest/gtest.h>
ไฟล์ส่วนหัวสำหรับ GTest ระบบจะแก้ไขทรัพยากร Dependency ของไฟล์ที่รวมโดยอัตโนมัติ
โดยใช้ 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
สำหรับกรณีที่ซับซ้อนมากขึ้นซึ่งต้องมีการปรับแต่งที่หนักกว่า ให้ทำตามวิธีการติดตั้งเครื่องมือ