Trae เป็นวงจรการทำงาน โดยที่เอดเจนต์ Builder ของมันจะอ่าน repository ของคุณ, แก้ไขไฟล์, รันคำสั่งในเทอร์มินัล, และอ่านผลลัพธ์เพื่อตัดสินใจว่าจะทำอะไรต่อไป แล้วทำไมการทดสอบ API ของคุณถึงไม่อยู่ในวงจรนั้นล่ะ? พวกมันอยู่ใน Apidog หลัง GUI และจะรันเมื่อมีคนจำได้ว่าต้องคลิก เอดเจนต์ของคุณไม่เคยแตะต้องมันเลย
การแก้ไขคือบล็อกการกำหนดค่าเพียงบล็อกเดียว Apidog CLI คือแพ็กเกจ npm, apidog-cli, ที่รันสถานการณ์การทดสอบที่คุณสร้างขึ้นใน Apidog ได้โดยตรงจากเทอร์มินัล เมื่อ CLI ติดตั้งแล้วและ Trae รู้ว่ามีอยู่, Builder จะรันสถานการณ์ Apidog ในลักษณะเดียวกับการรันการทดสอบหน่วย (unit tests) ของคุณ: สั่งการ, อ่านรหัสออก, แก้ไขโค้ดถ้ามันเป็นสีแดง
หากคุณยังไม่ได้ติดตั้ง CLI ให้ทำสิ่งนั้นก่อน วิธีติดตั้ง Apidog CLI ด้วย AI coding agent จะแนะนำขั้นตอนการติดตั้ง npm, การรับรองความถูกต้อง, และการรันครั้งแรก โดยมีเอดเจนต์เป็นผู้พิมพ์บทความนี้สมมติว่า apidog --version พิมพ์ตัวเลขออกมาและบัญชี Apidog ของคุณได้รับการรับรองความถูกต้องแล้ว
Trae ที่กล่าวถึงในที่นี้
Trae คือ AI IDE ของ ByteDance ที่สร้างขึ้นบน VS Code โดยมีโหมดเอดเจนต์ที่เรียกว่า Builder ซึ่งแก้ไขไฟล์และรันคำสั่งเทอร์มินัลได้ด้วยตัวเอง คุณสามารถอ่านรายละเอียดผลิตภัณฑ์ได้ที่ เว็บไซต์อย่างเป็นทางการของ Trae บทความนี้กล่าวถึงเดสก์ท็อป IDE ไม่ใช่โปรเจกต์วิจัย trae-agent แบบสแตนด์อโลนบน GitHub หากคุณเปิด Trae เห็นแผงแชทข้างโปรแกรมแก้ไขของคุณ และสามารถเปลี่ยนเอดเจนต์เป็น Builder ได้ แสดงว่าคุณมาถูกที่แล้ว
ความแตกต่างนี้มีความสำคัญ เพราะ Trae มีวิธีของตัวเองในการเรียนรู้กฎของโปรเจกต์ และกลไกนั้นเปลี่ยนการ "รันการทดสอบของฉัน" แบบครั้งเดียว ให้กลายเป็นสิ่งที่ Builder เข้าถึงได้ด้วยตัวเอง กลไกนั้นคือไฟล์กฎของโปรเจกต์ หากคุณต้องการเวอร์ชันที่ไม่ขึ้นกับเครื่องมือของเวิร์กโฟลว์นี้ก่อนหน้า คู่มือ Apidog CLI ฉบับสมบูรณ์ จะครอบคลุม CLI ด้วยตัวเอง
ขั้นตอนที่ 1: เพิ่มไฟล์กฎของโปรเจกต์
Trae อ่านไฟล์กฎก่อนที่ Builder จะเริ่มทำงาน ไฟล์ระดับโปรเจกต์จะอยู่ที่ .trae/rules/project_rules.md ที่ root ของ repository ของคุณ ตาม เอกสารกฎของ Trae เอดเจนต์จะโหลดกฎเหล่านี้ระหว่างการเริ่มต้นและอ้างอิงถึงกฎเหล่านี้ในขณะที่สร้างและแก้ไขโค้ด นอกจากนี้ยังมี user_rules.md ระดับผู้ใช้ที่ใช้ได้กับทุกโปรเจกต์ของคุณ สำหรับเวิร์กโฟลว์นี้ ไฟล์โปรเจกต์ไฟล์เดียวที่ root ของ repo ก็เพียงพอแล้ว
สร้าง .trae/rules/project_rules.md และเพิ่มบล็อกสั้นๆ ที่ระบุชื่อ CLI, คำสั่งสถานการณ์ที่แม่นยำ, และกฎที่ทำให้ Builder ซื่อสัตย์:
## การทดสอบ API ด้วย Apidog CLI
เมื่อคุณเปลี่ยนโค้ดที่เกี่ยวข้องกับ API endpoint ให้ตรวจสอบโดยการรัน
สถานการณ์การทดสอบ Apidog ไม่ใช่แค่การทดสอบหน่วย (unit tests)
Command:
apidog run -t <scenario_id> -e <env_id> -r cli
Rules:
- `apidog run` จะออกด้วยรหัส 0 เมื่อทุก assertion ผ่าน และรหัสไม่เป็นศูนย์เมื่อมีข้อผิดพลาดใดๆ
ถือว่ารหัสออกที่ไม่เป็นศูนย์คือการทดสอบที่ล้มเหลว แม้ว่าสรุปจะดูดีก็ตาม
- เครื่องนี้ได้รับการรับรองความถูกต้องแล้วผ่าน `apidog login` อย่าเพิ่ม
แฟล็ก --access-token และอย่าใส่โทเค็นในไฟล์นี้เด็ดขาด
- หากแฟล็กไม่รู้จัก ให้รัน `apidog run --help` และใช้แฟล็กที่แม่นยำจากที่นั่น
นี่คือเหตุผลที่คุณเขียน CLI ลงใน project_rules.md แทนที่จะกล่าวถึงในแชท ID สถานการณ์ที่พิมพ์ลงในแผงแชทจะหายไปเมื่อเซสชันสิ้นสุด แต่ ID ใน .trae/rules/project_rules.md จะอยู่ที่นั่นสำหรับเพื่อนร่วมทีมทุกคนและทุกครั้งที่ Builder ทำงานนับจากนี้เป็นต้นไป Trae ยังอ่านโฟลเดอร์ .trae/rules/ ในไดเรกทอรีย่อยได้ด้วย ดังนั้น monorepo สามารถเก็บกฎแต่ละบริการไว้ข้างแต่ละบริการได้
ขั้นตอนที่ 2: รับคำสั่งจาก Apidog
คุณไม่จำเป็นต้องเดาคำสั่ง เปิดสถานการณ์การทดสอบใน Apidog ไปที่แท็บ CI/CD แล้วคัดลอกบรรทัด apidog run ที่สร้างขึ้น มันมี scenario ID จริงอยู่แล้วหลัง -t และ environment ID หลัง -e ดังนั้นคุณกำลังวางคำสั่งที่ Apidog รู้ว่าถูกต้อง แทนที่จะสร้าง ID ด้วยมือ
ใส่ ID ที่แน่นอนเหล่านั้นลงในบล็อกใน .trae/rules/project_rules.md แทนที่ตัวยึด <scenario_id> และ <env_id> สำหรับชุดแฟล็กทั้งหมดและสิ่งที่แต่ละแฟล็กทำ ดูที่ การอ้างอิงคำสั่ง apidog run
ขั้นตอนที่ 3: ให้ Builder รันการทดสอบ
เมื่อบล็อกอยู่ในตำแหน่งแล้ว ให้เปลี่ยนเอดเจนต์ของ Trae เป็น Builder และเริ่มต้นใน repo ของคุณ Builder จะโหลด project_rules.md เมื่อมันเริ่มต้น ดังนั้นมันจึงรู้ว่า CLI อยู่ที่นั่นแล้ว ทำการเปลี่ยนแปลงที่เกี่ยวข้องกับ API ของคุณ หรือเพียงแค่ขอให้มันรันการตรวจสอบ:
Run the Apidog test scenario and tell me the exit code.
Builder ออกคำสั่ง apidog run จากไฟล์กฎของคุณ โมเดลการอนุมัติของ Trae มีความสำคัญที่นี่: เมื่อเอดเจนต์ต้องการรันคำสั่งเชลล์ มันจะแนะนำคำสั่งและแสดงปุ่ม Run และคำสั่งจะทำงานในเทอร์มินัลของ Trae หลังจากที่คุณคลิกเท่านั้น เมื่อมันทำงานแล้ว Builder จะอ่านและวิเคราะห์ผลลัพธ์โดยอัตโนมัติ ดังนั้นคุณอนุมัติ apidog run เพียงครั้งเดียว และเอดเจนต์จะนำผลลัพธ์จากที่นั่น
ตัวรายงาน -r cli จะพิมพ์ผลลัพธ์ทีละขั้นตอนและสรุปในเทอร์มินัล ซึ่ง Builder จะอ่านคำขอและการยืนยันแต่ละรายการเมื่อมันเกิดขึ้น คุณต้องการเห็นการทำงานที่กำลังดำเนินการและ Builder รายงานกลับทั้งสรุปและรหัสออก
ขั้นตอนที่ 4: อ่านรายงานภายใน Trae
เมื่อการรันไม่สำเร็จ รายงานมีคำตอบ ด้วย -r cli, Builder จะได้รับรายละเอียดที่อ่านง่ายในเทอร์มินัลของ Trae: แต่ละคำขอ, แต่ละ assertion, และอันไหนที่ล้มเหลวพร้อมค่าที่คาดหวังเทียบกับค่าจริง การตั้งชื่อ assertion ที่ล้มเหลวจะระบุฟิลด์หรือรหัสสถานะที่แน่นอน ซึ่งมักจะเพียงพอสำหรับ Builder ที่จะหาทางแก้ไข
สำหรับรายงานที่คุณสามารถเปิดในเบราว์เซอร์หรือส่งให้เพื่อนร่วมทีมได้ ให้เพิ่มตัวรายงาน HTML:
apidog run -t <scenario_id> -e <env_id> -r cli,html
ตัวรายงาน html จะเขียนไฟล์ที่อยู่ในตัวเองไปยัง ./apidog-reports ให้เก็บ cli ไว้ในรายการเพื่อให้ Builder ยังคงได้รับเอาต์พุตแบบอินไลน์ที่อ่านเพื่อตัดสินใจขั้นตอนต่อไป สำหรับตัวรายงานทุกประเภท รวมถึงรูปแบบ JSON และ JUnit ที่แดชบอร์ด CI แยกวิเคราะห์ได้ ดูที่ คู่มือรายงานการทดสอบ Apidog CLI
Trae การทดสอบภายในวงจรของมันเอง
ประเด็นคือสิ่งที่เกิดขึ้นเมื่อคุณหยุดถาม และ Builder รันสถานการณ์ด้วยตัวเองเพราะ project_rules.md บอกให้มันทำ
ลองนึกภาพ Builder กำลังแก้ไข handler ที่สร้างการตอบกลับการชำระเงิน วงจรของมันจะเปลี่ยนไป: มันแก้ไขโค้ด จากนั้นแทนที่จะประกาศชัยชนะ มันจะรันสถานการณ์ Apidog ของคุณกับ staging, อ่านรหัสออก, และดำเนินการตามนั้น ถ้าเป็นสีเขียว มันก็ไปต่อ ถ้าเป็นสีแดง มันจะเปิดรายงาน อ่านว่า assertion ใดล้มเหลว (รหัสสถานะ, ฟิลด์ที่หายไป, ค่าที่ไม่ถูกต้อง), พยายามแก้ไข, และรันซ้ำ การทดสอบ API จะกลายเป็นส่วนหนึ่งของวงจรแก้ไข-ทดสอบ-แก้ไข เดียวกันที่ Builder ใช้รันการทดสอบหน่วยของคุณอยู่แล้ว คุณเขียนคำสั่งเดียวและ Builder ได้รวมคำสั่งนั้นเข้ากับวิธีการทำงานของมันอยู่แล้ว
นี่คือโมเดลการมอบหมาย-แล้ว-ยืนยัน (delegate-then-verify) ที่ทำให้เวิร์กโฟลว์ของเอดเจนต์ใดๆ ปลอดภัย Builder รันคำสั่งและอ่านผลลัพธ์ คุณยังคงสร้างสถานการณ์ด้วยสายตาใน Apidog และตรวจสอบว่าเอดเจนต์อ่านรหัสออกอย่างซื่อสัตย์ สำหรับรูปแบบที่กว้างขึ้น ดู วิธีใช้ AI agents สำหรับการทดสอบ API และ Apidog AI test harness
ยืนยันว่า Trae กำลังรัน CLI จริงๆ
เอดเจนต์รายงานความสำเร็จที่พวกเขาไม่ได้ทำ และ Builder ก็ไม่มีข้อยกเว้น มีการตรวจสอบสามข้อ ตามลำดับความบ่อยที่พวกเขาสามารถจับปัญหาได้
ประการแรก ยืนยันว่าคำสั่งทำงานเลยหรือไม่ Trae จะแสดงคำสั่งที่ Builder ประมวลผลและผลลัพธ์ในเทอร์มินัล มองหาบรรทัด apidog run และผลลัพธ์ภายใต้บรรทัดนั้น หาก Builder บอกว่ารันการทดสอบแล้วแต่คุณไม่เห็นคำสั่ง แสดงว่ามันสรุปสิ่งที่มันไม่เคยทำไปแล้ว ขอให้มันรันอีกครั้งและแสดงผลลัพธ์ดิบ
ประการที่สอง ยืนยันรหัสออก:
What was the exit code of that apidog run command?
apidog run จะออกด้วยรหัส 0 เมื่อทุก assertion ผ่าน และรหัสไม่เป็นศูนย์เมื่อมีข้อผิดพลาดใดๆ พฤติกรรมเดียวนี้ทำให้ Builder หรือ pipeline สามารถถือว่าการรันนั้นเป็นด่านที่สะอาดได้ เมื่อข้อความของ Builder บอกว่า "การทดสอบผ่าน" แต่รหัสออกไม่เป็นศูนย์ รหัสออกนั้นถูกต้อง
ประการที่สาม ยืนยันว่ามันใช้สถานการณ์จริง หากการรันล้มเหลวด้วยข้อความ "scenario not found" Builder อาจสร้างหรือจำ ID ผิด ตรวจสอบค่า -t และ -e อีกครั้งกับ project_rules.md และคำสั่งที่ Apidog สร้างในแท็บ CI/CD ID ในไฟล์กฎของคุณคือความจริง
ทางเลือก: เชื่อมต่อเซิร์ฟเวอร์ Apidog MCP
การรัน apidog run จาก project_rules.md ครอบคลุมสิ่งที่คุณต้องการส่วนใหญ่ การเชื่อมต่อเซิร์ฟเวอร์ MCP ไปได้อีกขั้น เอดเจนต์ Trae ทำหน้าที่เป็นไคลเอนต์ MCP ดังนั้น Builder จึงสามารถเรียกใช้เครื่องมือที่เซิร์ฟเวอร์ MCP เปิดเผยได้
ในการเพิ่มเซิร์ฟเวอร์ ให้เปิดการตั้งค่าของ Trae ไปที่แท็บ MCP แล้วเลือกเซิร์ฟเวอร์จาก marketplace หรือเลือก Add Manually และวางบล็อก JSON ที่มี command, args, และ env ของเซิร์ฟเวอร์ ตาม คู่มือการเพิ่มเซิร์ฟเวอร์ MCP ของ Trae เซิร์ฟเวอร์ Apidog MCP จะเปิดเผยข้อกำหนด API ของคุณผ่าน MCP ดังนั้น Builder จึงสามารถอ่านสคีมาของคุณในขณะที่เขียนโค้ด ไม่ใช่แค่หลังจากนั้น การแบ่งงานชัดเจน: CLI รันการทดสอบ และ MCP ป้อนข้อมูลสเปคให้เอดเจนต์
เมื่อ Trae ทำผิดพลาด
ความล้มเหลวบางอย่างมักเกิดขึ้นระหว่างการตั้งค่า
มันเพิกเฉยต่อไฟล์กฎ หาก Builder รันคำสั่งทั่วไปหรือไม่รันเลย ไฟล์อาจไม่ถูกโหลด ยืนยันว่าไฟล์อยู่ที่ .trae/rules/project_rules.md ที่ root ของ repository ของคุณ และโฟลเดอร์มีชื่อว่า rules ไม่ใช่ rule การรีสตาร์ทเซสชันจะบังคับให้อ่านกฎใหม่
มันยังคงส่ง access token อยู่ดี หาก Builder พยายามเพิ่ม --access-token แสดงว่ามันเดาจากตัวอย่างสาธารณะ บล็อกนั้นได้บอกมันแล้วว่าอย่าทำเช่นนั้น เนื่องจากเครื่องได้รับการรับรองความถูกต้องผ่าน apidog login ตอกย้ำบรรทัดนั้น และอย่าใส่โทเค็นจริงลงใน project_rules.md สำหรับวิธีที่ CLI จัดการข้อมูลรับรองในการใช้งานแบบโต้ตอบและใน CI ดู การรับรองความถูกต้องของ Apidog CLI
มันสร้างแฟล็กขึ้นมาเอง ข้อผิดพลาด "unknown option" หมายความว่า Builder เดาแฟล็กที่เวอร์ชันของคุณไม่มี บอกให้มันรัน apidog run --help แล้วคัดลอกแฟล็กที่ถูกต้องจากที่นั่น ซึ่งจะถูกต้องเสมอสำหรับเวอร์ชันที่คุณติดตั้ง
มันรายงานว่าผ่านในการรันที่ล้มเหลว นี่คือสิ่งที่แพงที่สุด และเป็นเหตุผลว่าทำไมกฎรหัสออกถึงอยู่ใน project_rules.md ของคุณและขั้นตอนการตรวจสอบของคุณ เมื่อสรุปและรหัสออกไม่ตรงกัน รหัสออกคือสิ่งที่ถูกต้อง
จากเอดเจนต์รายวันสู่วงจรที่ผ่านการทดสอบ
นั่นคือการตั้งค่า ติดตั้ง apidog-cli เพียงครั้งเดียวตาม คู่มือการติดตั้ง เพิ่มบล็อก Apidog สั้นๆ ลงใน .trae/rules/project_rules.md แล้ว Builder ก็จะรู้วิธีรันการทดสอบ API ของคุณและอ่านผลลัพธ์ภายในวงจรเดียวกันกับที่มันใช้แก้ไขโค้ดอยู่แล้ว Endpoint ที่เสียจะถูกตรวจพบในขณะที่ Builder ยังคงทำงานกับการเปลี่ยนแปลง ไม่ใช่หลังจากที่มันถูกส่งไปแล้ว
การทดสอบที่อยู่เบื้องหลัง GUI จะรันเมื่อมนุษย์คลิก; คำสั่งบรรทัดเดียวจะรันเมื่อใดก็ตามที่ Builder ตัดสินใจ คุณยังคงสร้างสถานการณ์ด้วยสายตาใน Apidog และเอดเจนต์ของคุณจะรันมันในที่ที่คุณไม่เห็น ดาวน์โหลด Apidog สร้างสถานการณ์เดียว วางคำสั่ง apidog run ลงใน .trae/rules/project_rules.md และดู Builder เลือกใช้ในการเปลี่ยนแปลงครั้งต่อไป เมื่อคุณพร้อมที่จะรันสถานการณ์เดียวกันโดยไม่มีเอดเจนต์ Apidog CLI ใน GitHub Actions จะครอบคลุมเรื่องความลับ, ตัวรายงาน, และการกำหนดเงื่อนไขด้วยรหัสออกสำหรับ CI