โค้ดของคุณพึ่งพาบริการที่คุณควบคุมไม่ได้ ไม่ว่าจะเป็นเกตเวย์การชำระเงิน, API ของพาร์ทเนอร์, เมนเฟรมรุ่นเก่า, หรือไมโครเซอร์วิสของทีมอื่น การพึ่งพานั้นอาจหยุดทำงานเพื่อบำรุงรักษา, จำกัดจำนวนการเรียกใช้ทดสอบ, คิดค่าบริการต่อการเรียกใช้, หรือส่งคืนข้อมูลที่ไม่น่าเชื่อถือ ทำให้การพัฒนาของคุณหยุดชะงักและ CI pipeline ของคุณขึ้นสีแดงด้วยเหตุผลที่ไม่ได้เกี่ยวข้องกับโค้ดของคุณเลย
Service virtualization แก้ไขปัญหานี้ได้ คุณจะแทนที่การพึ่งพาจริงด้วยตัวจำลองที่ทำงานเหมือนกัน เพื่อให้คุณสามารถสร้างและทดสอบกับสิ่งที่ควบคุมได้อย่างเต็มที่ คู่มือนี้จะอธิบายว่า service virtualization คืออะไร, แตกต่างจากการ mocking และ stubbing อย่างไร, ทำไมทีมถึงเลือกใช้, และเครื่องมือใดที่ช่วยได้ พร้อมตัวอย่างคำสั่งจริงสำหรับ WireMock, Hoverfly, Mountebank, ตัวเลือกสำหรับองค์กร, และ Apidog’s mock server สำหรับการทำ API-contract virtualization
Service virtualization คืออะไร
Service virtualization จำลองพฤติกรรมของการพึ่งพาที่คุณควบคุมไม่ได้ เพื่อให้แอปพลิเคชันของคุณสามารถสื่อสารกับการจำลองนั้นแทนที่จะเป็นของจริง
คำว่า “พฤติกรรม” มีความสำคัญในที่นี้ บริการเสมือนที่ดีไม่ได้แค่ส่งคืนเพย์โหลดที่คงที่เท่านั้น แต่ยังจับคู่รายละเอียดของคำขอ, ส่งคืนการตอบกลับที่แตกต่างกันสำหรับอินพุตที่ต่างกัน, คงสถานะข้ามการเรียกใช้, เพิ่มความล่าช้าและความผิดพลาด, และใช้โปรโตคอลเดียวกับระบบจริง เป้าหมายคือการสร้างตัวจำลองที่สมจริงพอที่โค้ดของคุณจะแยกความแตกต่างไม่ออกในระหว่างการพัฒนาและการทดสอบ
คำว่า “API virtualization” มีความหมายเดียวกันเมื่อการพึ่งพาเป็น HTTP API และ “API simulator” คือเครื่องมือที่สร้างเอนด์พอยต์เสมือน พิจารณาทั้งสองคำนี้เป็นคำพ้องความหมายสำหรับส่วนของ service virtualization ที่เน้น API
Service virtualization เทียบกับ mocking และ stubbing
คำศัพท์ทั้งสามนี้มีความทับซ้อนกัน และผู้คนก็นำไปใช้กันอย่างหลวมๆ นี่คือวิธีปฏิบัติในการแยกแยะความแตกต่าง
stub จะส่งคืนการตอบกลับที่ถูกกำหนดไว้ล่วงหน้า (hardcoded) โดยไม่สนใจคำขอและตอบกลับด้วยวิธีเดิมเสมอ หากการทดสอบของคุณเรียกใช้ GET /user/42 และ stub ถูกตั้งค่าให้ส่งคืนอ็อบเจกต์ผู้ใช้ที่แน่นอน มันก็จะส่งคืนอ็อบเจกต์เดียวกันนั้นไม่ว่าคุณจะส่ง ID ใดเข้าไป Stubs เป็นรูปแบบที่ง่ายที่สุดและอยู่ในโค้ดทดสอบของคุณ
mock คือ stub ที่ยังตรวจสอบปฏิสัมพันธ์ด้วย มันจะบันทึกว่าถูกเรียกอย่างไร (เมธอดใด, อาร์กิวเมนต์ใด, จำนวนครั้งเท่าไหร่) เพื่อให้การทดสอบของคุณสามารถยืนยันได้ว่าโค้ดของคุณใช้การพึ่งพาอย่างถูกต้อง Mocks เป็นเครื่องมือสำหรับการทดสอบหน่วย (unit-testing) โดยปกติจะทำงานแบบ in-process ในภาษาเดียวกับโค้ดของคุณ คำอธิบาย API stubbing vs API mocking ของเราจะเจาะลึกความแตกต่างนี้มากขึ้น
Service virtualization ทำงานผ่านเครือข่าย ไม่ได้อยู่ในโค้ดของคุณ มันจะตั้งค่าบริการที่กำลังทำงานอยู่บนพอร์ตเครือข่ายจริงที่ใช้โปรโตคอลจริง แอปพลิเคชันของคุณจะเชื่อมต่อกับมันในลักษณะเดียวกับการเชื่อมต่อไปยังระบบ production โดยการเปลี่ยน base URL หรือการตั้งค่า proxy บริการเสมือนสามารถมีสถานะ (stateful), สามารถจับคู่เงื่อนไขคำขอที่ซับซ้อน, และสามารถจำลองพฤติกรรมระดับโปรโตคอล เช่น HTTP status codes, headers, streaming, และข้อผิดพลาดในการเชื่อมต่อ
เส้นแบ่งระหว่าง “mock” และ “service virtualization” นั้นเลือนลางในการใช้งานประจำวัน หลายทีมเรียก HTTP mock server ที่กำลังทำงานอยู่ว่า “mock” แม้ว่ามันจะทำ virtualization เต็มรูปแบบก็ตาม ซึ่งก็ไม่เป็นไร สิ่งที่สำคัญคือความแตกต่าง: คุณกำลังแทนที่อ็อบเจกต์ภายในกระบวนการของคุณ (mocking/stubbing) หรือกำลังตั้งค่าบริการเครือข่ายที่แอปของคุณเชื่อมต่อ (virtualization)? ดู API mocking: everything you need to know สำหรับมุมมองของ mock
ทำไมทีมถึงใช้ service virtualization
สามปัญหาหลักที่ผลักดันให้มีการนำไปใช้มากที่สุด
การพึ่งพายังไม่พร้อมใช้งาน ทีม Frontend และ Backend ทำงานควบคู่กันไป และ Frontend ต้องการ API ที่ใช้งานได้ก่อนที่ Backend จะส่งมอบ บริการเสมือนที่สร้างจาก API contract ช่วยให้ Frontend สามารถสร้างโดยอิงจากการตอบกลับที่สมจริงได้ตั้งแต่วันนี้ ไม่ต้องรอใคร
การพึ่งพามีราคาแพงหรือถูกจำกัดจำนวนการเรียกใช้ (rate-limited) API ของบุคคลที่สามมักจะคิดค่าบริการต่อการเรียกใช้ หรือจำกัดอย่างเข้มงวด การเรียกใช้ชุดทดสอบเต็มรูปแบบกับ sandbox จริงจึงสิ้นเปลืองโควต้าและเงิน บริการเสมือนสามารถเรียกใช้ได้ฟรี ทำให้ CI ของคุณสามารถรันสถานการณ์ได้หลายพันครั้งต่อวัน
การพึ่งพาไม่เสถียร (flaky) หรือควบคุมได้ยาก คุณไม่สามารถทำให้ผู้ให้บริการชำระเงินจริงส่งคืนข้อผิดพลาดที่เฉพาะเจาะจง, หมดเวลา, หรือส่งการตอบกลับที่ไม่ถูกต้องได้ง่ายๆ บริการเสมือนสามารถสร้างสิ่งเหล่านี้ได้ตามต้องการ ซึ่งเป็นวิธีที่คุณใช้ทดสอบเส้นทางข้อผิดพลาดที่ทำให้ระบบ production ล้มเหลว
นอกจากนี้ยังมีประโยชน์ด้านการควบคุม การพึ่งพาจริงมีข้อมูลที่เปลี่ยนแปลงอยู่ตลอดเวลา บริการเสมือนช่วยให้คุณมีสถานะที่แน่นอนและคงที่ ทำให้การทดสอบของคุณเป็นแบบกำหนดได้ (deterministic) การสร้างสำเร็จ (green build) หมายความว่าโค้ดของคุณทำงานได้ ไม่ใช่ว่าระบบระยะไกลบังเอิญทำงานได้ดีในวันนี้
Service virtualization ทำงานอย่างไร
เครื่องมือส่วนใหญ่ปฏิบัติตามหนึ่งในสองรูปแบบนี้
บันทึกและเล่นซ้ำ (Record and replay) คุณชี้เครื่องมือไปยังบริการจริงในฐานะ proxy, รันทราฟฟิกจริงผ่านมันครั้งเดียว, แล้วมันจะจับคู่คำขอ/การตอบกลับเอาไว้ หลังจากนั้นมันจะเล่นซ้ำการบันทึกเหล่านั้นแทนการเรียกใช้บริการจริง วิธีนี้รวดเร็วเพราะคุณไม่ต้องเขียนการตอบกลับด้วยมือ โหมดจับภาพของ Hoverfly และโหมดบันทึกของ WireMock ทำงานในลักษณะนี้ทั้งคู่
ขับเคลื่อนด้วยข้อกำหนด (Specification-driven) คุณกำหนดบริการเสมือนจาก API contract หรือด้วยตนเอง: ระบุว่าคำขอใดจับคู่กับการตอบกลับใด, เพิ่มค่าแบบไดนามิก, และตั้งค่าพฤติกรรมแบบมีสถานะ (stateful) วิธีนี้ต้องใช้ความพยายามในช่วงแรกมากกว่า แต่ให้การควบคุมอย่างเต็มที่และใช้งานได้แม้ว่าบริการจริงยังไม่มีอยู่
ไม่ว่าจะด้วยวิธีใด กลไกหลักคือการจับคู่คำขอ (request matching) เมื่อคำขอมาถึง เครื่องมือจะตรวจสอบกับชุดกฎ (path, method, query parameters, headers, body) และส่งคืนการตอบกลับที่ผูกกับรายการที่ตรงกันรายการแรก เครื่องมือที่ดีกว่าจะเพิ่มการสร้างเทมเพลต (templating) เพื่อให้การตอบกลับสามารถสะท้อนส่วนต่างๆ ของคำขอ หรือสร้างค่าใหม่ในการเรียกใช้แต่ละครั้ง นั่นคือวิธีที่ทำให้บริการเสมือนรู้สึกเหมือนมีชีวิตแทนที่จะเป็นแบบคงที่
เครื่องมือต่างๆ
นี่คือตัวเลือกหลักๆ ตั้งแต่เครื่องมือโอเพนซอร์สที่เน้น HTTP ไปจนถึงชุดเครื่องมือสำหรับองค์กรขนาดใหญ่ ตรวจสอบเวอร์ชันและคุณสมบัติปัจจุบันกับเอกสารของแต่ละโปรเจกต์ก่อนที่คุณจะตัดสินใจ เนื่องจากสิ่งเหล่านี้เปลี่ยนแปลงอย่างรวดเร็ว
WireMock
WireMock เป็นเครื่องมือโอเพนซอร์สสำหรับการจำลอง API (API mocking) และ service virtualization สำหรับ HTTP มันทำงานเป็นกระบวนการแบบสแตนด์อโลน, ฝังอยู่ใน JVM tests, หรือในคอนเทนเนอร์ คุณกำหนดการแมป stub เป็น JSON และ WireMock จะจับคู่คำขอที่เข้ามากับสิ่งเหล่านั้น มันรองรับการบันทึกและเล่นซ้ำกับบริการจริง, การสร้างเทมเพลตการตอบกลับ, สถานการณ์แบบมีสถานะ (stateful scenarios), การฉีดข้อผิดพลาด (fault injection), และการจำลองความล่าช้า
java -jar wiremock-standalone-3.13.2.jar --port 8080
Then register a stub over its admin API:
curl -X POST http://localhost:8080/__admin/mappings \
-H "Content-Type: application/json" \
-d '{
"request": {
"method": "GET",
"url": "/user/42"
},
"response": {
"status": 200,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": 42, "name": "Ada Lovelace" }
}
}'
WireMock มีประสิทธิภาพสูงสุดเมื่อการพึ่งพาของคุณเป็น HTTP และคุณต้องการการควบคุมที่ละเอียดอ่อนในการตั้งค่า JVM หรือคอนเทนเนอร์ มีเวอร์ชันเชิงพาณิชย์แบบโฮสต์ (WireMock Cloud) หากคุณต้องการตัวเลือกแบบ managed
Hoverfly
Hoverfly เป็นเครื่องมือ service virtualization แบบโอเพนซอร์สที่มีน้ำหนักเบา เขียนด้วยภาษา Go มันทำงานเป็น proxy: คุณส่งทราฟฟิกขาออกจากแอปพลิเคชันของคุณผ่าน Hoverfly และมันจะบันทึกการตอบกลับจริง หรือเล่นซ้ำการตอบกลับที่จำลองไว้ มันทำงานได้หลายโหมด รวมถึง capture, simulate, spy, modify, synthesize, และ diff
A basic capture-then-replay flow using its hoverctl command:
hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
admin API ของ Hoverfly ทำงานบนพอร์ต 8888 และ proxy ทำงานบนพอร์ต 8500 โดยค่าเริ่มต้น โมเดล proxy แบบบันทึกและเล่นซ้ำทำให้เหมาะอย่างยิ่งเมื่อคุณต้องการทำ virtualization กับทราฟฟิกที่มีอยู่ได้อย่างรวดเร็ว แทนที่จะเขียนการตอบกลับด้วยมือทุกครั้ง นอกจากนี้ยังมี Hoverfly Cloud แบบโฮสต์ให้เลือกใช้
Mountebank
Mountebank เป็นเครื่องมือโอเพนซอร์สที่สร้างขึ้นโดยใช้แนวคิด “imposters” Imposter คือบริการเสมือนเดียวที่ฟังบนพอร์ตเดียวและใช้โปรโตคอลเดียว นอกจาก HTTP และ HTTPS แล้ว Mountebank ยังรองรับ TCP และ SMTP ซึ่งมีประโยชน์เมื่อการพึ่งพาของคุณไม่ใช่แค่ REST API ธรรมดา คุณสามารถควบคุมมันได้อย่างสมบูรณ์ผ่าน REST control plane บนพอร์ต 2525
Install and start it:
npm install -g mountebank
mb
Then create an imposter by POSTing JSON to the control port:
curl -X POST http://localhost:2525/imposters \
-H "Content-Type: application/json" \
-d '{
"port": 4545,
"protocol": "http",
"stubs": [{
"predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }],
"responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
}]
}'
Predicates เป็นตัวตัดสินว่าคำขอใดตรงกัน; responses กำหนดว่าอะไรจะถูกส่งกลับไป ความสามารถในการรองรับหลายโปรโตคอลของ Mountebank คือจุดเด่นที่แตกต่างจากตัวเลือกโอเพนซอร์สอื่นๆ
Parasoft Virtualize และ Broadcom Service Virtualization
สำหรับองค์กรขนาดใหญ่ ตัวเลือกที่มีประสิทธิภาพสูงคือ Parasoft Virtualize และ Broadcom Service Virtualization (ซึ่งเป็นส่วนหนึ่งของ DevTest suite) เหล่านี้เป็นแพลตฟอร์มเชิงพาณิชย์ที่สร้างขึ้นสำหรับทีมที่ต้องการจำลองโปรโตคอลและรูปแบบข้อความจำนวนมากนอกเหนือจาก HTTP, เชื่อมต่อบริการเสมือนเข้ากับแหล่งข้อมูลจริง, และจัดการ virtualization ข้ามสภาพแวดล้อมหลายแห่งจากส่วนกลาง
Parasoft Virtualize โฆษณาว่ารองรับโปรโตคอลและรูปแบบข้อความมาตรฐานอุตสาหกรรมที่หลากหลาย รวมถึงบริการเสมือนที่ขับเคลื่อนด้วยข้อมูลที่ดึงมาจากแหล่งข้อมูลภายนอก ข้อเสนอของ Broadcom มุ่งเป้าไปที่สถานการณ์องค์กรที่คล้ายกัน ด้วยสภาพแวดล้อมเสมือนสำหรับการพัฒนาและทดสอบแบบคู่ขนาน ทั้งสองมีค่าใช้จ่ายใบอนุญาตและการตั้งค่าระดับองค์กร จึงเหมาะสมเมื่อคุณต้องการทำ virtualization กับโปรโตคอลเก่า (เช่น mainframe, MQ, ข้อความความยาวคงที่) ในขนาดใหญ่ แทนที่จะเป็น REST endpoints เพียงไม่กี่จุด หากการพึ่งพาของคุณเป็น HTTP API ทั่วไป เครื่องมือโอเพนซอร์สที่กล่าวมาข้างต้นหรือแพลตฟอร์ม API จะช่วยคุณได้ด้วยค่าใช้จ่ายที่น้อยกว่ามาก โปรดยืนยันรายการโปรโตคอลและราคาปัจจุบันกับผู้จำหน่ายแต่ละราย
Apidog: lightweight service virtualization สำหรับ API contracts
หากการพึ่งพาที่คุณต้องการทำ virtualization เป็น HTTP API ที่กำหนดโดย contract, Apidog สามารถจัดการส่วนนั้นได้โดยไม่ต้องใช้เครื่องมือแยกต่างหาก เมื่อคุณออกแบบหรือนำเข้า API, Apidog จะตั้งค่า mock server ให้โดยอัตโนมัติ Frontend หรือชุดทดสอบของคุณจะได้รับเอนด์พอยต์ที่ใช้งานได้จาก schema เพียงอย่างเดียว ก่อนที่โค้ด Backend จะมีอยู่ด้วยซ้ำ
สิ่งที่ทำให้สิ่งนี้ใกล้เคียงกับ virtualization มากกว่า stub ธรรมดา คือ mock ของ Apidog นั้นรับรู้ schema และเป็นแบบไดนามิก Smart Mock ของมันจะอ่าน JSON Schema ของคุณและสร้างการตอบกลับที่เคารพทุกข้อจำกัด (ประเภท, รูปแบบ, enum, ฟิลด์ที่จำเป็น) นอกจากนี้ยังจับคู่ชื่อฟิลด์กับกฎในตัว เพื่อให้ฟิลด์ชื่อ email ส่งคืนอีเมลที่ถูกต้องและฟิลด์ชื่อ city ส่งคืนชื่อเมือง แทนที่จะเป็นข้อมูลที่ไม่เกี่ยวข้อง สำหรับการควบคุมที่ละเอียดยิ่งขึ้น ค่าไดนามิกที่อิงตาม Faker.js จะสร้างข้อมูลที่สมจริงในการเรียกใช้แต่ละครั้ง และคุณสามารถกำหนดค่าที่แน่นอนในจุดที่คุณต้องการความแม่นยำ (determinism)
คุณยังสามารถเขียนกฎ mock แบบกำหนดเองที่ส่งคืนการตอบกลับที่แตกต่างกันตามพารามิเตอร์คำขอ ซึ่งเป็นพฤติกรรมการจับคู่คำขอที่แยก virtualization ออกจาก stub ที่คงที่ mock server สามารถทำงานใน GUI หรือแบบ headless ได้ จึงเหมาะสำหรับการพัฒนาในเครื่องและ CI ดู วิธี mock API ในหนึ่งนาที สำหรับคำแนะนำ
Apidog เหมาะกับกรณีใด: API-contract service virtualization สำหรับ HTTP/REST และสิ่งที่คล้ายกัน ไม่เหมาะกับกรณีใด: ไม่ใช่เครื่องมือบันทึกและเล่นซ้ำแบบ proxy-based สำหรับโปรโตคอลเก่าที่ไม่จำเพาะเจาะจง และไม่ใช่ตัวสร้างโหลด สำหรับกรณีเหล่านั้น เครื่องมือที่กล่าวมาข้างต้นคือตัวเลือกที่เหมาะสม สำหรับการเปรียบเทียบเครื่องมือแบบละเอียดเพิ่มเติม ดู การเปรียบเทียบเครื่องมือ API mocking ออนไลน์ และ 10 สุดยอดเครื่องมือ API mocking
วิธีการเริ่มต้น
เลือกเครื่องมือให้ตรงกับการพึ่งพา ไม่ใช่ในทางกลับกัน
- ระบุโปรโตคอล HTTP/REST ทั่วไป? เกือบทุกเครื่องมือที่นี่ใช้งานได้ และแพลตฟอร์ม API จะมีความยุ่งยากน้อยที่สุด ต้องการ TCP หรือ SMTP? Mountebank โปรโตคอลองค์กรเก่าขนาดใหญ่? Parasoft หรือ Broadcom
- ตัดสินใจว่าจะบันทึก (record) หรือระบุ (specify) หากบริการจริงมีอยู่และคุณสามารถส่งทราฟฟิกผ่านมันได้ การบันทึกและเล่นซ้ำ (Hoverfly, WireMock record mode) จะเร็วที่สุด หากยังไม่มีอยู่ ให้ขับเคลื่อนบริการเสมือนจาก API contract (Apidog, WireMock stubs, Mountebank imposters)
- ชี้แอปของคุณไปที่มัน เปลี่ยน base URL หรือการตั้งค่า proxy ในสภาพแวดล้อมการทดสอบหรือการพัฒนาของคุณ และเก็บสิ่งนั้นไว้หลัง config เพื่อให้การสลับระหว่าง virtual กับ real เป็นเพียงตัวแปรเดียว
- เพิ่มกรณีความล้มเหลว ผลตอบแทนคือการทดสอบเส้นทางข้อผิดพลาด ดังนั้นให้เพิ่มการตอบกลับสำหรับ 4xx และ 5xx, การหมดเวลา, และ body ที่ไม่ถูกต้อง นั่นคือส่วนที่การพึ่งพาจริงจะไม่ยอมให้คุณซ้อม
- รันใน CI บริการเสมือนที่รันบนแล็ปท็อปของคุณเท่านั้นช่วยคุณได้ แต่ไม่ช่วยการสร้าง (build) ใส่ไว้ใน pipeline เพื่อให้สีเขียวหมายถึงสำเร็จจริง หากคุณต้องการ mock ที่ทำงานแบบ headless ใน CI โดยไม่มี GUI ดู เครื่องมือ mock API แบบ headless
สำหรับข้อดีข้อเสียของการพึ่งพาแบบ virtual เทียบกับแบบ live โดยทั่วไป, mock server vs real server จะอธิบายว่าควรใช้แบบไหนเมื่อไหร่
คำถามที่พบบ่อย (FAQ)
Service virtualization เหมือนกับ mocking หรือไม่? ไม่เชิง Mocking มักจะแทนที่อ็อบเจกต์ภายในกระบวนการของคุณสำหรับการทดสอบหน่วย (unit tests) และตรวจสอบว่าถูกเรียกอย่างไร Service virtualization จะตั้งค่าบริการที่กำลังทำงานอยู่บนพอร์ตเครือข่ายที่แอปพลิเคชันของคุณเชื่อมต่อผ่านโปรโตคอลจริง ผู้คนมักเรียกบริการเสมือน HTTP ว่า “mocks” ในการใช้งานทั่วไป ซึ่งก็ไม่เป็นไร แต่ความแตกต่างทางเทคนิคคืออ็อบเจกต์ในกระบวนการเทียบกับบริการเครือข่าย
ฉันควรใช้บริการเสมือนเมื่อใด แทนที่จะใช้สภาพแวดล้อมการทดสอบจริง? ใช้ virtualization เมื่อการพึ่งพาจริงไม่พร้อมใช้งาน, ถูกจำกัดจำนวนการเรียกใช้ (rate-limited), มีราคาแพง, หรือควบคุมได้ยาก มันให้การตอบกลับที่กำหนดได้ (deterministic), ฟรี, ใช้งานได้ตลอดเวลา และช่วยให้คุณจำลองข้อผิดพลาดที่คุณไม่สามารถกระตุ้นบนระบบจริงได้ ควรเก็บชุดการทดสอบขนาดเล็กไว้เพื่อทดสอบกับบริการจริงสำหรับความมั่นใจในการบูรณาการขั้นสุดท้าย
บริการเสมือนสามารถมีสถานะ (stateful) ได้หรือไม่? ได้ เครื่องมืออย่าง WireMock และ Mountebank รองรับสถานการณ์แบบมีสถานะที่การตอบกลับเปลี่ยนแปลงไปตามคำขอก่อนหน้า ตัวอย่างเช่น การส่งคืนตะกร้าสินค้าว่างเปล่า จากนั้นเป็นตะกร้าสินค้าที่มีสินค้าหลังจากคำขอ POST สิ่งนี้สำคัญเมื่อคุณกำลังจำลองเวิร์กโฟลว์แทนที่จะเป็นการเรียกใช้ครั้งเดียว
ฉันจำเป็นต้องใช้เครื่องมือระดับองค์กรแบบมีค่าใช้จ่ายหรือไม่? เฉพาะในกรณีที่คุณกำลังทำ virtualization กับโปรโตคอลที่ไม่ใช่ HTTP จำนวนมาก หรือจัดการ virtualization ทั่วทั้งองค์กรขนาดใหญ่ สำหรับ HTTP API ทั่วไป เครื่องมือโอเพนซอร์ส (WireMock, Hoverfly, Mountebank) หรือ mock server ของแพลตฟอร์ม API ก็สามารถจัดการงานได้โดยไม่ต้องมีใบอนุญาตระดับองค์กร
วิธีที่เร็วที่สุดในการทำ virtualization สำหรับ HTTP API จาก spec คืออะไร? นำเข้าคำจำกัดความ API ไปยังเครื่องมือที่สร้าง mock จาก schema Apidog ทำสิ่งนี้โดยอัตโนมัติ: นำเข้า OpenAPI spec ของคุณแล้วคุณจะได้รับ mock server ที่รับรู้ schema พร้อมข้อมูลไดนามิกที่สมจริง โดยไม่จำเป็นต้องเขียนการตอบกลับเอง จากนั้นคุณสามารถเพิ่มกฎที่กำหนดเองสำหรับเงื่อนไขคำขอ/การตอบกลับที่การทดสอบของคุณต้องการ