ทางเลือก Pact ที่ดีที่สุด

Pact เป็นเครื่องมืออ้างอิงสำหรับการทดสอบสัญญาแบบ consumer-driven ผู้บริโภค (Consumers) เขียน unit test ที่สร้างสัญญา ผู้ให้บริการ (Providers) นำสัญญานั้นกลับมาเล่นซ้ำกับโค้ดจริงของตน Pact Broker จัดเก็บผลลัพธ์ และ can-i-deploy จะบอก pipeline ของคุณว่าเวอร์ชันนั้นปลอดภัยที่จะนำไปใช้งานหรือไม่ เมื่อกระบวนการทำงาน มันจะตรวจจับข้อผิดพลาดในการรวมระบบที่ isolated unit tests ไม่สามารถทำได้ ปัญหาคือตัวกระบวนการเอง: ภาษาเฉพาะโดเมน (DSL) สำหรับการทดสอบในแต่ละภาษาบนทุกทีมผู้บริโภค, สถานะของผู้ให้บริการที่ต้องเขียนสคริปต์และบำรุงรักษา, broker ที่ต้องโฮสต์และจัดการเวอร์ชัน, และการสร้างเพื่อยืนยันของผู้ให้บริการที่ล้มเหลวด้วยเหตุผลที่ไม่มีใครสามารถทำซ้ำได้ในเครื่องของตนเอง หลายทีมนำ Pact มาใช้สำหรับการรวมระบบที่ไม่เสถียรเพียงครั้งเดียว และสุดท้ายก็ต้องมีทีมงานเล็กๆ เพื่อดูแลแพลตฟอร์มการทดสอบสัญญา

นี่คือคำตอบโดยตรง โดยระบุขอบเขตไว้ล่วงหน้า: Apidog เป็นทางเลือกที่ดีที่สุดสำหรับ Pact สำหรับทีมที่มีปัญหาจริงๆ คือ schema drift ระหว่างผู้ผลิตและผู้บริโภค ซึ่งเป็นปัญหาของทีมส่วนใหญ่ มันเข้ามาแทนที่ขั้นตอนการสร้าง pact ด้วย OpenAPI spec เพียงหนึ่งเดียวเป็นแหล่งข้อมูลความจริง ตรวจสอบความถูกต้องของทุกการตอบสนองเทียบกับ schema นั้นในการรันทดสอบทุกครั้ง ให้บริการ mock อัจฉริยะจาก spec เพื่อให้ผู้บริโภคสามารถพัฒนาตามสัญญาก่อนที่ผู้ให้บริการจะส่งมอบ และรันทั้งหมดใน CI ผ่าน Apidog CLI สิ่งที่ Apidog ไม่ทำคือการจำลองเวิร์กโฟลว์ของ Pact Broker แบบ consumer-driven: ไม่มีไฟล์ pact, ไม่มี matrix, ไม่มี can-i-deploy หากคุณต้องการกลไกที่แม่นยำดังกล่าวในหลายๆ ทีมที่ปรับใช้แยกกัน Pact ยังคงเป็นเครื่องมือที่เหมาะสม และบทความนี้จะกล่าวถึงเรื่องนี้ด้านล่าง

ปุ่ม

สิ่งที่ Pact ทำได้จริงและทำได้ดี

เอกสารของ Pact อธิบายว่าเป็นเครื่องมือที่เน้นโค้ดเป็นหลักสำหรับการทดสอบ HTTP และการรวมข้อความ รูปแบบคือแบบ consumer-driven: การทดสอบของผู้บริโภคจะรันกับ Pact mock provider และบันทึกคู่ request/response ที่เป็นรูปธรรมลงในไฟล์ pact เฉพาะฟิลด์ที่ผู้บริโภคใช้เท่านั้นที่จะถูกบันทึก ทำให้ผู้ให้บริการมีอิสระที่จะเปลี่ยนแปลงสิ่งใดๆ ที่ไม่มีใครพึ่งพา จากนั้นผู้ให้บริการจะยืนยัน pact โดยการเล่นซ้ำคำขอเหล่านั้นกับโค้ดจริง โดยมี provider states ที่ตั้งค่าข้อมูลที่แต่ละการโต้ตอบต้องการ

