ทดสอบ Claude Fable 5.2 API ด้วย Apidog: คู่มือ Regression Testing

ในการทดสอบการเชื่อมต่อ API ของ Claude Fable 5.2 ให้ตรวจสอบการยืนยันตัวตน (authentication), request body ของ Messages, response blocks แบบมี type ที่ชัดเจน และกรณีความล้มเหลวที่คาดการณ์ได้ จากนั้นบันทึกการตรวจสอบเหล่านี้เป็น Apidog test cases ที่เรียกใช้ซ้ำได้ ซึ่ง coding agent ของคุณจะรันผ่าน CLI แยกการตรวจสอบระดับ transport ออกจากการตรวจสอบคุณภาพของงาน เพื่อไม่ให้ HTTP response ที่สำเร็จปิดบังคำตอบที่ใช้งานไม่ได้

ประกาศของ Anthropic ระบุว่า claude-fable-5-2 คือ model ID บน Claude Platform คู่มือนี้จะสร้าง workflow สำหรับ regression testing โดยอิงจากโมเดลนั้น แทนที่จะหยุดแค่หลังจากได้ response ที่สำเร็จเพียงครั้งเดียว Apidog ช่วยให้ agent ของคุณมีพื้นที่กลางสำหรับดูแล endpoint, test cases และรายงานการรันทดสอบ

การทดสอบ API ของ Claude Fable 5.2 ควรครอบคลุมอะไรบ้าง?

ใช้สามชั้นการทดสอบ: transport checks ตรวจสอบว่า request ไปถึงบริการหรือไม่; contract checks ตรวจสอบความถูกต้องของโครงสร้าง response; behavioral checks ตรวจสอบว่าแอปพลิเคชันของคุณนำผลลัพธ์ไปใช้ได้จริงหรือไม่ รันสองชั้นแรกกับทุก fixture ส่วนเกณฑ์การยอมรับด้านพฤติกรรมให้กำหนดแยกตามแต่ละงาน แทนการเปรียบเทียบคำตอบที่สร้างขึ้นทั้งหมดแบบ byte ต่อ byte

เริ่มต้นด้วย fixture ขนาดเล็กที่ไม่มีอันตราย: "2 + 2 เท่ากับเท่าไร? ตอบด้วยตัวเลขเท่านั้น" ซึ่งทำให้เห็นเกณฑ์การยอมรับได้ชัดเจนโดยไม่ต้องเกี่ยวข้องกับไฟล์ เครื่องมือ หรือประวัติการสนทนา เมื่อ contract พื้นฐานใช้งานได้แล้ว ค่อยเพิ่ม fixtures ที่แทนสถานการณ์จริงของแอปพลิเคชัน

อย่าถือว่า fixture นี้เป็น benchmark ด้านความสามารถในการใช้เหตุผล วัตถุประสงค์ของมันคือการจับ regression ด้านการเชื่อมต่อ เช่น การดึง thinking block มาแสดงเป็นข้อความสำหรับผู้ใช้ หรือการยอมรับ response ที่ถูกตัดขาด

กำหนดการยืนยันตัวตนและค่า request ให้คงที่ก่อนการทดสอบ

สำหรับ Claude API โดยตรง ให้ใช้ endpoint ของ Messages, API credential ที่ scoped ระดับ workspace, API version ที่ระบุชัดเจน และ request body ที่คงที่ คงค่า input เหล่านี้ให้เหมือนกันในทุกการรัน API overview อธิบายเรื่องการยืนยันตัวตนแบบ Bearer, การเลือก workspace และ header เวอร์ชัน ซึ่งต่างจากการยืนยันตัวตนแบบ IAM ของผู้ให้บริการคลาวด์

ใช้ Claude Console API key ที่ส่งผ่าน secret environment ในเครื่องของคุณ Apidog access token ใช้ยืนยันตัวตนของ CLI กับ Apidog ไม่ใช่ยืนยัน request ไปยัง Anthropic จงแยก credentials ทั้งสองออกจากกัน

Request ต่อไปนี้เป็นไปตามเอกสาร Messages ปัจจุบัน ตรวจสอบเมื่อวันที่ 10 พฤศจิกายน 2026 บันทึก JSON เป็น request.json:

{
  "model": "claude-fable-5-2",
  "max_tokens": 1024,
  "stream": false,
  "thinking": { "type": "adaptive" },
  "messages": [
    {
      "role": "user",
      "content": "What is 2 + 2? Reply with the numeral only."
    }
  ]
}

