หากคุณยังใหม่ต่อการพัฒนาแพลตฟอร์ม 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
ใน makefile
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTests ถูกเขียนโดยใช้มาโคร TEST
: พารามิเตอร์แรกคือชื่อกรณีการทดสอบ และพารามิเตอร์ที่สองคือชื่อการทดสอบ นอกจากชื่อไบนารีทดสอบแล้ว ยังสร้างลำดับชั้นต่อไปนี้ในแดชบอร์ดผลลัพธ์:
<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
สำหรับกรณีที่ซับซ้อนมากขึ้นซึ่งต้องมีการปรับแต่งที่หนักกว่า ให้ทำตาม คำแนะนำเกี่ยวกับเครื่องมือวัด