เส้นทาง 02บทเรียน 3 / 6

ใช้ test เป็นหลักฐาน

เลือกการตรวจสอบที่ปฏิเสธพฤติกรรมผิดได้ ตรวจทาน test ที่สร้างขึ้นอย่างรอบคอบเท่ากับโค้ดที่สร้างขึ้น

ผู้ปฏิบัติงาน11 minตรวจทานแล้ว 5 ต.ค. 2569

เผยแพร่โดย Taigaวิธีเขียนเนื้อหาของเรา

ตรวจความเข้าใจTest ที่สร้างขึ้น mock ฟังก์ชันตรวจสอบสิทธิ์ให้อนุญาตเสมอ ผลที่ผ่านพิสูจน์อะไรทำแบบฝึกหัด

แสดงคำตอบ

สิ่งนี้มีประโยชน์สำหรับ test ขอบเขตแคบได้ เพิ่มหลักฐานแยกสำหรับการตรวจสอบสิทธิ์จริงและคำขอที่ต้องห้าม

สิ่งที่จะได้เรียนรู้

เชื่อมข้อกำหนดสำคัญแต่ละข้อกับการตรวจสอบที่มีความหมาย
แยกหลักฐานจาก unit test, integration test และ end-to-end test
ตรวจพบ test ที่ใช้สมมติฐานผิดเดียวกับโค้ดที่พัฒนา

เริ่มจากข้อกำหนด

Test เป็นหลักฐานสำหรับข้อกล่าวอ้างที่เจาะจง การรัน test สำเร็จไม่ได้พิสูจน์ทุกคุณสมบัติของซอฟต์แวร์ ก่อนขอให้เขียน test ให้ระบุพฤติกรรมที่สำคัญและข้อบกพร่องที่การตรวจสอบแต่ละข้อควรตรวจพบ

ในตัวอย่างสมมติของการ export ข้อมูลองค์กร ข้อกำหนดหลักคือการแยกข้อมูล ผู้ใช้ในองค์กร A ต้องไม่ได้รับระเบียนจากองค์กร B Test ที่ตรวจเพียงว่าดาวน์โหลดสำเร็จไม่ได้พิสูจน์ข้อกำหนดนี้

ขอให้ agent อธิบายความสัมพันธ์ระหว่างข้อกำหนดกับ assertion วิธีนี้ทำให้พบกรณีที่ขาดง่ายขึ้น ก่อนชุด test จะใหญ่

เลือกขอบเขต test ที่เหมาะสม

Unit test ตรวจสอบการแปลงข้อมูลเล็ก ๆ ได้เร็ว Integration test ตรวจสอบว่าคอมโพเนนต์ทำงานร่วมกันอย่างไร End-to-end test ตรวจสอบลำดับการใช้งานสำคัญผ่านแอปที่ deploy แล้วหรือแอปที่เป็นตัวแทนได้

ใช้ขอบเขตแคบที่สุดที่ให้หลักฐานตามต้องการ เครื่องมือจัดรูปแบบไม่จำเป็นต้องมี browser test เต็มรูปแบบสำหรับทุก input ขอบเขตสิทธิ์อาจต้องใช้ route จริงและเส้นทางเข้าถึงข้อมูลจริง การโต้ตอบบน browser ที่สำคัญต้องมีหลักฐานเกี่ยวกับหน้าจอที่ render แล้ว

ข้อกล่าวอ้าง	ตัวอย่างหลักฐาน
Output CSV escape เครื่องหมายคำพูดถูกต้อง	Unit test ที่มีเครื่องหมายคำพูดใน field
องค์กรอื่นอ่านข้อมูล export ไม่ได้	Integration test ผ่านการตรวจสอบสิทธิ์จริง
ผู้ใช้ keyboard เริ่ม export ได้	Browser test และการตรวจด้วย keyboard โดยคน
Export ที่ล้มเหลวให้ข้อผิดพลาดที่มีประโยชน์	การตรวจเส้นทางเมื่อผิดพลาดที่ interface ที่เกี่ยวข้อง