Pact Broker เปลี่ยน artifact เหล่านั้นให้เป็นตรรกะการปรับใช้ (deployment logic) คู่เวอร์ชันผู้บริโภคและผู้ให้บริการที่ได้รับการยืนยันทุกคู่จะถูกบันทึกใน matrix และ can-i-deploy จะตรวจสอบว่าเวอร์ชันที่คุณกำลังจะนำไปใช้มีการยืนยันที่สำเร็จเทียบกับทุกสิ่งที่กำลังทำงานอยู่ในสภาพแวดล้อมเป้าหมายแล้วหรือไม่ Exit code 0 หมายถึงนำไปใช้ได้, 1 หมายถึงห้ามนำไปใช้

ระบบนิเวศกว้างขวาง: มีการใช้งานอย่างเป็นทางการในกว่า 10 ภาษา รวมถึง JVM, JavaScript, Go, .NET, Python, Ruby, Rust, PHP และ Swift ซึ่งส่วนใหญ่ใช้ Rust core ดั้งเดิมร่วมกัน และเนื่องจากการโฮสต์ broker ด้วยตัวเองเป็นงานที่ต้องใช้ความพยายาม SmartBear จึงจำหน่าย PactFlow ซึ่งเป็น managed broker ที่มี Starter tier ฟรี (รองรับ 2 การรวมระบบ), Team tier ราคา 127 ดอลลาร์ต่อเดือนสำหรับ 50 การรวมระบบ และ Enterprise ที่ราคาตามการปรับแต่ง พร้อม SSO และตัวเลือก on-premise

พิธีรีตองที่สะสม

สิ่งที่น่าสนใจคือ "การรันลูป" นั้นมีค่าใช้จ่ายเท่าใดในการปฏิบัติจริง

ทุกทีมผู้บริโภคเขียนโค้ด DSL

Pacts ถูกสร้างจากโค้ดทดสอบ ดังนั้นแต่ละทีมผู้บริโภคจึงต้องเรียนรู้ Pact DSL สำหรับภาษาของตน และองค์กรที่ใช้หลายภาษาจะต้องเรียนรู้หลายภาษา กฎการจับคู่และการตั้งค่า mock เป็นโค้ดที่คุณต้องเขียน ตรวจสอบ และปรับปรุงใหม่ตลอดไป

สถานะของผู้ให้บริการเป็นชุดทดสอบที่ซ่อนอยู่

แต่ละการโต้ตอบอาจต้องมีสถานะ (เช่น “ผู้ใช้ 42 มีใบแจ้งหนี้ที่ยังไม่ได้ชำระ”) และทีมผู้ให้บริการจะต้องใช้งาน handler ที่สร้างสถานะนั้นขึ้นมา เมื่อผู้บริโภคเพิ่มขึ้น ผู้ให้บริการจะต้องดูแลแคตตาล็อกของ state handler สำหรับรูปแบบข้อมูลที่ตนเองไม่ได้ควบคุม

Broker คือโครงสร้างพื้นฐาน

หากโฮสต์ด้วยตัวเอง จะต้องมีฐานข้อมูล, การอัปเกรด, การรับรองความถูกต้อง (auth) และ webhooks เข้าสู่ทุกระบบ CI หากจัดการโดยผู้ให้บริการภายนอก ก็จะเป็นผู้ขายอีกราย ไม่ว่าจะทางใด การจัดการเวอร์ชันอย่างมีวินัย (ชื่อ branch, บันทึกสภาพแวดล้อม, pending pacts) จะต้องสอนให้ทุกทีมที่เกี่ยวข้อง

การยืนยันของผู้ให้บริการไม่เสถียร

การยืนยันจะเล่นซ้ำคำขอที่บันทึกโดยผู้บริโภคกับ live provider instance ซึ่งดึงเอา runtime ทั้งหมดของผู้ให้บริการเข้ามา: database seeds, auth stubs, background jobs เมื่อ build ไม่ผ่าน การทดสอบที่ล้มเหลวถูกเขียนโดยทีมอื่นและขัดขวางการปรับใช้ของพวกเขาผ่าน can-i-deploy การแก้ไขข้อผิดพลาดข้ามทีมนั้นเป็นช่วงเวลาที่ทีมต่างๆ เริ่มข้ามการตรวจสอบโดยเงียบๆ

