Smart mock ช่วยให้คุณได้ API ปลอมภายในไม่กี่วินาที มันจะอ่าน Schema ของ Endpoint ของคุณและส่งข้อมูลที่เป็นไปได้กลับมาให้: อีเมลที่ดูเหมือนจริง, Timestamp ที่สมเหตุสมผล, ชื่อที่ไม่ใช่ xJ8kQ. สำหรับงานส่วน Frontend ส่วนใหญ่ แค่นั้นก็เพียงพอแล้วที่จะช่วยให้คุณทำงานต่อได้
จากนั้นคุณจะเจอกรณีที่ Smart mock ไม่สามารถทำได้ คุณต้องการให้ /login ส่งคืน 200 สำหรับผู้ใช้ที่รู้จัก และ 401 ในกรณีอื่น ๆ คุณต้องการให้ /orders/{id} ส่งคืนคำสั่งซื้อที่จัดส่งแล้วสำหรับ ID หนึ่ง และคำสั่งซื้อที่ยกเลิกแล้วสำหรับอีก ID หนึ่ง คุณต้องการบังคับให้เกิด 500 ตามต้องการ เพื่อให้การจัดการข้อผิดพลาดของคุณได้รับการทดสอบก่อนที่จะเข้าสู่การใช้งานจริง Smart mock ส่งคืนรูปแบบเดียวต่อ Endpoint ดังนั้นจึงไม่สามารถแตกแขนงตามคำขอได้ นี่คือช่องว่างที่คู่มือนี้จะเข้ามาอุด
Apidog ครอบคลุมสิ่งนี้ด้วยสองคุณสมบัติ: mock expectations สำหรับการตอบกลับแบบมีเงื่อนไขตามกฎ และ mock scripts สำหรับตรรกะที่กฎไม่สามารถแสดงออกได้ คู่มือนี้จะแสดงทั้งสองอย่างพร้อมตัวอย่างที่เป็นรูปธรรม และอธิบายลำดับความสำคัญเพื่อให้กฎที่คุณกำหนดเองมีชัยเหนือ Smart mock เสมอ หากคุณยังใหม่กับพื้นฐาน ภาพรวมการจำลอง API เป็นการอุ่นเครื่องที่ดี และ Apidog คือเครื่องมือที่เราจะใช้ตลอดทั้งคู่มือนี้ OpenAPI Initiative ได้จัดทำเอกสารเกี่ยวกับเวิร์กโฟลว์แบบ contract-first ที่ทำให้ทั้งหมดนี้เป็นไปได้
การจำลองแบบมีเงื่อนไขหมายความว่าอย่างไร
การจำลองแบบมีเงื่อนไขคือกฎ: เมื่อคำขอที่เข้ามามีลักษณะ เช่นนี้ ให้ส่งคืน สิ่งนั้น. Apidog สร้างกฎเหล่านี้จากสองชั้น
ชั้นแรกคือการปรับแต่งระดับฟิลด์ภายใน Schema ของ Endpoint คุณกำหนดฟิลด์ให้มีค่าคงที่ หรือคุณแนบ expression แบบไดนามิกของ Faker.js เพื่อให้ค่าเปลี่ยนแปลงไปในทุกการเรียกใช้ สิ่งนี้จะควบคุม สิ่งที่ฟิลด์มีอยู่ แต่ก็ยังคงส่งคืนรูปแบบการตอบกลับเดียวสำหรับ Endpoint
ชั้นที่สองคือ mock expectation สำหรับการตอบกลับแบบเต็ม รูปแบบของ expectation คือกฎที่มีชื่อพร้อมเงื่อนไขเสริมและมีเนื้อหาการตอบกลับ, รหัสสถานะ (status code) และส่วนหัว (headers) ของตัวเอง expectation ที่ไม่มีเงื่อนไขจะส่งคืนข้อมูลที่ตายตัวโดยไม่มีเงื่อนไข expectation ที่มีเงื่อนไขจะส่งคืนข้อมูลของตนเองเมื่อคำขอตรงกับเงื่อนไขเท่านั้น การเรียงซ้อนกันหลาย ๆ อย่างนี้จะทำให้เกิดการแตกแขนงจริง ๆ: การตอบกลับ B เมื่อคำขอตรงกับเงื่อนไข A, เนื้อหาข้อผิดพลาดเมื่อส่วนหัวหายไป, หรือ Payload ที่แตกต่างกันไปตาม Path Parameter
ชั้นที่สองนั้นทำให้สถานะข้อผิดพลาดตามต้องการและเนื้อหาการตอบกลับต่อคำขอเป็นไปได้ ส่วนที่เหลือของคู่มือนี้จะเน้นไปที่ส่วนนี้
ค่าไดนามิกในระดับฟิลด์เป็นอันดับแรก
ก่อนที่จะมีการแตกแขนง จะเป็นประโยชน์ที่จะได้เห็นว่าฟิลด์เดียวได้รับค่าอย่างไร เนื่องจากคุณจะนำไวยากรณ์เดียวกันนี้กลับมาใช้ในการตอบกลับแบบมีเงื่อนไขของคุณ
ภายใน Schema ของ Endpoint ฟิลด์สตริงใด ๆ สามารถเก็บ expression ของ Faker.js ที่เขียนในรูปแบบ {{$category.method}} ได้ Apidog จะแก้ไขค่านี้ใหม่ทุกครั้งที่มีการเรียกใช้ Mock โดยใช้ประเภทฟิลด์ที่ JSON Schema ของคุณได้ประกาศไว้แล้ว
{
"id": "{{$number.int(min=1000,max=9999)}}",
"customer": "{{$person.fullName}}",
"email": "{{$internet.email}}",
"product": "{{$commerce.productName}}",
"shippingAddress": "{{$location.streetAddress}}, {{$location.city}}",
"orderedAt": "{{$date.between(from='2024-01-01',to='2024-12-31',format='yyyy-MM-dd')}}"
}
เมธอดแบบ Parameterized ทำงานได้ ดังนั้น {{$number.int(min=1000,max=9999)}} จะกำหนดขอบเขตของค่า และ {{$date.between(...)}} จะกำหนดช่วงและรูปแบบ คุณสามารถเชื่อมข้อความคงที่และหลาย expression ในฟิลด์เดียวได้ ซึ่งเป็นวิธีที่ที่อยู่ด้านบนถูกสร้างขึ้น หากคุณต้องการข้อมูลเฉพาะภูมิภาค Apidog รองรับ mock locales ที่ปรับแต่งได้ เพื่อให้ชื่อ ที่อยู่ และหมายเลขโทรศัพท์ของคุณตรงกับภาษาหรือประเทศที่กำหนด เอกสารอ้างอิง Faker.js ใน Apidog ครอบคลุมแคตตาล็อกเมธอดทั้งหมด
นี่คือขอบเขตของ Smart mock มันเป็นแบบไดนามิก แต่ไม่ใช่แบบมีเงื่อนไข ในการแตกแขนงตามคำขอ คุณจะต้องไปที่ expectations
ตัวอย่าง: Endpoint สำหรับการเข้าสู่ระบบที่ส่งคืน 200 หรือ 401
กรณีที่เป็นไปได้ที่สุด: POST /login รับ JSON Body ที่มี username และ password. ผู้ใช้ที่รู้จักควรได้รับ 200 พร้อมโทเค็น คนอื่น ๆ ควรได้รับ 401.
เปิดแท็บที่ถูกต้อง
ตำแหน่งที่คุณกำหนดค่านี้ขึ้นอยู่กับโหมดการทำงานของคุณ:
- ในโหมด DEBUG (Request-first) ให้เปิด Endpoint แล้วคลิกแท็บ Mock.
- ในโหมด DESIGN (Design-first) ให้เปิด Endpoint แล้วคลิกแท็บ Advanced mock.
ทั้งสองวิธีจะนำไปสู่รายการ expectation เดียวกัน หากคุณต้องการทำตามและยังไม่มีแอป ให้ ดาวน์โหลด Apidog และนำเข้าหรือสร้าง Endpoint /login ก่อน
เพิ่ม expectation สำหรับความสำเร็จ
คลิก New expectation. ตั้ง ชื่อ expectation เช่น login-success. จากนั้นเพิ่มเงื่อนไข เนื่องจาก username อยู่ในเนื้อหาคำขอ JSON คุณจึงจับคู่เป็นพารามิเตอร์ Body: ใส่ JSON path ของคุณสมบัติเป้าหมาย username ลงในช่องชื่อ และตั้งค่าเงื่อนไขให้เท่ากับ alice@example.com.
เงื่อนไขพารามิเตอร์ Body เป็น JSON เท่านั้น และจะถูกจับคู่ผ่าน JSON path ในช่องชื่อ ดังนั้นคุณสมบัติที่ซ้อนกันจะใช้ dot paths เช่น user.email. กรอก Response data ด้วย Payload ที่สำเร็จ:
{
"token": "mock-jwt-{{$string.uuid}}",
"user": {
"id": 4821,
"username": "alice@example.com",
"role": "member"
}
}
บันทึก. HTTP Status Code เริ่มต้นคือ 200 ดังนั้นคุณไม่จำเป็นต้องแก้ไขอะไรเพิ่มเติมสำหรับเส้นทางที่สำเร็จ (happy path)
เพิ่ม expectation สำหรับความล้มเหลว
คลิก New expectation อีกครั้ง ตั้งชื่อว่า login-failure และปล่อยเงื่อนไขว่างไว้เพื่อให้ทำหน้าที่เป็นตัวจับทุกกรณี (catch-all). ตั้งค่า Response data เป็นเนื้อหาข้อผิดพลาด:
{
"error": "invalid_credentials",
"message": "Username or password is incorrect."
}
อันนี้ต้องใช้สถานะที่ไม่ใช่ค่าเริ่มต้น เปิดแท็บ More ของ expectation และตั้งค่า HTTP Status Code เป็น 401. ขณะที่คุณอยู่ที่นั่น โปรดทราบว่าแท็บ More ยังเป็นที่ที่คุณสามารถตั้งค่า Response Delay เป็นมิลลิวินาที (ค่าเริ่มต้นคือ 0) และส่วนหัวการตอบกลับที่กำหนดเองได้ การหน่วงเวลา 400 มิลลิวินาทีเป็นวิธีที่ง่ายเพื่อให้แน่ใจว่า Loading Spinner ของคุณแสดงผลได้จริง
ลำดับมีความสำคัญ
Expectations จะถูกประเมินจากบนลงล่าง และเงื่อนไขที่ตรงกันอันแรกจะเป็นผู้ชนะ ดังนั้น login-success ต้องอยู่ เหนือ login-failure. คำขอที่มี username เท่ากับ alice@example.com จะตรงกับกฎแรกและส่งคืนโทเค็น ส่วนอื่น ๆ จะผ่านไปที่กฎความล้มเหลวที่ไม่มีเงื่อนไขและได้รับ 401. หากคุณกลับลำดับ กฎที่ไม่มีเงื่อนไขจะตรงกับทุกอย่างและกรณีความสำเร็จของคุณจะไม่มีทางเกิดขึ้น
คัดลอก mock URL จาก Endpoint และทดสอบทั้งสองเส้นทาง:
# known user -> 200 with a token
curl -X POST https://<your-mock-host>/login \
-H "Content-Type: application/json" \
-d '{"username":"alice@example.com","password":"whatever"}'
# anyone else -> 401
curl -X POST https://<your-mock-host>/login \
-H "Content-Type: application/json" \
-d '{"username":"stranger@example.com","password":"whatever"}'
ตัวอย่าง: เนื้อหาการตอบกลับที่แตกต่างกันสำหรับ /orders/{id} ตามสถานะ
กรณีทั่วไปที่สองคือการแตกแขนงตาม Path Parameter คุณต้องการให้ /orders/{id} ส่งคืนคำสั่งซื้อที่จัดส่งแล้วสำหรับ ID หนึ่ง และคำสั่งซื้อที่ยกเลิกแล้วสำหรับอีก ID หนึ่ง เพื่อให้ UI ของคุณสามารถแสดงผลทุกสถานะได้โดยไม่ต้องมี Backend ที่ทำงานจริง
สร้าง expectation หนึ่งรายการต่อสถานะ สำหรับแต่ละรายการ ให้เพิ่มเงื่อนไขบน Path Parameter id จากนั้นกรอก Response data ที่ตรงกัน
Expectation order-shipped, เงื่อนไข: Path Parameter id เท่ากับ 5001.
{
"id": 5001,
"status": "shipped",
"total": 129.90,
"trackingNumber": "1Z{{$string.alphanumeric(length=16)}}",
"shippedAt": "{{$date.recent(days=3,format='yyyy-MM-dd')}}"
}
Expectation order-cancelled, เงื่อนไข: Path Parameter id เท่ากับ 5002.
{
"id": 5002,
"status": "cancelled",
"total": 0,
"cancelledAt": "{{$date.recent(days=1,format='yyyy-MM-dd')}}",
"refundIssued": true
}
เพิ่ม expectation สุดท้ายที่ไม่มีเงื่อนไข ซึ่งจะส่งคืนคำสั่งซื้อที่รอดำเนินการทั่วไป เพื่อให้ ID อื่น ๆ ยังคงได้รับการตอบกลับที่ถูกต้องแทนที่จะไม่มีการจับคู่ใด ๆ จัดเรียงกฎเฉพาะไว้เหนือ catch-all, บันทึก, และคุณก็จะมี Mock ที่แสดงผลทุกสถานะของคำสั่งซื้อตามต้องการ การผสมเงื่อนไขก็ใช้ได้เช่นกัน: เพิ่มเงื่อนไข Header ควบคู่ไปกับเงื่อนไข Path และทั้งสองต้องเป็นจริง เนื่องจาก Apidog รวมเงื่อนไขหลายรายการด้วยตรรกะ AND (การรวมกันของเงื่อนไข ตามคำศัพท์ในเอกสาร)
เงื่อนไขไม่ได้จำกัดอยู่แค่ Body และ Path คุณสามารถจับคู่กับ Query Parameter, Header Parameter, Cookie Parameter และแม้กระทั่งที่อยู่ IP ซึ่งช่วยให้คุณสามารถจำกัดการตอบกลับไปยัง Client เฉพาะในระหว่างการทดสอบได้
การบังคับสถานะข้อผิดพลาดตามต้องการ
คุณไม่จำเป็นต้องมี Backend ที่เสียเพื่อทดสอบการตอบกลับที่ผิดพลาด expectation พร้อมกับแท็บ More จะให้สถานะใดก็ได้ที่คุณต้องการ
ในการบังคับให้เกิด 500 ให้เพิ่ม expectation ที่มีเงื่อนไขที่คุณสามารถควบคุมได้จาก Client เช่น Header X-Mock-Scenario เท่ากับ server-error. ตั้งค่า Response data เป็น Body ข้อผิดพลาดที่สมจริง และ HTTP Status Code เป็น 500 ในแท็บ More
{
"error": "internal_error",
"requestId": "{{$string.uuid}}",
"message": "Something went wrong on our end. Please retry."
}
ตอนนี้ Endpoint เดียวกันจะให้บริการ 200 ตามปกติโดยค่าเริ่มต้น และ 500 เมื่อใดก็ตามที่คุณส่ง Header นั้น ทำเช่นเดียวกันสำหรับ 404, 429 (พร้อมกับ Header Retry-After ที่ตั้งค่าไว้ในแท็บ More) หรือ 503. การจัดการข้อผิดพลาดใน Frontend ของคุณในที่สุดก็มีสิ่งที่ต้องจับได้ หากคุณยืนยันการตอบกลับเหล่านี้ในการตรวจสอบอัตโนมัติ คู่มือ API assertions จะเข้ากันได้ดีกับการตั้งค่านี้
รายละเอียดหนึ่งสำหรับโปรเจกต์ที่แชร์กัน: แต่ละ expectation สามารถเปิดหรือปิดได้อย่างอิสระสำหรับสภาพแวดล้อม Mock ทั้งแบบ Local และ Cloud จากรายการ expectation ดังนั้นคุณจึงสามารถรักษากฎ 500 ให้ทำงานในเครื่องได้ ในขณะที่ปิดใช้งานใน Cloud Mock ที่เพื่อนร่วมทีมของคุณใช้งาน
เมื่อกฎไม่เพียงพอ: Mock scripts
Expectations เป็นแบบ Declarative คือมันจะจับคู่และส่งคืนค่า แต่ไม่สามารถคำนวณได้ เมื่อคุณต้องการฟิลด์ที่ได้มาจากคำขอ, ยอดรวมที่ได้จากรายการสินค้า, หรือ Body ที่เปลี่ยนรูปแบบตามข้อมูลหลายอย่างพร้อมกัน คุณจะใช้ Mock script
Mock script คือ JavaScript ที่ทำงานกับการตอบกลับของ Mock มันจะอยู่ใน Mock Script section ที่ด้านล่างของแท็บ Mock และเปิดใช้งานด้วยสวิตช์ Script จะเปิดเผยสองตัวแปร Global:
$$.mockRequest: อ่านคำขอที่เข้ามาผ่านgetParam(key)รวมถึงheaders,cookies,body,formdata, และurlencoded.$$.mockResponse: กำหนดรูปแบบการตอบกลับขาออกผ่านsetBody(),setCode(),setDelay(),json(), และคุณสมบัติheadersกับcode.
นี่คือ Script ที่คำนวณยอดรวมคำสั่งซื้อจากรายการสินค้าที่ส่งมา และสะท้อน Header สกุลเงินของผู้เรียกกลับไป:
const body = $$.mockRequest.body;
const items = body.items || [];
const subtotal = items.reduce((sum, item) => {
return sum + item.price * item.quantity;
}, 0);
const currency = $$.mockRequest.headers["x-currency"] || "USD";
$$.mockResponse.setCode(201);
$$.mockResponse.setBody({
orderId: Math.floor(Math.random() * 90000) + 10000,
currency: currency,
subtotal: subtotal,
tax: Number((subtotal * 0.08).toFixed(2)),
total: Number((subtotal * 1.08).toFixed(2))
});
ขั้นตอนคือ: Smart mock สร้างการตอบกลับเริ่มต้น, Script ของคุณอ่าน $$.mockRequest และ $$.mockResponse ปัจจุบัน, ใช้ตรรกะของมัน, เรียกใช้ $$.mockResponse.setBody() (และ setCode, setDelay, หรือ headers ตามความจำเป็น), และ Engine จะส่งคืนผลลัพธ์สุดท้าย เอกสารอ้างอิง MDN JavaScript เป็นคู่หูที่ยอดเยี่ยมหากคุณต้องการผลักดันตรรกะให้ก้าวหน้ายิ่งขึ้นด้วยเมธอด Array หรือการคำนวณวันที่
กฎข้อเดียวที่ทำให้คนสับสน
Mock scripts ทำงานได้กับ Smart mock เท่านั้น ไม่สามารถใช้กับ Mock expectations หรือ Response examples ได้ นี่คือสิ่งสำคัญที่สุดที่ต้องจำไว้: คุณไม่สามารถรวม Mock script เข้ากับการตอบกลับที่อิงตาม expectation ได้ หาก expectation ตรงกับคำขอ Script จะไม่ทำงานเลย ดังนั้นให้เลือกวิธีใดวิธีหนึ่งต่อ Endpoint ใช้ expectations เมื่อคุณต้องการแตกแขนงตามเงื่อนไขที่กำหนดและส่งคืน Body ที่ตายตัว ใช้ Mock script เมื่อคุณต้องการ Output ที่คำนวณได้จากฐานที่ Smart mock สร้างขึ้น
ลำดับความสำคัญถูกแก้ไขอย่างไร
เมื่อรวมทั้งหมดเข้าด้วยกัน นี่คือลำดับที่ Apidog ดำเนินการสำหรับคำขอ Mock ใด ๆ:
- จะตรวจสอบ Expectations ของคุณจากบนลงล่าง Expectation แรกที่เงื่อนไขทั้งหมดตรงกันจะเป็นผู้ชนะ และจะส่งคืนการตอบกลับนั้น นี่คือเหตุผลที่กฎที่กำหนดเองมีชัยเหนือ Smart mock: Expectation ที่ตรงกันจะข้ามทุกอย่างที่อยู่ด้านล่างไป
- หากไม่มี Expectation ใดตรงกัน Apidog จะกลับไปใช้ Mock method priority ที่คุณตั้งค่าไว้ใน Project Settings - Feature Settings - Mock Settings. นั่นคือระดับที่ Smart mock (และ Mock script ใด ๆ ที่แนบมา) จะสร้างการตอบกลับ
โมเดลความคิดนั้นเรียบง่าย: กฎเฉพาะเจาะจงก่อน ข้อมูลที่สร้างขึ้นมาทีหลัง จัดเรียง Expectations ของคุณจากเฉพาะเจาะจงที่สุดไปหาน้อยที่สุด เก็บ Catch-all ที่ไม่มีเงื่อนไขไว้ด้านล่างสุดหากคุณต้องการการจับคู่ที่แน่นอน และให้ Smart mock จัดการส่วนที่เหลือทั้งหมด สำหรับการสำรวจเชิงลึกเพิ่มเติมว่าเมื่อใดควรใช้แต่ละ Layer คู่มือ กรณีการใช้งานการจำลอง API จะแมปสถานการณ์ทั่วไปกับคุณสมบัติต่าง ๆ
สิ่งที่ควรทราบก่อนนำไปใช้งานจริง
ข้อจำกัดบางประการจะช่วยให้คุณประหยัดเวลาในการแก้ปัญหาที่สับสน:
- เงื่อนไข Parameter ไม่รองรับ
{{variables}}. ตัวแปรโปรเจกต์และสภาพแวดล้อมของ Apidog ไม่สามารถใช้งานได้ภายใน Mock expectations ดังนั้นให้ใส่ค่า Literal ในเงื่อนไขของคุณ - เงื่อนไข Body-parameter เป็น JSON เท่านั้น ไม่ใช่ XML และต้องจับคู่ผ่าน JSON path ในช่องชื่อ
- รูปแบบ Body ของคำขอในเงื่อนไขต้องตรงกับ API spec. Endpoint ที่เป็น Form-data ต้องถูก Mock ด้วยการจัดวางแบบ Form-data ไม่ใช่ JSON
- ภายใน Mock scripts ไม่มีฟังก์ชันการ Logging, อ็อบเจกต์
pmไม่สามารถใช้งานได้ (เป็นสภาพแวดล้อมการทำงานที่แตกต่างจาก Test scripts) และไม่สามารถใช้ตัวแปรของ Apidog ได้ รักษาตรรกะของ Script ให้เป็นอิสระจากกัน
คุณสมบัติเหล่านี้ไม่มีการจำกัดแผนการใช้งานในเอกสาร ความแตกต่างระหว่าง Local กับ Cloud มีเพียงด้านฟังก์ชันการทำงาน: การเปิด/ปิดอิสระต่อสภาพแวดล้อมที่อธิบายไปก่อนหน้านี้ ไม่ใช่การจำกัดการเข้าถึงแบบ Paywall
ทำให้เวิร์กโฟลว์เป็นแบบอัตโนมัติด้วย Apidog CLI
การ Mock ใน Apidog เป็นความสามารถของ GUI และ Cloud Engine Mock จะให้บริการ Endpoint ของคุณจาก Local และ Cloud mock URL และไม่มีคำสั่ง CLI ใดที่สามารถตั้ง Mock Server ที่ทำงานได้ สิ่งที่ Apidog CLI เพิ่มเข้ามาคือการควบคุมทรัพยากรที่ใช้สร้าง Mock เหล่านั้น
การตอบกลับของ Mock ถูกสร้างขึ้นจาก Endpoint Schema ดังนั้นความถูกต้องของ Mock ของคุณจึงขึ้นอยู่กับความถูกต้องของ Spec ของคุณ CLI และ AI Coding Agents ที่ขับเคลื่อนมัน (Cursor, Claude Code, Trae, Codex) สามารถสร้างและอัปเดต Endpoint และ Schema ในโปรเจกต์ของคุณได้ เปลี่ยน Contract ในโค้ด, ซิงค์ข้อมูล, และ Output ของ Mock จะยังคงถูกต้องโดยที่ไม่มีใครต้องเปิดแอปอีกครั้ง
เมื่อ Mock ได้ปลดบล็อกงาน Frontend แล้ว สถานการณ์การทดสอบของโปรเจกต์เดียวกันจะทำงานแบบ Headless ใน CI เพื่อตรวจสอบ Backend จริงเทียบกับ Contract ที่ Mock ได้อธิบายไว้:
apidog run -t <scenario_id> -e <env_id> -r cli
คำสั่งเดียวนี้จะดำเนินการสถานการณ์การทดสอบของคุณและรายงานผลลัพธ์ ดังนั้น Mock และการตรวจสอบจะใช้แหล่งข้อมูลความจริงเดียวกัน คู่มือการติดตั้ง Apidog CLI ครอบคลุมการตั้งค่า และ การใช้งาน Apidog CLI ใน GitHub Actions จะแสดงวิธีการเชื่อมต่อเข้ากับ Pipeline
คำถามที่พบบ่อย (FAQ)
ทำไม expectation ของฉันถึงถูกละเว้น ทั้งที่เงื่อนไขดูเหมือนถูกต้อง? เกือบทั้งหมดเป็นเรื่องของลำดับหรือรูปแบบที่ไม่ตรงกัน Expectations จะถูกประเมินจากบนลงล่างและเงื่อนไขที่ตรงกันอันแรกจะเป็นผู้ชนะ ดังนั้นกฎที่ไม่มีเงื่อนไขแบบกว้าง ๆ ที่อยู่เหนือเงื่อนไขเฉพาะเจาะจงจะดักจับคำขอไป นอกจากนี้ โปรดยืนยันว่ารูปแบบ Body ตรงกับ Spec (JSON path สำหรับ Body แบบ JSON, การจัดวางแบบ Form-data สำหรับ Endpoint แบบ Form). ภาพรวมการจำลอง API ครอบคลุมพื้นฐานการตั้งค่าหากคุณต้องการตรวจสอบอีกครั้ง
ฉันสามารถใช้ Mock script และ Mock expectation กับการตอบกลับเดียวกันได้หรือไม่? ไม่ได้ Mock scripts ทำงานได้กับ Smart mock เท่านั้น จะถูกละเว้นโดย Mock expectations และ Response examples หาก expectation ตรงกัน Script จะไม่ทำงานเลย ดังนั้นให้เลือกวิธีใดวิธีหนึ่งต่อ Endpoint: ใช้ expectations สำหรับการแตกแขนงตามกฎ, ใช้ scripts สำหรับ Output ที่คำนวณได้
ฉันจะส่งคืน 401 หรือ 500 โดยไม่ทำให้ 200 เริ่มต้นเสียหายได้อย่างไร? เพิ่ม expectation เฉพาะพร้อมเงื่อนไขที่คุณควบคุมได้จาก Client (Header ทำงานได้ดี) จากนั้นเปิดแท็บ More และตั้งค่า HTTP Status Code. การตอบกลับเริ่มต้นจะยังคงเป็น 200; ข้อผิดพลาดจะเกิดขึ้นเฉพาะเมื่อเงื่อนไขตรงกันเท่านั้น
เงื่อนไขสามารถใช้ตัวแปรสภาพแวดล้อมของฉันได้หรือไม่? ไม่ได้ ค่า {{variable}} ของ Apidog ไม่สามารถใช้งานได้ภายใน Mock expectations และเงื่อนไข Parameter ไม่รองรับ {{variables}}. ใช้ค่า Literal ในเงื่อนไข
เกิดอะไรขึ้นเมื่อไม่มี expectation ใดตรงกันเลย? Apidog จะกลับไปใช้ Mock method priority ใน Project Settings - Feature Settings - Mock Settings ซึ่ง Smart mock จะสร้างการตอบกลับจาก Schema ของคุณ การเพิ่ม Expectation แบบ Catch-all ที่ไม่มีเงื่อนไขเป็นวิธีที่จะรับประกัน Fallback ที่เฉพาะเจาะจงแทน
สรุป
Smart mock จัดการกรณีทั่วไปได้ และ Mock expectations จัดการทุกอย่างที่มี เงื่อนไข ในนั้น: 200 สำหรับผู้ใช้ที่รู้จักและ 401 ในกรณีอื่น ๆ, เนื้อหาคำสั่งซื้อที่แตกต่างกันไปตามสถานะ, 500 ตามต้องการ ใช้ Mock script เฉพาะเมื่อคุณต้องการ Output ที่คำนวณได้ที่กฎไม่สามารถแสดงออกได้ และจำไว้ว่ามันทำงานกับ Smart mock เท่านั้น คำนึงถึงลำดับความสำคัญ (Expectation ที่เฉพาะเจาะจงก่อน, ข้อมูลที่สร้างขึ้นมาทีหลัง) และ Mock ของคุณจะแตกแขนงได้อย่างถูกต้องตามที่ API จริง ๆ ทำ ดาวน์โหลด Apidog เพื่อสร้าง Mock แบบมีเงื่อนไขครั้งแรกของคุณ ฟรี ไม่มีบัตรเครดิต