สรุป
บริการจำลอง (mock services) ของ SoapUI จำลองปลายทาง SOAP หรือ REST ในเครื่องได้ แต่ต้องมีกระบวนการ Java ทำงานอยู่, การตั้งค่าการส่งข้อมูลด้วยตนเอง และไม่สามารถแชร์กับทีมได้หากไม่มีเครื่องที่ใช้ร่วมกัน Smart Mock ของ Apidog สร้างการตอบสนองจำลองจาก schema API ของคุณ ทำงานบนคลาวด์ และแชร์กับทีมของคุณได้โดยอัตโนมัติ
บทนำ
บริการจำลอง (Mock services) แก้ปัญหาทั่วไปในการพัฒนา API: คุณต้องการทดสอบว่าโค้ดไคลเอ็นต์ของคุณจัดการกับบริการอย่างไรก่อนที่บริการนั้นจะพร้อมใช้งาน หรือคุณต้องการทดสอบกรณีขอบ (ข้อผิดพลาด, การตอบสนองช้า) โดยไม่ก่อให้เกิดปัญหาในระบบจริง
คุณสมบัติบริการจำลองของ SoapUI มีมาตั้งแต่เวอร์ชันแรก ๆ และใช้งานได้ดี โดยจะรันเซิร์ฟเวอร์ HTTP ในเครื่องที่ตอบสนองต่อคำขอตามกฎที่คุณกำหนด ปัญหาคือกระบวนการในเครื่องนี้สร้างความยุ่งยาก: มันจะหยุดทำงานเมื่อคุณปิด SoapUI สมาชิกทีมคนอื่น ๆ ไม่สามารถเข้าถึงได้หากไม่มีการตั้งค่าเครือข่าย และอินเทอร์เฟซการตั้งค่ายุ่งยาก
คู่มือนี้จะครอบคลุมวิธีการทำงานของบริการจำลองของ SoapUI, วิธีการตั้งค่า, ปัญหาทั่วไปที่ทีมมักพบ และวิธีการของ Apidog เปรียบเทียบกับสิ่งเหล่านี้
บริการจำลองของ SoapUI ทำงานอย่างไร
SoapUI สร้างบริการจำลองจากอินเทอร์เฟซ SOAP หรือ REST ที่มีอยู่ในโปรเจกต์ของคุณ บริการจำลองจะ:
- รอการเชื่อมต่อบนพอร์ตในเครื่องที่คุณกำหนดค่า (เช่น
http://localhost:8088/MockService) - ดักจับคำขอที่เข้ามา
- จับคู่คำขอกับ "การตอบกลับจำลอง" โดยใช้ตรรกะการส่งข้อมูล
- ส่งคืนการตอบกลับที่กำหนดค่าไว้
สำหรับบริการ SOAP, SoapUI สามารถสร้างการตอบกลับจำลองจาก WSDL ของคุณได้โดยอัตโนมัติ โดยสร้างการตอบกลับแบบ stub สำหรับแต่ละ operation สิ่งนี้มีประโยชน์สำหรับการจำลองบริการก่อนที่จะมีอยู่จริง หรือก่อนที่คุณจะเข้าถึงปลายทางจริงได้
การตั้งค่าบริการจำลองของ SoapUI (ทีละขั้นตอน)
สำหรับอินเทอร์เฟซ SOAP
- ในโปรเจกต์ SoapUI ของคุณ คลิกขวาที่อินเทอร์เฟซ SOAP ในโครงสร้างโปรเจกต์
- เลือก “Generate MockService.”
- ในกล่องโต้ตอบ ให้กำหนดค่า:
- ชื่อบริการ (เช่น “OrderService Mock”)
- หมายเลขพอร์ต (ค่าเริ่มต้นคือ 8088; เปลี่ยนหากพอร์ตนั้นถูกใช้งานอยู่)
- พาธ (เช่น
/orders)
- คลิก OK. SoapUI จะสร้างโหนด MockService ในโครงสร้างโปรเจกต์ของคุณ
- ขยายโหนด MockService คุณจะเห็น “MockOperation” สำหรับแต่ละ operation ของ SOAP ในอินเทอร์เฟซ
- ดับเบิลคลิกที่ MockOperation เพื่อเปิดตัวแก้ไขการตอบกลับจำลอง
- แก้ไข XML การตอบกลับ SOAP เพื่อส่งคืนค่าที่คุณต้องการจำลอง
- คลิกปุ่มเล่นสีเขียวในตัวแก้ไข MockService เพื่อเริ่มเซิร์ฟเวอร์ในเครื่อง
บริการจำลองของคุณกำลังทำงานอยู่ที่ http://localhost:8088/orders ตอนนี้ ชี้โค้ดไคลเอนต์ของคุณไปที่ URL นี้
สำหรับอินเทอร์เฟซ REST
- คลิกขวาที่อินเทอร์เฟซ REST หรือทรัพยากรในโครงสร้างโปรเจกต์
- เลือก “Add to MockService” หรือ “Generate MockService.”
- กำหนดค่าพอร์ตและพาธตามข้างต้น
- สำหรับแต่ละทรัพยากร/เมธอด ให้กำหนดค่าเนื้อหาการตอบกลับจำลองและรหัสสถานะ
- เริ่มบริการจำลอง
การกำหนดค่าการส่งข้อมูล (dispatch)
โดยค่าเริ่มต้น บริการจำลองของ SoapUI จะส่งคืนการตอบกลับจำลองแรกที่พบ หากคุณต้องการการตอบกลับที่แตกต่างกันสำหรับอินพุตที่ต่างกัน ให้กำหนดค่า "สคริปต์การส่งข้อมูล" (Groovy) หรือใช้ประเภทการส่งข้อมูลแบบ "SEQUENCE"
การส่งข้อมูลแบบ Sequence: ส่งคืนการตอบกลับตามลำดับที่กำหนดในการเรียกติดต่อกัน การเรียกครั้งที่ 1 ได้รับการตอบกลับ A, การเรียกครั้งที่ 2 ได้รับการตอบกลับ B
การส่งข้อมูลแบบ SCRIPT: สคริปต์ Groovy ตรวจสอบคำขอและส่งคืนชื่อการตอบกลับตามตรรกะ
ตัวอย่างสคริปต์การส่งข้อมูล:
def request = mockRequest.getRequestContent()
if (request.contains("orderId>12345")) {
return "OrderFoundResponse"
} else {
return "OrderNotFoundResponse"
}
คุณสร้างการตอบกลับจำลองที่มีชื่อหลายรายการ (เช่น “OrderFoundResponse,” “OrderNotFoundResponse”) และสคริปต์การส่งข้อมูลจะเลือกรายการใดที่จะส่งคืนตามเนื้อหาคำขอที่เข้ามา
ปัญหาทั่วไปของบริการจำลอง SoapUI
ปัญหาที่ 1: บริการจำลองหยุดทำงานเมื่อปิด SoapUI
บริการจำลองของ SoapUI ทำงานเป็นส่วนหนึ่งของกระบวนการ JVM ของ SoapUI เมื่อคุณปิด SoapUI บริการจำลองจะหยุดทำงาน เพื่อนร่วมทีมที่กำลังใช้บริการจำลองนั้นก็จะเข้าถึงไม่ได้
วิธีแก้ไขเฉพาะหน้า:
- เปิด SoapUI ทิ้งไว้บนเครื่องเฉพาะหรือ VM
- ใช้ตัวเลือกเซิร์ฟเวอร์จำลองผ่านคอมมานด์ไลน์ของ SoapUI:
mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml - ใช้เครื่องที่ใช้ร่วมกันแบบถาวรที่รันบริการจำลองอยู่เสมอ
ไม่มีวิธีใดที่ดูดี ตัวเลือกคอมมานด์ไลน์ช่วยได้ แต่ก็ยังต้องใช้เครื่องที่ติดตั้ง SoapUI และ Java
ปัญหาที่ 2: การแชร์บริการจำลองกับทีม
บริการจำลองบน localhost:8088 สามารถเข้าถึงได้เฉพาะผู้ที่รันมันเท่านั้น หากเพื่อนร่วมทีมต้องการเข้าถึงบริการจำลองเดียวกัน คุณจะต้องเข้าถึงเครือข่ายของเครื่องนั้น (กฎไฟร์วอลล์, การตั้งค่า VPN) หรือรันบริการจำลองบนเซิร์ฟเวอร์ที่ใช้ร่วมกัน
ปัญหาที่ 3: สคริปต์การส่งข้อมูลพังเมื่อเจอ XML ที่ซับซ้อน
สคริปต์การส่งข้อมูลของ SoapUI ใช้การจับคู่สตริง Groovy บนเนื้อหา XML ดิบ SOAP envelopes มี namespace และค่าตรรกะเดียวกันสามารถปรากฏพร้อมกับ prefix ของ namespace ที่แตกต่างกันขึ้นอยู่กับไคลเอนต์ สคริปต์ที่ค้นหาสตริงตามตัวอักษร เช่น <orderId>12345</orderId> จะพังเมื่อ prefix แตกต่างกัน
การแก้ไขต้องมีการแยกวิเคราะห์ XML ที่ถูกต้องในสคริปต์การส่งข้อมูลโดยใช้คลาส GroovyUtils ของ SoapUI ซึ่งเพิ่มความซับซ้อน
ปัญหาที่ 4: สถานะไม่คงอยู่ระหว่างการเรียก
บริการจำลองของ SoapUI เป็นแบบไร้สถานะโดยค่าเริ่มต้น หากคุณต้องการจำลองเวิร์กโฟลว์สร้างแล้วอ่าน (POST เพื่อสร้าง, GET เพื่อเรียกข้อมูล) คุณต้องมีสคริปต์การส่งข้อมูล Groovy ที่เก็บสถานะไว้ในตัวแปรที่ใช้ร่วมกัน ซึ่งใช้งานได้แต่มีความเปราะบาง
ปัญหาที่ 5: SSL สำหรับบริการจำลอง
การกำหนดค่า HTTPS สำหรับบริการจำลอง SoapUI ต้องมีการตั้งค่า keystore, การกำหนดค่าการตั้งค่า SSL ของ SoapUI และการชี้ไคลเอนต์ไปยังใบรับรองที่ถูกต้อง ซึ่งซับซ้อนกว่าบริการจำลองแบบ HTTP อย่างมาก
Apidog Smart Mock: เปรียบเทียบกันอย่างไร
วิธีการจำลองของ Apidog เริ่มต้นจากการออกแบบ API ไม่ใช่จากกระบวนการที่กำลังทำงานอยู่
เมื่อคุณกำหนด API endpoint ใน Apidog (เมธอด, พาธ, request schema, response schema), Apidog จะสร้าง mock endpoint บนคลาวด์โดยอัตโนมัติ ไม่ต้องมีการตั้งค่าใดๆ
URL ของบริการจำลองจะมีลักษณะดังนี้: https://{your-project}.mock.apidog.io/orders/{id}
URL นี้คือ:
- ทำงานอยู่เสมอ (ไม่มีกระบวนการในเครื่องที่ต้องเริ่มหรือหยุด)
- เข้าถึงได้สำหรับสมาชิกทีมทุกคนที่เข้าถึงโปรเจกต์
- สร้างการตอบกลับจาก schema ที่คุณกำหนด
Apidog สร้างการตอบกลับจำลองได้อย่างไร
Apidog อ่าน response schema ของคุณ (JSON Schema หรือ OpenAPI response definition) และสร้างข้อมูลปลอมที่สมจริง schema ที่ระบุว่า orderId เป็น string ในรูปแบบ UUID จะส่งคืน UUID แบบสุ่ม schema ที่ระบุว่า amount เป็น number ระหว่าง 0 ถึง 10000 จะส่งคืนตัวเลขในช่วงนั้น
คุณยังสามารถกำหนดค่ากฎการจำลองแบบกำหนดเองสำหรับฟิลด์เฉพาะได้ ตั้งค่า orderId ให้ส่งคืน "test-123" เสมอเมื่อคุณต้องการค่าที่คาดเดาได้
ปลายทาง SOAP ใน Apidog Mock
Smart Mock ของ Apidog ได้รับการออกแบบมาสำหรับปลายทาง REST ที่มีการตอบกลับ JSON สำหรับปลายทาง SOAP การตั้งค่าบริการจำลองเป็นแบบแมนนวล: คุณสร้างคำขอใน Apidog, กำหนดค่าการตอบกลับแบบกำหนดเองด้วย SOAP envelope และใช้เซิร์ฟเวอร์จำลองของ Apidog เพื่อส่งคืน
สิ่งนี้นับว่ามีระบบอัตโนมัติน้อยกว่าการสร้างบริการจำลองแบบ WSDL ของ SoapUI แต่ใช้งานได้สำหรับทีมที่ต้องการบริการจำลอง SOAP แบบง่ายๆ โดยไม่ต้องเรียกใช้กระบวนการ Java ในเครื่อง
การจำลองแบบมีสถานะ (Stateful mocking)
Apidog รองรับสคริปต์การตอบกลับแบบกำหนดเองสำหรับพฤติกรรมการจำลองแบบมีสถานะ คุณสามารถตรวจสอบเนื้อหาคำขอในสคริปต์จำลอง JavaScript และส่งคืนการตอบกลับที่แตกต่างกันตามเนื้อหาคำขอ คล้ายกับสคริปต์การส่งข้อมูลของ SoapUI แต่เป็นใน JavaScript
การเปรียบเทียบแบบเคียงข้างกัน
| คุณสมบัติ | SoapUI Mock | Apidog Smart Mock |
|---|---|---|
| ต้องใช้ Java | ใช่ | ไม่ |
| ทำงานตลอดเวลา | เฉพาะเมื่อใช้ command-line runner | ใช่ (คลาวด์) |
| เข้าถึงได้โดยทีม | การตั้งค่าเครือข่ายด้วยตนเอง | ใช่, ผ่าน URL ที่แชร์ได้ |
| การสร้าง WSDL อัตโนมัติ | ใช่ | ไม่ |
| อิงตาม REST schema | ไม่ | ใช่ |
| การตอบกลับแบบไดนามิก | Groovy dispatch | สคริปต์จำลอง JavaScript |
| รองรับ HTTPS | การตั้งค่า keystore ด้วยตนเอง | มีในตัว |
| การจำลองแบบมีสถานะ | ผ่านตัวแปร Groovy | ผ่านสคริปต์ JavaScript |
| ฟรี | ใช่ | ใช่ |
เมื่อใดควรใช้แต่ละอย่าง
ใช้บริการจำลอง SoapUI เมื่อ:
- คุณต้องการจำลองบริการ SOAP ที่อิงตาม WSDL และต้องการ stub response ที่สร้างขึ้นโดยอัตโนมัติ
- ทีมของคุณทำงานแบบออฟไลน์หรืออยู่เบื้องหลังการควบคุมเครือข่ายที่เข้มงวด
- คุณใช้ระบบนิเวศของ SoapUI มานานแล้วและไม่ต้องการเปลี่ยนเครื่องมือ
ใช้ Apidog Smart Mock เมื่อ:
- ทีมของคุณจำลองปลายทาง REST และต้องการการเข้าถึงร่วมกันโดยไม่ต้องตั้งค่าเครือข่าย
- คุณต้องการเซิร์ฟเวอร์จำลองที่ทำงานอยู่เสมอโดยไม่ต้องมีการแทรกแซงด้วยตนเอง
- คุณกำลังเริ่มต้นโปรเจกต์ใหม่และกำหนด API contract ก่อนการใช้งานจริง
- คุณต้องการหลีกเลี่ยงการติดตั้งและดูแลรักษาสภาพแวดล้อม Java สำหรับบริการจำลอง
คำถามที่พบบ่อย
ฉันสามารถรันบริการจำลอง SoapUI โดยไม่ใช้ GUI ได้หรือไม่?ได้ SoapUI มี mockservicerunner.sh (Linux/macOS) และ mockservicerunner.bat (Windows) รันด้วยพาธไฟล์โปรเจกต์และชื่อบริการ คุณยังคงต้องติดตั้ง Java แต่ไม่จำเป็นต้องเปิด GUI
Apidog รองรับบริการจำลอง SOAP หรือไม่?บางส่วน คุณสามารถกำหนดค่าการตอบกลับแบบกำหนดเองด้วย SOAP XML ในเซิร์ฟเวอร์จำลองของ Apidog คุณจะไม่ได้รับการสร้าง stub response อัตโนมัติแบบ WSDL สำหรับทีมที่มีอินเทอร์เฟซ SOAP ที่เข้าใจได้ดี การตั้งค่าด้วยตนเองก็สามารถจัดการได้
บริการจำลอง SoapUI สามารถจำลองการตอบสนองที่ช้าได้หรือไม่?ได้ ในการกำหนดค่าการตอบกลับจำลอง ให้ตั้งค่า "Delay" เป็นมิลลิวินาที Apidog ยังรองรับการกำหนดค่าการหน่วงเวลาการตอบกลับเพื่อจำลองสภาพเครือข่ายที่ช้า
Apidog จัดการคำขอจำลองได้กี่รายการ?เซิร์ฟเวอร์จำลองบนคลาวด์ของ Apidog สามารถจัดการโหลดการพัฒนาและการทดสอบทั่วไปได้ สำหรับการทดสอบประสิทธิภาพที่มีปริมาณมาก เครื่องมือเซิร์ฟเวอร์จำลองเฉพาะอาจเหมาะสมกว่า
จะเกิดอะไรขึ้นหากสมาชิกทีมสองคนต้องการการตอบกลับจำลองที่แตกต่างกันสำหรับปลายทางเดียวกัน?ใน SoapUI แต่ละคนจะรันบริการจำลองในเครื่องของตนเองและสามารถกำหนดค่าได้อย่างอิสระ ใน Apidog คุณสามารถสร้างสภาพแวดล้อมหลายแบบหรือใช้พารามิเตอร์การสอบถามเพื่อเลือกสถานการณ์การตอบกลับที่แตกต่างกัน คุณสมบัติ "Mock expects" ของ Apidog ช่วยให้คุณสามารถจับคู่เงื่อนไขคำขอเฉพาะกับการตอบกลับเฉพาะ
บริการจำลองของ Apidog ต้องการให้ API ถูกกำหนดไว้ทั้งหมดก่อนหรือไม่?response schema ช่วยให้ Apidog สร้างข้อมูลที่สมจริงได้ แต่คุณสามารถสร้างการตอบกลับจำลองด้วยตนเองโดยไม่ต้องมี schema ที่สมบูรณ์ กำหนดปลายทาง ตั้งค่าเนื้อหาการตอบกลับแบบกำหนดเอง และบริการจำลองก็จะทำงานได้
บริการจำลองของ SoapUI ใช้งานได้แต่ผูกติดกับกระบวนการ Java ในเครื่อง สำหรับทีมสมัยใหม่ที่ต้องการบริการจำลองที่คงอยู่และแชร์ได้ วิธีการบนคลาวด์ของ Apidog ช่วยลดภาระในการประสานงาน