PactFlow เองก็ยอมรับถึงภาระนี้ การทดสอบสัญญาแบบ bi-directional ของมันตัดขั้นตอนการเล่นซ้ำออก: ผู้ให้บริการเผยแพร่เอกสาร OpenAPI เป็นสัญญาของตน, ผู้บริโภคเผยแพร่สัญญาที่ได้จาก mock, และ PactFlow เปรียบเทียบทั้งสองอย่างแบบ static นั่นคือการยอมรับที่สร้างขึ้นโดยผู้จำหน่ายว่าสำหรับการรวมระบบจำนวนมาก การเปรียบเทียบ schemas ก็เพียงพอแล้ว และถ้า spec คือสัญญา กลไกที่เหลือให้ประโยชน์อะไรแก่คุณ? เราได้อธิบายเหตุผลเดียวกันนี้ในการ ทดสอบสัญญาแบบ bidirectional

คำตอบ: Apidog

Apidog เป็นแพลตฟอร์มพัฒนา API ที่มีนักพัฒนาใช้งานกว่า 500,000 คน มันนำ OpenAPI spec เพียงหนึ่งเดียวมาเป็นศูนย์กลางและสร้างทุกสิ่งอย่างอื่นจากมัน: เอกสารประกอบ, mock servers, การตรวจสอบความถูกต้องของคำขอ และการทดสอบอัตโนมัติ ในฐานะทางเลือกสำหรับ Pact แนวคิดคือทฤษฎีสัญญาที่แตกต่างออกไป ซึ่งเราได้อธิบายไว้ในการ ทดสอบสัญญา API: ทำให้ spec เป็นสัญญา จากนั้นบังคับใช้มันด้วยกลไกทุกที่

1. หนึ่งสัญญา, ไม่มี DSLs. Spec คือข้อตกลงระหว่างผู้ผลิตและผู้บริโภค ไม่มีใครเขียนโค้ดสร้าง pact ในห้าภาษา; ทีมอ่านและแก้ไขเอกสารเดียว ไม่ว่าจะในรูปแบบภาพหรือโค้ด
2. การตรวจสอบ Schema ในทุกครั้งที่รัน. ทุกคำขอที่คุณส่งใน Apidog และทุกสถานการณ์การทดสอบใน CI จะตรวจสอบการตอบสนองเทียบกับ spec โดยอัตโนมัติ การเปลี่ยนชื่อฟิลด์, การเปลี่ยนประเภท หรือ property ที่ถูกลบออก จะทำให้การรันล้มเหลวโดยไม่ต้องมีใครเขียน assertion นั่นคือการตรวจจับ schema drift ที่ทีมส่วนใหญ่ซื้อ Pact มาเพื่อสิ่งนี้
3. ผู้บริโภคพัฒนาตามสัญญาตั้งแต่วันแรก. Smart mock server จะให้บริการการตอบสนองที่สมจริงซึ่งมาจาก schema ทันทีที่ endpoint ถูกกำหนด ไม่ต้องเขียนสคริปต์ provider states; mock ถูกสร้างขึ้นโดยอัตโนมัติ ไม่ใช่สร้างด้วยมือ
4. การบังคับใช้ CI โดยไม่มี broker. apidog run รันสถานการณ์การทดสอบใน pipeline ใดก็ได้ การ build ของผู้ให้บริการที่ทำลาย spec จะทำให้ CI ของตัวเองล้มเหลวก่อนที่จะ deploy: ซึ่งเป็นผลลัพธ์แบบเดียวกันที่ว่า “ห้ามส่งมอบการเปลี่ยนแปลงที่ก่อให้เกิดความเสียหาย” โดยถูกบังคับใช้ที่ต้นทางแทนที่จะเป็นที่ matrix

การเปลี่ยนแปลงมีลักษณะอย่างไร ทีละส่วน

ตัวสัญญาเอง