ไม่มีสัดส่วนประเภท test ตายตัวที่เหมาะกับทุกระบบ เลือกตามความผิดพลาดที่ต้องตรวจจับและต้นทุนดูแลการตรวจสอบ

หลีกเลี่ยงสมมติฐานผิดที่ใช้ร่วมกัน

Agent อาจเขียนทั้งโค้ดและ test จากความเข้าใจผิดเดียวกัน ทั้งสองอาจตรงกันทั้งที่ยังไม่เป็นไปตามข้อกำหนด

สมมติว่าโค้ดกรองระเบียนด้วย ID องค์กรที่มากับคำขอ Test ใช้ ID เดียวกันสำหรับผู้ใช้ที่เข้าสู่ระบบและคำขอ จึงผ่าน กรณีที่ขาดคือผู้ใช้ขอ ID ขององค์กรอื่น

เพิ่มกรณีนั้นผ่านตัวตนที่เชื่อถือได้และเส้นทางตรวจสอบสิทธิ์จริง Mock ที่ตอบว่า “อนุญาต” เสมอพิสูจน์การแยก tenant ไม่ได้ พิสูจน์ได้เพียงพฤติกรรมหลังผ่านการตรวจสอบสิทธิ์

ตรวจสอบว่า test ไม่ผ่านได้จริง

สำหรับข้อบกพร่องที่ทราบ ให้รัน regression test ใหม่กับเวอร์ชันที่มีข้อบกพร่องใน branch แยก ยืนยันว่าไม่ผ่านด้วยเหตุผลที่ตั้งใจ จากนั้นแก้ไขแล้วรันอีกครั้ง

Test ที่ไม่ผ่านเพราะโหลด fixture ไม่ได้ยังไม่ใช่หลักฐานเกี่ยวกับพฤติกรรมธุรกิจ ตรวจดูความผิดพลาด ไม่ใช่เพียง exit code

สำหรับการเปลี่ยนแปลงที่กว้างขึ้น mutation testing ช่วยประเมินว่าการเปลี่ยนโค้ดบางจุดทำให้ test ไม่ผ่านหรือไม่ วิธีนี้มีต้นทุนและแทนการตรวจทานข้อกำหนดไม่ได้ ใช้เมื่อหลักฐานเพิ่มเติมช่วยตัดสินใจเรื่องที่มีผลสำคัญ

เชื่อมหลักฐานกับการเปลี่ยนแปลงไว้

รันการตรวจสอบที่เกี่ยวข้องบน revision สุดท้าย บันทึกการตรวจสอบที่ข้ามและเหตุผล ผลจาก commit ก่อนหน้าอาจใช้ไม่ได้แล้วหลังแก้ตามการตรวจทาน

ทำให้ test เข้าใจง่าย เลือก setup และ assertion ที่ชัดเจนแทน helper ขนาดใหญ่ที่ซ่อนเงื่อนไขสำคัญ ลบการตรวจสอบซ้ำซ้อนเมื่อเพิ่มค่าดูแลโดยไม่ได้ตรวจพบความผิดพลาดแบบอื่น

ผู้ตรวจทานควรบอกได้ว่า test พิสูจน์อะไรและยังไม่แน่ใจอะไร คำอธิบายนี้มีประโยชน์กว่าจำนวน test ที่มาก

ทำแบบฝึกหัด

เลือก test ที่สร้างขึ้นหนึ่งรายการ ระบุข้อกำหนดที่มันทดสอบ ใส่ข้อบกพร่องที่เกี่ยวข้องชั่วคราวใน branch แยก ยืนยันว่า test ไม่ผ่านด้วยเหตุผลที่ตั้งใจ แล้วคืนโค้ดเดิม บันทึกสิ่งที่ test ยังไม่ครอบคลุม

ดาวน์โหลดใบงาน (Markdown)

ตรวจความเข้าใจ ↑