เอเจนต์ของ Cursor สามารถแก้ไขไฟล์, รันเทอร์มินัลของคุณ, อ่านผลลัพธ์ และแก้ไขสิ่งที่มันผิดพลาดได้อยู่แล้ว ขั้นตอนต่อไปคือการนำการทดสอบ API ของคุณเข้าสู่วงจรนั้น: ให้ Cursor รันสถานการณ์ Apidog จริงของคุณ, อ่านผลว่าผ่านหรือไม่ผ่าน และดำเนินการต่อ สิ่งที่ทำให้สิ่งนี้เป็นไปได้คือตัวรันบรรทัดคำสั่งที่ Cursor สามารถเรียกใช้ได้
ตัวรันนั้นคือ Apidog CLI ซึ่งเป็นแพ็กเกจ npm ชื่อ apidog-cli มันจะรันสถานการณ์ทดสอบที่คุณสร้างขึ้นด้วยภาพใน Apidog จากเทอร์มินัลและออกด้วยรหัสสถานะที่ Cursor สามารถดำเนินการต่อได้ คู่มือนี้ครอบคลุมส่วนที่เฉพาะเจาะจงกับ Cursor: ไฟล์กฎที่สอนเวิร์กโฟลว์ของคุณให้ Cursor, พร้อมต์ที่ใช้รันการทดสอบ, วิธีที่การรันรวมเข้ากับวงจรแก้ไข-ทดสอบ-แก้ไข และเซิร์ฟเวอร์ MCP เสริมที่ส่งมอบสเปค API ของคุณให้ Cursor ขณะที่มันกำลังเขียนโค้ด
หาก CLI ยังไม่ได้ติดตั้ง ให้เริ่มต้นด้วย วิธีการติดตั้ง Apidog CLI ด้วย AI coding agent ซึ่งจะแนะนำ Cursor ตลอดกระบวนการติดตั้งและยืนยันตัวตน กลับมาเมื่อ apidog --version แสดงตัวเลข คุณต้องมีบัญชี Apidog ที่มีสถานการณ์ทดสอบที่บันทึกไว้อย่างน้อยหนึ่งรายการ ดาวน์โหลด Apidog หากคุณยังไม่มี
ปุ่ม
"การใช้ CLI ใน Cursor" หมายถึงอะไร
ไม่มีปลั๊กอิน Apidog สำหรับ Cursor และคุณไม่จำเป็นต้องมี เอเจนต์ของ Cursor สามารถรันคำสั่งเชลล์ในเทอร์มินัลของโปรเจกต์ของคุณได้อยู่แล้ว ดังนั้น การใช้ Apidog CLI ใน Cursor จึงหมายถึงสามสิ่งนี้:
- สอนเวิร์กโฟลว์ให้ Cursor เพียงครั้งเดียว ด้วยกฎของโปรเจกต์ เพื่อให้มันรู้จักคำสั่ง, แฟล็ก และรู้ว่ารหัสออกเป็นแหล่งที่มาของความจริง
- ให้เอเจนต์รัน
apidog runเป็นขั้นตอนปกติในวงจรของมัน เหมือนกับการรันการทดสอบหน่วยของคุณ - เชื่อมต่อเซิร์ฟเวอร์ Apidog MCP เสริม เพื่อให้ Cursor สามารถอ่านสเปค API ของคุณได้ในขณะที่มันเขียนโค้ดที่การทดสอบเหล่านั้นตรวจสอบ
กฎนี้คือสิ่งที่ทำให้สิ่งนี้เป็นรูปแบบเฉพาะของ Cursor แทนที่จะเป็นคู่มือทั่วไปที่ว่า "เปิดเทอร์มินัลแล้วพิมพ์"
ขั้นตอนที่ 1: เพิ่มกฎของโปรเจกต์
Cursor อ่านกฎของโปรเจกต์จากไดเรกทอรี .cursor/rules ที่รูทของ repo ของคุณ แต่ละกฎเป็นไฟล์ .mdc ที่มีบล็อก frontmatter ขนาดเล็ก ซึ่งถูกควบคุมเวอร์ชันควบคู่ไปกับโค้ดของคุณ เพื่อให้ทั้งทีมได้รับพฤติกรรมเดียวกัน
คุณสามารถสร้างได้สองวิธี: พิมพ์ /create-rule ในแชทและอธิบายสิ่งที่คุณต้องการ หรือเปิด Cursor Settings > Rules, Commands แล้วคลิก + Add Rule ไม่ว่าวิธีใด คุณก็จะได้ไฟล์อยู่ใต้ .cursor/rules
บันทึกสิ่งนี้เป็น .cursor/rules/apidog-cli.mdc:
---
description: How to run Apidog API tests from the terminal
alwaysApply: false
---
# Running Apidog API tests
This project has API test scenarios in Apidog. Run them with the
apidog-cli, which is installed globally and already authenticated.
- The command is `apidog run`. The binary is `apidog`.
- Run a single scenario by ID: `apidog run -t <scenarioId> -e <environmentId> -n 1 -r cli`
- `-t` is the test scenario ID, `-e` is the environment ID.
- `-n 1` runs it once. `-r cli` prints a readable report to the terminal.
- Do not pass `--access-token`. Auth is handled by a prior `apidog login`.
- The exit code is the source of truth: `0` means every assertion passed,
non-zero means a failure. Report the exit code, not just a summary.
- If a flag is unknown, run `apidog run --help` and use the exact flag from there.
Never guess at flag names.
- After changing code that touches an endpoint, run the relevant scenario
and read the result before claiming the change works.
Frontmatter มีความสำคัญ description บวกกับ alwaysApply: false ทำให้เป็นกฎที่ถูกนำไปใช้โดยอัจฉริยะ: Cursor จะดึงกฎนี้เข้ามาเมื่อการสนทนาเกี่ยวกับการรันการทดสอบ แทนที่จะใช้บริบทไปกับการสนทนาทุกครั้ง ตั้งค่า alwaysApply: true เพื่อให้กฎอยู่ในขอบเขตเสมอ หากต้องการกำหนดขอบเขตให้เป็นประเภทไฟล์ ให้ลบคำอธิบายและเพิ่มบรรทัด globs แล้ว Cursor จะแนบกฎนี้โดยอัตโนมัติเมื่อไฟล์ที่ตรงกันถูกเปิด
เนื้อหาคือส่วนที่ทำงานจริง มันกำหนดรูปแบบคำสั่ง, บอกแหล่งที่มาของการยืนยันตัวตน และระบุบรรทัดที่ทำให้เอเจนต์ซื่อสัตย์: รหัสออกมีความสำคัญกว่าข้อความ บางครั้งเอเจนต์อ่านรายงานที่ล้มเหลวแล้วเรียกมันว่า "ดูดี" การเขียนกฎนั้นลงไปเพียงครั้งเดียวหมายความว่าคุณไม่จำเป็นต้องตรวจสอบด้วยตนเอง
ขั้นตอนที่ 2: รับคำสั่งจาก Apidog
ก่อนที่คุณจะขอให้เอเจนต์รันสิ่งใด ให้แน่ใจว่าคุณมีคำสั่งที่ถูกต้อง อย่าให้ Cursor เดา ID
เปิดสถานการณ์ทดสอบของคุณใน Apidog, ไปที่แท็บ CI/CD และเลือกตัวเลือกบรรทัดคำสั่ง Apidog จะสร้างคำสั่ง apidog run ที่สมบูรณ์พร้อมด้วย Scenario ID, Environment ID และ Access Token ที่กรอกไว้แล้ว:
apidog run --access-token YOUR_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r cli
605067 คือ Test Scenario ID และ 1629989 คือ Environment ID; ของคุณจะแตกต่างกันไป เนื่องจากคุณได้ยืนยันตัวตน CLI ระหว่างการติดตั้งแล้ว ให้ตัดส่วน --access-token ออกและเก็บ ID ไว้ นั่นคือคำสั่งที่กฎของคุณบอกให้ Cursor ใช้
ขั้นตอนที่ 3: ให้เอเจนต์รันการทดสอบ
เปิดเอเจนต์ของ Cursor (โหมดแชทที่รันคำสั่งเทอร์มินัล ไม่ใช่การแก้ไขแบบอินไลน์) เมื่อมีกฎอยู่แล้ว พร้อมต์จะสั้นๆ ดังนี้:
รันสถานการณ์ทดสอบ Apidog ของฉัน และแสดงผลลัพธ์ทั้งหมดพร้อมบอกรหัสออกให้ฉันด้วย
Cursor จะเสนอคำสั่ง และหลังจากที่คุณอนุมัติ มันจะรันคำสั่งนั้นในเทอร์มินัลแบบรวม:
apidog run -t 605067 -e 1629989 -n 1 -r cli
โดยค่าเริ่มต้น Cursor จะถามก่อนที่จะดำเนินการคำสั่งเทอร์มินัล ดังนั้นคุณจะเห็นสิ่งที่จะรันอย่างชัดเจน อนุมัติมัน แล้วเอเจนต์จะรันสถานการณ์ จากนั้นจะอ่านผลการทำงานและสรุปให้ฟัง
การตรวจสอบของคุณ: ดูที่รหัสออก ไม่ใช่สรุป apidog run จะออกด้วยรหัส 0 เมื่อการยืนยันทั้งหมดผ่าน และเป็นค่าที่ไม่ใช่ศูนย์เมื่อมีรายการใดล้มเหลว พฤติกรรมนี้คือเหตุผลทั้งหมดที่ทำให้สิ่งนี้ทำงานเป็นด่านกั้น สำหรับ CI และสำหรับเอเจนต์ หาก Cursor บอกว่า "การทดสอบผ่าน" แต่รหัสออกไม่ใช่ศูนย์ นั่นคือผิดพลาด; ให้เชื่อถือโค้ด นี่คือความล้มเหลวที่กฎในขั้นตอนที่ 1 ป้องกันไว้ได้อย่างแม่นยำ
สำหรับรูปแบบรายงานที่แตกต่างกันหรือการวนซ้ำเพิ่มเติม ให้เอเจนต์รัน apidog run --help เพื่อให้อ่านรายการแฟล็กจริงสำหรับเวอร์ชันที่คุณติดตั้ง คู่มือ Apidog CLI ฉบับสมบูรณ์ จะบันทึกแฟล็กทุกตัว รวมถึงรีพอร์ตเตอร์ html, json, junit และการวนซ้ำแบบขับเคลื่อนด้วยข้อมูล
ขั้นตอนที่ 4: อ่านรายงานภายใน Cursor
รีพอร์ตเตอร์ -r cli จะพิมพ์ผลลัพธ์ไปยังเทอร์มินัลที่ Cursor อ่านอยู่แล้ว ซึ่งทำให้เหมาะสมกับการทำงานของเอเจนต์ เอเจนต์จะเห็นบรรทัดเดียวกับที่คุณเห็น: สถานการณ์ใดที่รัน, แต่ละคำขอ, แต่ละการยืนยัน และจำนวนสุดท้ายที่ผ่านหรือไม่ผ่าน
เมื่อการรันไม่ผ่าน (ขึ้นสีแดง) รายงานจะระบุการยืนยันที่ล้มเหลว, ค่าที่คาดหวัง และสิ่งที่ปลายทางส่งกลับมา เนื่องจากข้อความนั้นอยู่ในบริบทของเอเจนต์ คุณสามารถดำเนินการต่อในการแชทเดียวกันได้:
สถานการณ์ล้มเหลว อ่านการยืนยันที่ล้มเหลวในรายงาน ค้นหา handler ที่สร้างฟิลด์นั้น และเสนอการแก้ไข จากนั้นรันสถานการณ์อีกครั้งและแสดงรหัสออกใหม่ให้ฉันดู
ตอนนี้การทดสอบเป็นส่วนหนึ่งของวงจรแล้ว Cursor จะแก้ไข handler, รัน apidog run ซ้ำ, อ่านรหัสออกใหม่ และดำเนินการต่อหรือลองอีกครั้ง การตรวจสอบ API ของคุณอยู่ในวงจรแก้ไข-ทดสอบ-แก้ไข เดียวกันกับที่ Cursor ใช้สำหรับการทดสอบหน่วย เพียงแต่การตรวจสอบเหล่านี้ทำงานกับปลายทางจริง สำหรับรูปแบบที่กว้างขึ้น วิธีการใช้ AI agents สำหรับการทดสอบ API ครอบคลุมถึงจุดที่เหมาะสมและจุดที่ไม่เหมาะสม
ทางเลือก: เชื่อมต่อเซิร์ฟเวอร์ Apidog MCP
CLI ช่วยให้ Cursor รันการทดสอบของคุณได้ เซิร์ฟเวอร์ Apidog MCP ช่วยให้ Cursor อ่านสเปค API ของคุณในขณะที่มันเขียนโค้ด ทั้งสองทำงานร่วมกัน: เซิร์ฟเวอร์ MCP จะส่ง schema ของคุณให้ Cursor เพื่อให้มันสร้างโค้ดที่ตรงกับสัญญา และ CLI จะตรวจสอบโค้ดนั้นกับสถานการณ์จริง
Cursor รองรับเซิร์ฟเวอร์ MCP ผ่านการกำหนดค่า JSON ใส่เซิร์ฟเวอร์ที่จำกัดขอบเขตโปรเจกต์ไว้ใน .cursor/mcp.json ที่รูทของ repo ของคุณ หรือเซิร์ฟเวอร์ส่วนกลางไว้ใน ~/.cursor/mcp.json รูปแบบคือออบเจกต์ mcpServers ที่มีชื่อเป็นคีย์ แต่ละรายการมี command, อาร์เรย์ args และค่า env ที่เป็นทางเลือก:
{
"mcpServers": {
"apidog": {
"command": "npx",
"args": ["-y", "apidog-mcp-server@latest", "--project=YOUR_PROJECT_ID"],
"env": {
"APIDOG_ACCESS_TOKEN": "YOUR_ACCESS_TOKEN"
}
}
}
}
มีสองข้อสังเกต MCP ถูกปิดกั้นด้วยสวิตช์ในการติดตั้งบางครั้ง ดังนั้นให้เปิด Cursor Settings, ค้นหาส่วน Model Context Protocol และยืนยันว่าเซิร์ฟเวอร์ Apidog ถูกเปิดใช้งาน และหากคุณคอมมิต .cursor/mcp.json อย่าใส่โทเค็นแบบฮาร์ดโค้ด; ให้อ้างอิงตัวแปรสภาพแวดล้อมแทน สำหรับการตั้งค่าทั้งหมด รวมถึงวิธีการรับ Project ID และโทเค็น ดู คู่มือเซิร์ฟเวอร์ Apidog MCP สำหรับเวิร์กโฟลว์สำเร็จรูปที่นำกลับมาใช้ใหม่ได้ แทนที่จะตั้งค่าด้วยตนเอง คู่มือ Apidog CLI with Claude Skills จะแสดงเวอร์ชันที่อิงตามทักษะ
จากวงจรท้องถิ่นสู่ CI
เมื่อ Cursor รันสถานการณ์ในเครื่องแล้วและดำเนินการตามรหัสออก คุณได้ยืนยันคำสั่งที่แน่นอนที่ไปป์ไลน์ของคุณจะใช้ การย้ายไป CI นั้นง่ายดาย: ใช้ apidog run เดียวกัน โดยส่งโทเค็นเป็นความลับที่ซ่อนไว้แทนการเข้าสู่ระบบที่จัดเก็บไว้ คุณยังสามารถขอให้ Cursor เขียนขั้นตอนให้ได้ด้วย เนื่องจากมันรู้จักคำสั่งจากกฎของคุณ:
กลไกของขั้นตอนนี้ (secrets, reporters, exit-code gating) อยู่ใน Apidog CLI ใน GitHub Actions คำสั่งเดียวกันนี้ทำงานในสามที่แล้ว ทั้งในเทอร์มินัลของคุณ, วงจร Agent ของ Cursor และ CI ซึ่งทั้งหมดเชื่อถือรหัสออกเดียวกัน
ปัญหาที่พบบ่อย
กฎไม่ถูกนำไปใช้ ด้วย description และ alwaysApply: false, Cursor จะโหลดกฎก็ต่อเมื่อมันพิจารณาว่าการแชทนั้นเกี่ยวข้อง หากเซสชันการทดสอบไม่ดึงกฎเข้ามา ให้กล่าวถึงด้วย @apidog-cli ในแชท หรือเปลี่ยนเป็น alwaysApply: true
เอเจนต์ไม่สามารถรันคำสั่งได้ หากมันเพียงแค่แนะนำคำสั่งแทนที่จะรัน คุณอาจอยู่ในโหมดแก้ไขแทนที่จะเป็นเอเจนต์ หรือคุณพลาดพร้อมต์การอนุมัติ ยืนยันว่าคุณอยู่ในแชทของเอเจนต์และอนุมัติเมื่อ Cursor ขอ หากการรันเทอร์มินัลล้มเหลวโดยสิ้นเชิง โดยปกติจะเป็นปัญหา PATH ที่ว่า apidog: command not found ซึ่ง คู่มือการติดตั้ง ได้กล่าวถึงไว้
apidog whoami แสดงว่าคุณไม่ได้รับการยืนยันตัวตน ข้อมูลการเข้าสู่ระบบถูกจัดเก็บไว้ในเครื่องของคุณ ไม่ใช่ใน Cursor รัน apidog login --with-token ด้วยโทเค็นใหม่จาก Apidog ด้วยตัวเอง จากนั้นขอให้เอเจนต์ยืนยันด้วย apidog whoami อย่าใส่โทเค็นลงในแชท
มันสร้างแฟล็กขึ้นมาเอง หากการรันล้มเหลวด้วยข้อผิดพลาด "unknown option" แสดงว่าเอเจนต์เดาแฟล็กที่ไม่มีอยู่ในเวอร์ชันของคุณ ให้มันรัน apidog run --help แล้วคัดลอกแฟล็กที่ถูกต้อง
สรุป
การตั้งค่า Cursor คือไฟล์เดียวและนิสัยเดียว: กฎ .cursor/rules/apidog-cli.mdc ที่กำหนดคำสั่ง, แหล่งที่มาของการยืนยันตัวตน และกฎรหัสออก บวกกับนิสัยที่ให้เอเจนต์รัน apidog run และตรวจสอบรหัสออกด้วยตัวคุณเอง เพิ่มเซิร์ฟเวอร์ Apidog MCP เข้าไป แล้ว Cursor ก็ยังสามารถอ่านสเปคของคุณได้ในขณะที่มันเขียนโค้ด
คุณยังคงสร้างสถานการณ์ด้วยภาพใน Apidog ต่อไป; Cursor เพียงแค่รันมัน จากจุดนี้ คุณสามารถชี้คำสั่งเดียวกันไปยังไปป์ไลน์ของคุณด้วย Apidog CLI ใน GitHub Actions หรืออ่านข้อมูลอ้างอิงแฟล็กทั้งหมดใน คู่มือ Apidog CLI ฉบับสมบูรณ์
ปุ่ม