ใน Pact สัญญาคือไฟล์ JSON ที่สร้างขึ้นจากการโต้ตอบตัวอย่าง; มันอธิบายสิ่งที่ผู้บริโภครายหนึ่งสังเกตเห็น ใน Apidog สัญญาคือ OpenAPI spec: ประเภท, ฟิลด์ที่จำเป็น, enums และรูปแบบข้อผิดพลาดสำหรับทุก endpoint โดยมีการจัดการในที่เดียวด้วยการควบคุมเวอร์ชันแบบ branch การแลกเปลี่ยนที่ซื่อสัตย์คือ: ส่วนย่อยต่อผู้บริโภคของ Pact จะบอกผู้ให้บริการได้อย่างแม่นยำว่าฟิลด์ใดที่ปลอดภัยที่จะเปลี่ยนแปลง และ shared spec ไม่ได้มีสัญญาณการใช้งานนั้น สิ่งที่ spec ให้มาแทนคือ artifact เพียงหนึ่งเดียวที่เอกสารประกอบ, mocks, การทดสอบ และ client ทั้งหมดเห็นชอบร่วมกัน; ดูรายละเอียดเพิ่มเติมเกี่ยวกับแนวคิดนี้ใน what is an API contract

การยืนยันฝั่งผู้ให้บริการ

Pact เล่นซ้ำการโต้ตอบของผู้บริโภคกับ live provider สิ่งที่เทียบเท่าของ Apidog คือการรันสถานการณ์การทดสอบกับ implementation จริงโดยเปิดการตรวจสอบ schema ใน CI ผ่าน CLI ผู้ให้บริการยังคงได้รับการยืนยันเทียบกับสัญญา โดยไม่ต้องมีแคตตาล็อกของ states ที่ผู้บริโภคสร้างขึ้น

การพัฒนาฝั่งผู้บริโภค

Pact ให้ mock provider แก่ผู้บริโภคแต่ละรายภายใน unit tests ของตน Apidog ให้ URL mock ที่ทำงานอยู่แก่ผู้บริโภคทุกคน ซึ่งมาจาก spec, สามารถแชร์ข้ามทีมได้ และมี custom expectations ในกรณีที่คุณต้องการข้อมูลเฉพาะ ทีม Frontend และ downstream สามารถเริ่มต้นได้ก่อนที่ผู้ให้บริการจะมีการใช้งานแม้แต่บรรทัดเดียว; ดู contract testing and mock servers เพื่อเปรียบเทียบว่า mock ที่ขับเคลื่อนด้วย spec แตกต่างจาก mock ที่สร้างด้วยมืออย่างไร

การควบคุมการปรับใช้

นี่คือจุดแข็งที่สุดของ Pact และ Apidog ไม่ได้จำลองมัน ไม่มี cross-service matrix และไม่มี can-i-deploy Apidog จะควบคุมที่ระดับสัญญาแทน: การเปลี่ยนแปลงของผู้ให้บริการที่ละเมิด spec จะทำให้ pipeline ของผู้ให้บริการล้มเหลว และการเปลี่ยนแปลง spec เป็นเหตุการณ์ที่ชัดเจนและได้รับการตรวจสอบ ซึ่งจะสร้าง mocks และเอกสารประกอบใหม่สำหรับผู้บริโภคทุกรายพร้อมกัน ในกรณีที่บริการถูกปรับใช้ผ่าน pipeline ที่ประสานงานกันไม่กี่แห่ง การควบคุมระดับสัญญาก็เพียงพอแล้วสำหรับ 80% ของกรณี สำหรับทีมหลายสิบทีมที่ปรับใช้แยกกันในเวลาที่ไม่แน่นอน การควบคุมระดับ matrix ยังคงมีประโยชน์อยู่

Pact และ PactFlow เทียบกับ Apidog โดยสรุป

ต้นทุนและความเหมาะสมอย่างตรงไปตรงมา

ไลบรารีของ Pact เป็นโอเพนซอร์สและฟรีตลอดไป สิ่งที่คุณต้องจ่ายคือการประสานงาน: การโฮสต์ broker หรือ PactFlow (Team tier ราคา 127 ดอลลาร์ต่อเดือน, ประมาณ 1,385 ดอลลาร์ต่อปี), บวกกับเวลาทางวิศวกรรมที่ใช้ไปกับการทดสอบ DSL, state handlers และการแก้ไขข้อผิดพลาดในการยืนยันข้ามทีม เวลานั้นคือค่าใช้จ่ายที่แท้จริง และมันจะเพิ่มขึ้นตามจำนวนการรวมระบบ