จากนั้นส่งจาก terminal ของคุณ หรือให้ coding agent เรียกใช้งาน:

curl https://api.anthropic.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
  -H 'anthropic-version: 2026-10-21' \
  -H 'Content-Type: application/json' \
  --max-time 600 \
  --dump-header response.headers \
  --output response.json \
  --write-out '%{http_code}\n' \
  --data-binary @request.json

หาก key ของคุณไม่ได้ scoped ระดับ workspace ให้ใส่ header anthropic-workspace-id ตามที่เอกสารระบุสำหรับ workspace เป้าหมาย อย่าใส่ credential แบบ literal ลงใน fixture ที่บันทึกไว้หรือรายงานที่สร้างขึ้นเด็ดขาด

เอกสาร Create a Message กำหนด model, messages และ max_tokens รวมถึงฟิลด์ของข้อความที่ส่งกลับ ค่า 1,024 ในที่นี้คืองบประมาณ output ที่เลือกเอง ไม่ใช่ค่าขั้นต่ำตามเอกสารหรือการรับประกันว่าทุกงานจะพอดี หาก fixture ใดต้องการพื้นที่มากกว่านั้น ให้เพิ่มค่านี้อย่างมีเจตนา

นี่คือ template ที่ได้รับการตรวจสอบจากเอกสาร ให้รันด้วยบัญชี API ที่คุณได้รับอนุญาตเองก่อนบันทึก baseline ที่ผ่าน โดยไม่มีการอ้างว่าเป็น response หรือการวัด latency จริงของ Fable ที่นี่

เพิ่ม response assertions ที่ทนต่อความแตกต่างของผลลัพธ์ที่สร้างขึ้น

ให้ assert envelope, ตรวจสอบ block types, ดึงข้อความออกมา แล้วจึงใช้เกณฑ์การยอมรับของ fixture Messages response ประกอบด้วย array content ดังนั้นอย่าสมมติว่า content[0].text เก็บคำตอบไว้ หากแอปพลิเคชันของคุณส่งข้อความเดิมกลับไปในเทิร์นสนทนาถัดไป ให้เก็บข้อความต้นฉบับเต็มแยกไว้ต่างหาก

สำหรับ fixture ทางคณิตศาสตร์ ให้ agent ของคุณแนบ post-response script นี้เข้ากับ Apidog test case:

