ในหน้านี้
การทดสอบสีเขียวอาจซ่อนกฎที่ขาด ในกรณีสมมตินี้ เอเจนต์ถูกขอให้เชื่อมร้านกับแพลตฟอร์มอีเมล เซิร์ฟเวอร์ทดสอบรับการอัปเดตรายชื่อและคืน 200 อย่างเรียบร้อย เอเจนต์ทำงานเสร็จและการทดสอบผ่าน
ปลายทางจริงมีกฎเพิ่ม: ต้องประกาศแอตทริบิวต์กำหนดเองก่อนการอัปเดตรายชื่อจะตั้งค่าได้ เซิร์ฟเวอร์ทดสอบไม่ได้จำลองกฎนั้น ผลสีเขียวพิสูจน์บางอย่างเกี่ยวกับเอเจนต์ในโลกทดสอบ ไม่พิสูจน์กฎที่ขาดในโลกจริง
นี่คือข้อแลกเปลี่ยนหลักของการจำลอง มันทำให้การกระทำอันตรายหรือแพงทำซ้ำได้ และสร้างระบบที่สองซึ่งพฤติกรรมอาจแยกจากระบบแรก
ระบบทดแทนทำให้ทดสอบการกระทำได้
การทดสอบเอเจนต์ที่ลงมือทำต้องมีเป้าหมาย สภาพแวดล้อม และสถานะปลายทางที่สังเกตได้ การอภิปรายต้นทางเรื่องสภาพแวดล้อมเอเจนต์จำลอง อธิบายโครงสร้างนี้ในงานเบราว์เซอร์และงานความรู้ สภาพแวดล้อมให้ตัวตรวจเทียบสิ่งที่เอเจนต์ทิ้งไว้กับผลที่ทราบว่าถูก
สำหรับการเชื่อมต่อ ระบบทดแทนอาจเปิดการดำเนินการปลายทางชุดเล็ก: ดูฟิลด์ สร้างรายชื่อ อัปเดตรายชื่อ และอ่านกลับ มันอาจถือชุดทดสอบที่มีฟิลด์ FNAME ประกาศแล้วและฟิลด์ CUSTOM_TIER ยังไม่มี การทดสอบให้เอเจนต์เสนอการแมป แล้วปฏิเสธการเขียนที่ใช้ CUSTOM_TIER ก่อนมีนิยาม
ระบบทดแทนมีประโยชน์เพราะทุกครั้งเริ่มจากสถานะเดียวกัน เปลี่ยนเงื่อนไขทีละอย่างได้: ฟิลด์หาย ปฏิเสธสิทธิ์ รุ่นสคีมาเก่า หรือตัวระบุกำกวม เทียบลำดับการเรียกและสถานะที่เกิดขึ้นระหว่างโมเดลหรือพรอมป์ต์ได้
นั่นแข็งแรงกว่าคำถามเป็นข้อความว่าเอเจนต์ จะ ทำอะไร มันทดสอบสิ่งที่เอเจนต์เรียกจริงในโลกที่ควบคุมได้
ให้ชุดทดสอบมีสถานะก่อนและหลังแต่ละการเรียก ไม่ใช่เพียงคำตอบสำเร็จรูป หากเอเจนต์สร้างรายชื่อสองครั้ง การเรียกที่สองควรเผยพฤติกรรมซ้ำที่ต้องการทดสอบ หากอ่านฟิลด์หลังเขียน การอ่านควรคืนสถานะที่เก็บจริง ไม่เช่นนั้นเอเจนต์อาจผ่านด้วยการส่งคำขอที่ดูสมเหตุผลโดยการทดสอบไม่รู้ว่าลำดับนั้นสร้างระเบียนที่ตั้งใจไหม
ความสมจริงเป็นส่วนหนึ่งของการทดสอบ
ข้อโต้แย้งที่ยุติธรรมคือ “ผู้ให้บริการมีแซนด์บ็อกซ์ ทำไมสร้างอีก” ใช้แซนด์บ็อกซ์ผู้ให้บริการเมื่อรองรับกรณีและรักษาข้อมูลปลอดภัย ระบบทดแทนในเครื่องคุ้มค่าเมื่อคุณต้องรีเซ็ตได้แน่นอน จำลองข้อผิดพลาดตั้งใจ หรือทดสอบการเรียกที่แซนด์บ็อกซ์จัดฉากไม่ได้ แต่มันมีต้นทุนดูแล กฎทุกข้อที่จำลองอาจผิดหรือล้าสมัย
API รายชื่อ Brevo อย่างเป็นทางการ ระบุว่าแอตทริบิวต์ต้องมีในบัญชีและค่าที่ผิดชนิดที่ประกาศจะถูกละเลย ระบบทดแทนที่ปฏิเสธค่าผิดรูปทุกกรณีจะต่างจากกรณีในเอกสาร มันอาจทำให้เอเจนต์คาดข้อผิดพลาดที่ไม่เคยมา
จดว่าระบบทดแทนครอบคลุมพฤติกรรมผู้ให้บริการใด เก็บชุดตรวจข้อกำหนดทางเทคนิคเล็ก ๆ กับ API จริงหรือสภาพแวดล้อมทดสอบที่รองรับ เมื่อพบความต่าง ให้อัปเดตระบบทดแทนและเพิ่มกรณีที่เผยความต่าง การจำลองเป็นแบบจำลองของผู้ให้บริการ ไม่ใช่สิ่งแทนผู้ให้บริการ
หลักเดียวกันใช้กับเวลา ระบบทดแทนที่ทำให้ทุกการเขียนมองเห็นทันทีอาจพลาดเวิร์กโฟลว์ที่อ่านเร็วเกินไป ระบบทดแทนที่หน่วงทุกการเขียนอาจสร้างความล้มเหลวที่ผู้ให้บริการไม่มี จำลองเวลาเฉพาะจุดที่มีผลต่อการตัดสินที่ทดสอบ และระบุส่วนที่อยู่นอกการจำลอง ผลทดสอบผ่านจึงมีความหมายแม่น: เอเจนต์นี้ทำการกระทำเหล่านี้เสร็จภายใต้กฎที่จำลอง
คู่มือคอนเน็กเตอร์ Brevo ของ Tajo อธิบายปัญหาเดียวกันจากฝั่งร้าน: คำขอสำเร็จอาจไม่ทิ้งฟิลด์ไว้ การทดสอบมีประโยชน์เมื่อดูฟิลด์ ไม่ใช่แค่คำตอบ HTTP
ปลายทางจำลองทดสอบเอเจนต์ภายใต้กฎที่สร้างขึ้น การตรวจข้อกำหนดทางเทคนิคเทียบกฎเหล่านั้นกับปลายทางจริงก่อนตัวอย่างใช้งานที่จำกัด
จากซ้อมปลอดภัยสู่หลักฐานที่จำกัด
การจำลองผ่านควรนำไปสู่ตัวอย่างใช้งานจริงขนาดเล็ก เลือกระเบียนไม่กี่รายการที่กำหนดสถานะปลายทางชัด รวมระเบียนปกติ ฟิลด์เสริมที่หาย และระเบียนที่สถานะความยินยอมห้ามใช้ทำการตลาด ตรวจสิ่งที่ปลายทางเก็บจริง อย่าสรุปจาก payload คำขออย่างเดียว
การดูตัวอย่างด้วยข้อมูลจำลองกับการตรวจปลายทางตอบคนละคำถาม ตัวอย่างการแมปของ Tajo ทดสอบการแปลงโดยไม่เขียนไปยังปลายทาง ภาพที่เสนอด้านล่างแสดงขั้นถัดไป: แม้ใช้การอัปเดตแล้วก็ยังต้องตรวจสถานะปลายทาง การแสดงว่ารออยู่ช่วยไม่ให้เข้าใจการซ้อมเป็นหลักฐาน
เขียนเสร็จก็ยังต้องมีหลักฐาน
การซิงค์ลูกค้าเสร็จหรือยัง
ใช้การเขียนแล้ว รอการตรวจยืนยัน
ยังไม่ได้ตรวจสถานะที่ปลายทาง
กิจกรรมการซิงค์
- รับคำขอแล้ว
- ใช้การอัปเดตแล้ว
- รอตรวจปลายทาง
การทำงานตัวอย่าง · 14:32 UTC
สิ่งที่ทราบ
- คำตอบจากผู้ให้บริการ
- รับแล้ว
- ผลการเขียน
- ใช้แล้ว
- อ่านกลับจากปลายทาง
- รอดำเนินการ
การเรียกสำเร็จไม่ได้พิสูจน์สถานะสุดท้าย
เค้าโครงที่เสนออิงฟีดกิจกรรมของ Tajo ภาพนี้เพิ่มสถานะการตรวจยืนยัน แต่ไม่ได้อ้างว่าการอ่านกลับจากปลายทางมีให้ใช้งานแล้ว
ตัวอย่างควรมีขอบเขตแคบและเงื่อนไขหยุดชัด ความล้มเหลวต้องหยุดการเปิดใช้วงกว้างและชี้ความต่างที่ตรงจุด: นิยามฟิลด์ ตัวระบุ ชนิด สิทธิ์ หรือเวลา ตัวอย่างที่ผ่านไม่พิสูจน์ว่าทุกระเบียนในอนาคตจะเหมือนกัน แต่พิสูจน์ว่าข้อกำหนดทางเทคนิคใช้ได้กับกรณีที่เลือกในวันนี้
ลำดับนี้แยกสองคำถาม การจำลองถามว่า “เอเจนต์เดินตามกฎที่ออกแบบเมื่อเราควบคุมโลกไหม” ตัวอย่างจริงถามว่า “กฎที่ออกแบบตรงกับบัญชีผู้ให้บริการนี้ไหม” คำถามหนึ่งแทนอีกข้อไม่ได้
คู่มือ Reverse ETL อธิบายว่าทำไมงานสุดท้ายจึงทำซ้ำกับหลายระเบียน การซ้ำนั้นขยายความต่างที่เหลือระหว่างข้อกำหนดจำลองกับข้อกำหนดจริง
ซ้อมในโลกที่รีเซ็ตได้ แล้วตรวจโลกที่รีเซ็ตไม่ได้
คำถามที่พบบ่อย
ปลายทางจำลองทดสอบอะไรได้?
ทดสอบว่าเอเจนต์เลือกการเรียกที่คาด เคารพสิทธิ์ จัดการข้อผิดพลาดที่รู้จัก และทิ้งสถานะตามคาดไว้ในระบบจำลอง
มันพิสูจน์อะไรไม่ได้?
พิสูจน์ไม่ได้ว่าแบบจำลองผู้ให้บริการครบ พฤติกรรมที่ไม่มีเอกสาร เวลา และการตั้งค่าเฉพาะบัญชีอาจต่างจากการจำลอง
หลังการจำลองผ่านควรทำอะไร?
รันตัวอย่างก่อนใช้งานหรือคานารีที่มีขอบเขตกับปลายทางจริง แล้วตรวจสถานะที่เกิดขึ้นก่อนเปิดใช้วงกว้าง