แผนฟรีของ Apidog ครอบคลุมผู้ใช้ 4 คน พร้อม spec editor, การใช้ mock server ไม่จำกัด, สถานการณ์ทดสอบ, การตรวจสอบ schema และการรัน CLI; แผนแบบเสียเงินเริ่มต้นที่ 9 ดอลลาร์ต่อผู้ใช้ต่อเดือน ดังนั้นการเปรียบเทียบจึงไม่ใช่แค่ค่าลิขสิทธิ์ มันคือว่าคุณต้องการบำรุงรักษากลไกการทดสอบสัญญา หรือเลือกใช้แพลตฟอร์มที่งานสัญญามาพร้อมกับ API client ที่คุณต้องการอยู่แล้ว (ต้องการรวมเครื่องมือใช่ไหม? เริ่มต้นจาก ทางเลือกที่ดีที่สุดสำหรับ Postman) ทีมที่เลือกใช้แนวทาง spec-first ตั้งแต่ต้นสามารถดูว่าแต่ละส่วนประกอบเข้ากันได้อย่างไรใน contract-first development toolstack

การย้ายจาก Pact

คุณไม่ต้องแปลงไฟล์ pact; คุณเลื่อนระดับ spec ให้เป็นสัญญา

1. รับ OpenAPI spec ที่แท้จริง. หากคุณมี ให้นำเข้าสู่ Apidog; มันจะกลายเป็นเอกสารสด, mocks และกฎการตรวจสอบทันที หากไม่มี ให้สร้างจาก code annotations โดยใช้ไฟล์ pact ของคุณเป็นรายการตรวจสอบ endpoint ที่ผู้บริโภคใช้งานจริง
2. เปิดใช้งานการตรวจสอบ schema ใน CI. สร้างสถานการณ์ทดสอบสำหรับ endpoint ของผู้ให้บริการและรันด้วย CLI ในทุกการ build ของผู้ให้บริการ สิ่งนี้จะแทนที่การยืนยันผู้ให้บริการ
3. ชี้ผู้บริโภคไปยัง smart mock. แทนที่การตั้งค่า Pact mock ของผู้บริโภคแต่ละรายด้วย hosted mock URL ลบโค้ด DSL เมื่อผู้บริโภคแต่ละรายเปลี่ยนไปใช้
4. ควบคุมการเปลี่ยนแปลง spec ไม่ใช่การ deploy. ทำให้การแก้ไข spec เป็นการเปลี่ยนแปลงที่ได้รับการตรวจสอบบน branch เพื่อให้การแก้ไขที่สร้างความเสียหายกลายเป็น diffs ที่มองเห็นได้ก่อนที่จะกลายเป็นเหตุการณ์
5. เลิกใช้ broker เป็นอันดับสุดท้าย. คง can-i-deploy ไว้ในการรวมระบบใดๆ ที่การปรับใช้แยกกันตามเวลาเป็นความเสี่ยงที่เกิดขึ้นจริง; ทิ้งมันไปในกรณีที่เป็นเพียงพิธีรีตอง

เมื่อใดที่ Pact ยังคงสมเหตุสมผล

หากหลายทีมปรับใช้บริการแยกกันตามตารางเวลาของตนเอง และคุณต้องการคำตอบที่ตรวจสอบได้ด้วยเครื่องว่า “เวอร์ชัน X สามารถเข้าสู่การผลิตได้หรือไม่ในตอนนี้ เมื่อพิจารณาจากทุกสิ่งที่กำลังทำงานอยู่” Pact broker matrix และ can-i-deploy ถูกสร้างขึ้นมาเพื่อสิ่งนั้นโดยเฉพาะ และ Apidog ไม่ได้จำลองสิ่งเหล่านี้ การทดสอบสัญญาของ Message-queue ก็เป็นขอบเขตของ Pact เช่นกัน โหมด bi-directional ของ PactFlow เป็นขั้นตอนตรงกลางหากคุณต้องการหลีกเลี่ยงพิธีการเล่นซ้ำโดยไม่ต้องออกจากระบบนิเวศ; มันใช้หลักการเดียวกับ Apidog ที่ว่า spec สามารถเป็นสัญญาได้ แต่หากปัญหาของคุณคือ schema drift, mocks และการตรวจสอบ CI แทนที่จะเป็นการจัดลำดับการ deploy ข้ามทีม คุณกำลังจ่ายค่า Pact เต็มจำนวนเพื่อประโยชน์เพียงเล็กน้อย