pm.test("HTTP success", function () {
  pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.test("Assistant message contract", function () {
  pm.expect(body.type).to.eql("message");
  pm.expect(body.role).to.eql("assistant");
  pm.expect(body.id).to.be.a("string");
  pm.expect(body.model).to.be.a("string");
  pm.expect(body.content).to.be.an("array");
});

const text = body.content
  .filter(block => block.type === "text")
  .map(block => block.text)
  .join("\n").trim();

pm.test("Arithmetic fixture is complete", function () {
  pm.expect(body.stop_reason).to.eql("end_turn");
  pm.expect(text).to.eql("4");
});

การเปรียบเทียบแบบเท่ากันเป๊ะเหมาะสมกับตัวเลขที่ถูกจำกัดอย่างจงใจนี้ สำหรับงานสรุปเนื้อหา ให้ใช้เกณฑ์อย่างข้อเท็จจริงที่จำเป็น ข้ออ้างที่ไม่มีหลักฐานรองรับที่ห้ามมี และขอบเขตความยาว การเปลี่ยนถ้อยคำเล็กน้อยที่ไม่เป็นอันตรายไม่ควรทำให้การทดสอบ summary ที่มีประโยชน์ล้มเหลว

บันทึกค่า usage และ header request-id ของ response ไว้เพื่อการวินิจฉัย เปรียบเทียบ model identifier ที่ส่งกลับมากับพฤติกรรมที่เอกสารระบุสำหรับ identifier ที่คุณเลือก อย่าติดป้าย response จาก fallback ว่าเป็นผลลัพธ์ของ Fable โดยไม่แจ้งให้ทราบ

สาเหตุหยุดแบบ max_tokens หมายความว่าคำตอบชนขีดจำกัด output ให้ทำให้ fixture ทางคณิตศาสตร์นี้ล้มเหลวและตรวจสอบงบ token งานอื่นอาจส่งคืน stop reason อื่นได้อย่างถูกต้อง รวมถึงการขอใช้เครื่องมือ ดังนั้นให้แต่ละเคสมีกฎความสมบูรณ์ของตัวเอง

ทดสอบกรณีลบของ API Claude Fable 5.2

สร้างเคสแยกสำหรับ input ที่ไม่ถูกต้องแต่ละกรณี โดยเปลี่ยนค่าครั้งละหนึ่งฟิลด์ ตรวจสอบ HTTP status และ structured error type แทนการจับคู่ข้อความ error ที่มนุษย์อ่านได้ทั้งหมด คง baseline ที่ถูกต้องให้ไม่เปลี่ยนแปลง เพื่อไม่ให้ fixture กรณีลบปนเปื้อนการรันกรณีบวกถัดไป

คู่มือ error อย่างเป็นทางการ ระบุกรณีที่มีประโยชน์ดังต่อไปนี้:

Fable 5.2 ใช้ thinking แบบเปิดตลอดเวลา อย่าคัดลอกจากบทเรียน Claude รุ่นเก่าที่ปิดฟีเจอร์นี้หรือกำหนดงบ extended thinking กรณีปิด thinking มีประโยชน์อย่างยิ่งเมื่ออัปเกรดโค้ดสร้าง request ที่ใช้ร่วมกัน

สำหรับแต่ละกรณี error ให้ assert body.type === "error", body.error.type ที่คาดหวัง และข้อความ error ที่ไม่ว่างเปล่า เก็บ request ID ไว้เมื่อมีให้ ถือว่า DNS failures และ client timeouts เป็นผลลัพธ์แยกต่างหาก เพราะกรณีเหล่านั้นอาจไม่สร้าง JSON error จาก Claude เลย

ทดสอบการจัดการ rate limits และความล้มเหลวของบริการในแอปพลิเคชันของคุณด้วย fixtures ที่ควบคุมได้หรือ mock อย่าระดมยิง API จริงเพื่อสร้าง 429 ขึ้นเอง แยกปัญหาความจุที่ retry ได้ออกจากความล้มเหลวด้านการยืนยันตัวตนและการตรวจสอบความถูกต้อง และกำหนดงบ retry แบบจำกัดรอบตรรกะการ retry ของแอปพลิเคชัน

ให้ coding agent ของคุณสร้าง Apidog regression cases

มอบ endpoint, fixtures, assertions และโปรเจกต์เป้าหมายให้ agent ของคุณ มันสามารถค้นหา CLI schema ปัจจุบัน ตรวจสอบ payload แต่ละตัว สร้าง test cases และรัน them ได้ ส่วนคุณทบทวนเคสที่สร้างขึ้นและสรุปความล้มเหลว วิธีนี้ทำให้ workflow ที่เรียกใช้ซ้ำได้อยู่ใน Apidog CLI

ติดตั้ง CLI และยืนยันตัวตนด้วย Apidog token ของคุณ:

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_APIDOG_TOKEN>

สำหรับการตั้งค่า agent ให้ทำตามคู่มือสดสำหรับ Claude Code หรือ Codex จากนั้นสั่ง agent ของคุณด้วย prompt เดียว:

In Apidog project <PROJECT_ID>, define POST /v1/messages for the
Claude API. Use model claude-fable-5-2 and version 2026-10-21.
Keep the Anthropic credential in a private runtime variable.
Create the arithmetic success case and four negative cases above.
Read CLI help and input schemas before generating payloads.
Discover valid endpoint and category IDs; validate every payload.
Attach the response assertions, then run each case against
<ENVIRONMENT_ID>. Report failures, request IDs, and token usage.
Do not print credentials or claim unexecuted cases passed.

คำสั่งต่อไปนี้ได้รับการตรวจสอบกับ CLI เวอร์ชัน 2.2.12 ที่ติดตั้งแล้ว agent ต้องมี endpoint ID และ category ID จริง; test-case-create อธิบายเคสที่อิงจาก endpoint ดังนั้นการสร้าง JSON request แบบ standalone ที่ไม่เกี่ยวข้องไม่เพียงพอ

apidog test-case category --project <PROJECT_ID>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <PROJECT_ID> --file case.json
apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
  -e <ENVIRONMENT_ID> -r cli,json

ให้ agent ตรวจสอบ help และ schemas ของคำสั่ง endpoint เมื่อ endpoint ยังไม่มีอยู่ ใช้ ID ที่ได้จากการส่งคืน ไม่ใช่ตัวเลขสมมติที่คัดลอกมาจากโปรเจกต์อื่น ตรวจสอบ case.json ก่อนเขียนไฟล์ จากนั้นอ่านเคสที่สร้างขึ้นกลับมาเพื่อยืนยันว่า headers, body และ assertions ตามที่ต้องการถูกบันทึกไว้จริง

รัน regression tests ของ Claude API ใน CI

รันเคสชุดเดิมหลังจากมีการเปลี่ยนแปลงด้านการยืนยันตัวตน, message serialization, block parsing หรือการจัดการ retry ส่งออกรายงานแบบ machine-readable และเก็บเวอร์ชันของ fixture ไว้คู่กับการเปลี่ยนแปลงของแอปพลิเคชัน สร้าง baseline ที่ผ่านก่อนทำการเปรียบเทียบ จากนั้นสืบสวนความล้มเหลวรายกรณี แทนการรันซ้ำจนกว่า build จะผ่านโดยบังเอิญ

สำหรับเคสที่สร้างไว้แล้วใน Apidog การเรียกใช้แบบเน้น CI คือ:

apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
  -e <ENVIRONMENT_ID> -r cli,json,junit \
  --out-dir ./apidog-reports

ทำซ้ำกับ case ID อื่น ๆ หรือให้ agent ของคุณจัดกลุ่มเคสเป็น test suite โดยใช้ suite schema ปัจจุบัน คู่มือ CI/CD ของ Apidog อธิบายการเชื่อมต่อกับ pipeline

เก็บโมเดล, API version, request body, งบ output, รุ่นของ fixture และเวอร์ชัน CLI ไว้ในบันทึกการรัน จัดเก็บ credentials ผ่านกลไก secret ของ CI ทบทวนรายงานเพื่อหาข้อมูล request ที่ละเอียดอ่อนก่อนแชร์

ใช้ชุด smoke test แบบเล็กสำหรับการเปลี่ยนแปลงทั่วไป และชุดทดสอบด้านพฤติกรรมที่กว้างขึ้นก่อนการเปิดตัว กำหนดงบด้านค่าใช้จ่ายและระยะเวลาของคุณเอง การผ่าน API contract พิสูจน์ความเข้ากันได้ด้านการเชื่อมต่อ; การทดสอบการยอมรับเฉพาะแอปพลิเคชันของคุณพิสูจน์ว่าผลลัพธ์มีประโยชน์จริง

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

ควรทดสอบ model ID ตัวไหน?

ใช้ claude-fable-5-2 สำหรับ workflow บน Claude Platform โดยตรงนี้ ตรวจสอบความพร้อมใช้งานในบัญชีของคุณก่อนบันทึก baseline

HTTP 200 เพียงพอที่จะผ่านหรือไม่?

ไม่ ให้ตรวจสอบ envelope ของข้อความ, content แบบมี type, เหตุผลการจบ และเกณฑ์การยอมรับของ fixture การ streaming ต้องมีการตรวจสอบระดับ event เพิ่มเติม เพราะความล้มเหลวอาจเกิดขึ้นหลังจาก response headers มาถึงแล้ว

ปิด thinking ของ Fable 5.2 ได้หรือไม่?

ไม่ได้ Anthropic ระบุว่าโมเดลนี้ใช้ thinking แบบเปิดตลอดเวลา ให้เก็บกรณีปิด thinking ไว้เป็นกรณีลบที่คาดหวัง validation error

ทุกคำตอบควรตรงกันเป๊ะหรือไม่?

ใช้การเทียบแบบเป๊ะสำหรับ fixtures ที่ถูกจำกัด เช่น ตัวอย่างตัวเลข สำหรับงานปลายเปิด ให้กำหนดเกณฑ์ด้านข้อเท็จจริงและโครงสร้างที่ยอมรับความแตกต่างของถ้อยคำที่ยังถูกต้อง

agent ของฉันรันการทดสอบซ้ำหลังแก้ไขได้หรือไม่?

ได้ มอบ case IDs และ environment ที่บันทึกไว้ให้มัน แล้วสั่งให้รันคำสั่ง CLI ชุดเดิมและสรุปรายงาน เริ่มต้นด้วย workflow Claude Code CLI หากคุณต้องการการตั้งค่า agent