หากคุณเพิ่งเริ่มพัฒนาแพลตฟอร์ม 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 ระบบจะแก้ไขการพึ่งพาไฟล์รวมโดยอัตโนมัติโดยใช้ BUILD_NATIVE_TEST ในไฟล์ make
#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 แทน ให้เขียนไฟล์การกำหนดค่าการทดสอบสำหรับ Trade Federation ซึ่งเป็นชุดทดสอบของ Android
การกําหนดค่าการทดสอบสามารถระบุตัวเลือกการตั้งค่าอุปกรณ์พิเศษและอาร์กิวเมนต์เริ่มต้นเพื่อระบุคลาสการทดสอบ
สร้างและทดสอบในเครื่อง
สําหรับ Use Case ที่พบบ่อยที่สุด ให้ใช้ Atest
สําหรับกรณีที่ซับซ้อนมากขึ้นซึ่งต้องมีการปรับแต่งมากขึ้น ให้ทําตามวิธีการเครื่องมือวัด