คำถามที่พบบ่อย

Apidog เป็นเครื่องมือทดสอบสัญญาเหมือน Pact หรือไม่?

มันบังคับใช้สัญญาที่แตกต่างกัน Pact สร้างสัญญาต่อผู้บริโภคจากโค้ดทดสอบและเล่นซ้ำกับผู้ให้บริการ Apidog ทำให้ OpenAPI spec เป็นสัญญาและตรวจสอบความถูกต้องของทุกคำขอและ CI run เทียบกับมัน ซึ่งครอบคลุม schema drift โดยไม่ต้องมีเวิร์กโฟลว์ของ broker ความแตกต่างนี้มีการอธิบายไว้ใน API contract testing

Apidog รองรับ can-i-deploy หรือ Pact Broker หรือไม่?

ไม่ Apidog ไม่มี verification matrix หรือ cross-service deploy gate การควบคุมของมันอยู่ที่สัญญา: builds ที่ละเมิด spec จะทำให้ pipeline ของตัวเองล้มเหลว ทีมที่ต้องการการควบคุมระดับ matrix ควรรักษา Pact ไว้สำหรับการรวมระบบเหล่านั้น; ตัวเลือกกลางคือแนวทางการเปรียบเทียบแบบ static ที่กล่าวถึงใน bidirectional contract testing

Apidog สามารถแทนที่ Pact’s consumer mocks ได้หรือไม่?

ได้ สำหรับการใช้งานส่วนใหญ่ Smart mock server สร้างการตอบสนองที่ถูกต้องตาม schema จาก spec โดยไม่ต้องตั้งค่าใดๆ บวกกับ custom expectations สำหรับกรณีเฉพาะ ทำให้ทีมผู้บริโภคเขียนโค้ดโดยอิงจาก live contract URL แทนที่จะเขียน mock-provider DSL ดู contract testing and mocking tools สำหรับภาพรวมเครื่องมือที่กว้างขึ้น

แล้วการ fuzzing ผู้ให้บริการเทียบกับ spec ล่ะ?

การจับคู่ scenario tests ของ Apidog กับ spec-based property tester ให้ความครอบคลุมด้านลบที่กว้างกว่าการเล่นซ้ำตัวอย่าง เราได้เปรียบเทียบตัวเลือกชั้นนำใน what is Schemathesis และ spec เดียวกันนี้ขับเคลื่อนทั้งสองเครื่องมือ

PactFlow มีค่าใช้จ่ายเท่าไหร่เมื่อเทียบกับ Apidog?

Starter tier ของ PactFlow ฟรีสำหรับการรวมระบบ 2 รายการ; Team tier มีราคา 127 ดอลลาร์ต่อเดือน (ประมาณ 1,385 ดอลลาร์ต่อปี) สำหรับการรวมระบบ 50 รายการ; Enterprise เป็นราคาแบบกำหนดเอง Apidog ฟรีสำหรับผู้ใช้สูงสุด 4 คน โดยมีแผนแบบเสียเงินเริ่มต้นที่ 9 ดอลลาร์ต่อผู้ใช้ต่อเดือน โดยรวมเครื่องมือสัญญาไว้ด้วย ไม่ได้เรียกเก็บเป็นค่า broker แยกต่างหาก กำลังเปรียบเทียบเครื่องมือ capture-replay ด้วยหรือไม่? ดู the best Keploy alternative

เลิกพิธีรีตอง, รักษาสัญญาไว้

หากการตั้งค่า Pact ของคุณมีอยู่เพื่อตรวจจับ schema drift คุณสามารถรับประกันสิ่งนั้นได้จาก spec เดียว ซึ่งได้รับการตรวจสอบในทุกการรัน พร้อมด้วย mocks ที่ผู้บริโภคของคุณต้องการอยู่แล้ว นำเข้าไฟล์ OpenAPI ของคุณ, เชื่อมต่อ apidog run เข้ากับ CI และแจกจ่าย mock URL ดาวน์โหลด Apidog หรือเริ่มต้นในเบราว์เซอร์; ทีมที่มี 4 คนไม่ต้องจ่ายอะไร และ broker ที่คุณไม่ต้องบำรุงรักษาอีกต่อไปคือจุดสำคัญ