วิธีรันการทดสอบ API จาก Apidog CLI

การทดสอบ API ของคุณผ่านบนแล็ปท็อป จากนั้นมีคนผสานการเปลี่ยนแปลงตอนตี 2 Endpoint ของ staging ก็เริ่มส่งข้อมูลผิดพลาดกลับมา และไม่มีใครสังเกตเห็นจนกว่าลูกค้าจะแจ้งปัญหาในเช้าวันรุ่งขึ้น การทดสอบนั้นมีอยู่แล้ว แต่มันไม่เคยถูกรันในที่ที่สำคัญ: ใน Pipeline ทุกครั้งที่มีการ Push โดยไม่มีมนุษย์ต้องคลิกปุ่มใดๆ

ช่องว่างระหว่าง "การทดสอบที่มีอยู่" กับ "การทดสอบที่ทำงานโดยอัตโนมัติ" คือสิ่งที่ Command-Line Runner เข้ามาช่วยเติมเต็ม Apidog CLI นำสถานการณ์การทดสอบที่คุณสร้างไว้แล้วในแอปพลิเคชัน Apidog บนเดสก์ท็อปหรือเว็บมารันแบบ Headless จาก Terminal โดยไม่มี GUI และไม่ต้องคลิกด้วยตนเอง คุณสามารถติดตั้งได้ด้วยคำสั่ง npm เพียงคำสั่งเดียว กำหนดเป้าหมายไปยังสถานการณ์การทดสอบ และมันจะออกด้วยรหัสสถานะที่ชัดเจนพร้อมรายงานที่คุณสามารถเผยแพร่ในระบบ CI ใดก็ได้ สิ่งนี้ทำให้มันเป็นสะพานเชื่อมระหว่าง Visual Test Builder กับแพลตฟอร์ม CI/CD ของคุณ

TL;DR

• Apidog CLI เป็นแพ็คเกจ npm ที่ชื่อว่า apidog-cli ติดตั้งทั่วโลกด้วย npm install -g apidog-cli จากนั้นรันสถานการณ์ด้วยคำสั่ง apidog run
• มันรันสถานการณ์การทดสอบที่คุณออกแบบใน Apidog คุณไม่จำเป็นต้องเขียนการทดสอบใหม่เป็นโค้ด; CLI จะดำเนินการสถานการณ์เดียวกันโดยใช้ ID โดยใช้ Access Token สำหรับการรับรองความถูกต้อง
• การรันหลัก: apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenarioId> -e <environmentId> -n 1 -r html,cli
• Reporters ครอบคลุม cli, html, json และ junit ไฟล์ JUnit XML คือสิ่งที่เชื่อมต่อโดยตรงกับแดชบอร์ดการทดสอบของ CI
• รหัสออกที่ไม่ใช่ศูนย์เมื่อการทดสอบล้มเหลวคือสิ่งที่ทำให้ CLI เป็น Quality Gate ที่แท้จริง การทดสอบที่ล้มเหลวจะทำให้ Build ล้มเหลวโดยค่าเริ่มต้น
• มันทำงานได้ใน CI Runner ใดๆ ที่มี Node.js: GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines และอื่นๆ

Apidog CLI คืออะไรกันแน่

Apidog เป็นแพลตฟอร์ม API แบบครบวงจร: คุณออกแบบ Schema, ดีบัก Requests, สร้างสถานการณ์การทดสอบอัตโนมัติ, Mock Endpoints และเผยแพร่เอกสารใน Workspace เดียวกัน งานส่วนใหญ่เกิดขึ้นในส่วนติดต่อผู้ใช้แบบภาพ (Visual Interface) คุณเชื่อมต่อ Requests เข้าด้วยกันเป็นสถานการณ์การทดสอบ เพิ่ม Assertions ดึงค่าจาก Response หนึ่งไปยังอีก Response หนึ่ง และวนซ้ำข้อมูลจากไฟล์ข้อมูล

CLI คือผู้ดำเนินการแบบ Headless สำหรับสถานการณ์เหล่านั้น มันไม่มีรูปแบบการทดสอบของตัวเอง มันเข้าถึงโปรเจกต์ Apidog ของคุณ ค้นหาสถานการณ์ที่คุณระบุด้วย ID และรันมันเหมือนกับที่แอปพลิเคชันจะทำ จากนั้นรายงานผลกลับมา ลองนึกถึงความสัมพันธ์ระหว่าง Build Tool กับ Source Code ของคุณ: Source of Truth อยู่ในโปรเจกต์ และ CLI คือสิ่งที่รันมันโดยไม่มีคนอยู่ด้วย

สิ่งนี้สำคัญเพราะมันช่วยขจัดสาเหตุที่พบบ่อยที่สุดที่ทำให้ API Tests ล้าสมัย เมื่อการทดสอบเป็นเพียงขั้นตอนที่คลิกได้ในแอปพลิเคชันบนเดสก์ท็อป มันจะถูกรันเมื่อมีคนจำได้ แต่เมื่อมันรันจากคำสั่งเพียงบรรทัดเดียว คุณสามารถเชื่อมต่อมันเข้ากับ Pipeline และมันจะรันทุกครั้งที่ Commit, ทุกครั้งที่ Merge, ทุกตารางเวลาตอนกลางคืน Visual Builder ช่วยให้คุณสร้างได้อย่างรวดเร็ว; CLI ช่วยให้คุณทำงานโดยอัตโนมัติ คุณจะได้รับทั้งสองอย่างโดยไม่ต้องเลือก

หากคุณมาจากโลกของ Postman โมเดลทางความคิดจะตรงกันอย่างชัดเจน Apidog CLI ทำหน้าที่เหมือนกับ Postman CLI หรือ Newman ที่ทำสำหรับ Postman Collections ยกเว้นว่ามันรัน Apidog Test Scenarios และมาในรูปแบบแพ็คเกจเดียว เราได้เปรียบเทียบเชิงลึกไว้ใน Postman CLI vs Newman และคำถามที่กว้างขึ้นเกี่ยวกับ การรัน Collections ใน CI โดยไม่มี Newman หากคุณกำลังย้ายแพลตฟอร์ม

ข้อกำหนดเบื้องต้น

ก่อนที่คุณจะรันคำสั่งใดๆ คุณต้องมีสามสิ่งนี้:

1. Node.js v16 หรือใหม่กว่า CLI มาในรูปแบบแพ็คเกจ npm ดังนั้น Node Runtime เป็น System Dependency เดียวเท่านั้น ตรวจสอบของคุณด้วย node -v อิมเมจ CI ใดๆ ที่มี Node 16+ ก็ใช้ได้แล้ว
2. Apidog Test Scenario CLI รัน Scenarios ไม่ใช่ Requests ที่แยกจากกัน สร้างหนึ่งในแอป Apidog ก่อน: เชื่อมต่อ Requests ของคุณ เพิ่ม Assertions ตั้งค่า Data-Driven Iteration ที่คุณต้องการ หากคุณยังใหม่กับการเขียน Assertions, API assertions: a practical guide จะแนะนำการตรวจสอบ Responses
3. Access Token สิ่งนี้ใช้ยืนยันตัวตน CLI กับบัญชี Apidog ของคุณเพื่อให้สามารถดึงและรัน Scenario ได้ คุณสร้างมันในแท็บ CI/CD ของ Test Scenario; เพิ่มเติมเกี่ยวกับเรื่องนี้ด้านล่าง

แค่นั้นแหละ ไม่มีการติดตั้ง Apidog แยกต่างหากบนเครื่อง CI, ไม่มี GUI, ไม่มีไฟล์ไลเซนส์ แพ็คเกจและ Token ก็เพียงพอแล้ว

การติดตั้ง Apidog CLI

ติดตั้งทั่วโลกด้วย npm:

npm install -g apidog-cli

จากนั้นยืนยันว่าทุกอย่างทำงานได้ถูกต้อง:

node -v && apidog -v && which node && which npm && which apidog

หากสิ่งนั้นแสดงหมายเลขเวอร์ชันและพาธ แสดงว่าคุณทำเสร็จแล้ว ไบนารีคือ apidog ดังนั้นทุกคำสั่งจะเริ่มต้นด้วย apidog run

บนเครื่องนักพัฒนา การติดตั้งทั่วโลกก็ใช้ได้ ใน CI คุณมีสองรูปแบบที่เหมาะสม รูปแบบแรกคือการติดตั้งใหม่ทุกครั้งที่ Pipeline ทำงาน ซึ่งรับประกันว่าคุณใช้เวอร์ชันล่าสุด:

npm install -g apidog-cli
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

รูปแบบที่สองคือการรันโดยไม่มีการติดตั้งทั่วโลกแบบถาวรผ่าน npx ซึ่งช่วยหลีกเลี่ยงการเปลี่ยนแปลงแพ็คเกจทั่วโลกของ Runner:

npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

ทั้งสองวิธีใช้ได้ วิธี npx สะอาดกว่าสำหรับ CI Runners ชั่วคราว; การติดตั้งทั่วโลกจะเร็วกว่าเล็กน้อยเมื่อคุณแคชระหว่างการรัน

การรับ Access Token และ Scenario ID ของคุณ

CLI ต้องรู้สองสิ่ง: จะรัน Scenario ใด และได้รับอนุญาตให้รันหรือไม่ Apidog สร้างให้คุณทั้งคู่ ดังนั้นคุณไม่จำเป็นต้องค้นหาใน UI

เปิด Scenario การทดสอบที่คุณต้องการทำงานอัตโนมัติ สลับไปที่แท็บ CI/CD เลือกตัวเลือก Command-Line จากนั้นคลิก Add access token และ Generate token Apidog จะสร้างคำสั่ง apidog run เต็มรูปแบบให้คุณ โดยมี Access Token, Scenario ID และ Environment ID กรอกไว้แล้ว คลิกที่คำสั่งเพื่อคัดลอก

คำสั่งที่สร้างขึ้นนั้นเป็นจุดเริ่มต้นที่ถูกต้อง มันดูเหมือนแบบนี้:

apidog run --access-token YOUR_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,cli

ตัวเลขคือ ID จริงจากโปรเจกต์ของคุณ 605067 คือ Test Scenario ID 1629989 คือ Environment ID คุณแทบจะไม่พิมพ์สิ่งเหล่านี้ด้วยตัวเอง; คุณคัดลอกมันจากแท็บ CI/CD เพียงครั้งเดียวแล้วกำหนดพารามิเตอร์ Token

กฎหนึ่งที่ควรกล่าวถึงตั้งแต่เนิ่นๆ: ปฏิบัติต่อ Access Token เหมือนรหัสผ่าน อย่าแปะมันลงในไฟล์ Config ที่ Commit แล้ว หรือใน Pipeline Definition สาธารณะ เก็บเป็น Secret ในระบบ CI ของคุณและอ้างอิงเป็น Environment Variable ตัวอย่างทั้งหมดด้านล่างใช้ $APIDOG_ACCESS_TOKEN ด้วยเหตุผลนี้

คำสั่ง apidog run แบบละเอียดทีละ Flag

CLI ทั้งหมดหมุนรอบคำสั่งเดียว นี่คือตัวเลือกทั้งหมดที่สามารถใช้ได้ โดยจัดกลุ่มตามสิ่งที่แต่ละกลุ่มควบคุม

การเลือกสิ่งที่ต้องรัน

คุณเลือกหนึ่งใน -t, -f หรือ --test-suite ขึ้นอยู่กับขอบเขต Scenario เดียวสำหรับการทดสอบ Smoke Test ที่เน้น, โฟลเดอร์สำหรับพื้นที่ฟีเจอร์, Test Suite เมื่อคุณต้องการให้ชุดของ Scenarios ที่เลือกไว้รันพร้อมกันเป็นงานเชิงตรรกะเดียว

การรับรองความถูกต้อง

นี่คือ Flag เดียวที่ทุกคำสั่ง CI ต้องการ ส่งผ่านจาก Secret อย่าใส่ในบรรทัดเดียวกัน

สภาพแวดล้อมและการวนซ้ำ

แฟล็ก Environment คือวิธีที่คุณชี้ Scenario เดียวกันไปยัง Staging ในการตรวจสอบ Pull-request และไปยัง Production ใน Smoke Test หลังการ Deploy โดยไม่ต้องสร้าง Scenario ซ้ำซ้อน Iteration Data คือวิธีที่คุณรัน Scenario หนึ่งครั้งกับอินพุตห้าสิบแถวและถือว่าแต่ละแถวเป็นการผ่านแยกต่างหาก เราครอบคลุมรูปแบบ Data-driven อย่างสมบูรณ์ในคู่มือเกี่ยวกับการ ปรับขนาดการทดสอบ API อัตโนมัติด้วย Test Suites

รายงาน

นี่คือจุดที่ CLI มีความสำคัญใน Pipeline ส่งผ่านหลายรูปแบบพร้อมกัน โดยคั่นด้วยเครื่องหมายจุลภาค:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -r html,junit --out-dir ./test-reports

cli ให้เอาต์พุต Terminal ที่อ่านง่ายสำหรับมนุษย์ที่อ่าน Log ของ Build html สร้างรายงานที่รวมอยู่ในตัวที่คุณสามารถเก็บถาวรเป็น Artifact ของ Build และเปิดในเบราว์เซอร์ junit ส่งออก XML ในรูปแบบ JUnit มาตรฐาน ซึ่งแดชบอร์ด CI เกือบทั้งหมดรู้วิธี Parse เป็น Pass/Fail Tree json ให้ผลลัพธ์ที่มีโครงสร้างดิบหากคุณต้องการประมวลผลเพิ่มเติม

การจัดการข้อผิดพลาดและพฤติกรรมการออก

--on-error ควบคุมสิ่งที่เกิดขึ้นระหว่าง Scenario end หยุดการรันเมื่อเกิดความล้มเหลวครั้งแรก ซึ่งเป็นสิ่งที่คุณมักจะต้องการสำหรับการทดสอบ Smoke Test ที่ล้มเหลวอย่างรวดเร็ว continue รันทุกขั้นตอนเพื่อให้คุณเห็นความล้มเหลวทั้งหมดในรายงานเดียว ignore สำหรับกรณีที่หายากที่ขั้นตอนเป็นที่รู้กันว่า Flaky และคุณไม่ต้องการให้มันขัดขวางการรัน

TLS และใบรับรอง

ใช้สิ่งเหล่านี้เมื่อคุณทดสอบ Endpoint ที่อยู่เบื้องหลัง Mutual TLS หรือด้วย Internal CA Chains ใช้ -k เฉพาะกับ Internal Hosts ที่เชื่อถือได้ซึ่ง Cert นั้นเป็น Self-Signed; ห้ามใช้กับ Public ใดๆ

เอาต์พุตและการวินิจฉัย

--verbose คือการดำเนินการแรกของคุณเมื่อการทดสอบผ่านในเครื่องแต่ล้มเหลวใน CI; มันจะแสดง Request ที่ Runner ส่งไปอย่างแม่นยำ และ Response ที่ได้รับกลับมาอย่างแม่นยำ --silent ใช้สำหรับ Nightly Jobs ที่มีเสียงดัง ซึ่งคุณสนใจเฉพาะรหัสออกและรายงานที่บันทึกไว้

Exit codes: ส่วนที่ทำให้ CI ทำงาน

Test Runner จะมีประโยชน์ใน Pipeline ก็ต่อเมื่อมันบอก Pipeline ว่าการทดสอบผ่านหรือไม่ Apidog CLI ทำเช่นนี้ในแบบที่เครื่องมือ Command-Line ที่ทำงานได้ดีทุกตัวทำ: มันออกด้วยรหัส 0 เมื่อทุก Assertion ผ่าน และรหัสที่ไม่ใช่ศูนย์เมื่อมีบางอย่างล้มเหลว

พฤติกรรมเดียวนี้คือสิ่งที่เปลี่ยน apidog run ให้เป็น Quality Gate ระบบ CI อ่านรหัสออกของแต่ละขั้นตอน รหัสออกที่ไม่ใช่ศูนย์จะทำเครื่องหมายขั้นตอนว่าล้มเหลว ซึ่งทำให้ Job ล้มเหลว ซึ่งจะบล็อกการ Merge หรือการ Deploy คุณไม่ต้องกำหนดค่าอะไรเพิ่มเติม ตราบใดที่ขั้นตอน apidog run อยู่ใน Pipeline ของคุณ การทดสอบที่ล้มเหลวจะหยุดการทำงาน

คุณสามารถปรับแต่งสิ่งนี้ด้วย --on-error พฤติกรรมเริ่มต้นจะล้มเหลวเมื่อ Assertion ที่เสียครั้งแรก ซึ่งช่วยให้ได้ Feedback อย่างรวดเร็ว เปลี่ยนเป็น --on-error continue เมื่อคุณต้องการเห็นความล้มเหลวทั้งหมดในรายงานเดียวก่อนที่ Build จะเป็นสีแดง ไม่ว่าในกรณีใด การรันก็ยังคงจบลงด้วยรหัสออกที่ไม่ใช่ศูนย์หากมีสิ่งใดล้มเหลว ดังนั้น Gate จึงยังคงทำงานอยู่

การรันใน GitHub Actions

Workflow ที่สมบูรณ์แบบที่รัน Apidog Scenario ในทุก Pull Request และเผยแพร่รายงานเป็น Artifact

name: API tests

on:
 pull_request:
 branches: [main]

jobs:
 api-tests:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v4

 - name: Set up Node.js
 uses: actions/setup-node@v4
 with:
 node-version: '20'

 - name: Install Apidog CLI
 run: npm install -g apidog-cli

 - name: Run API test scenario
 run: |
 apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -t 605067 \
 -e 1629989 \
 -n 1 \
 -r html,junit \
 --out-dir ./apidog-reports
 env:
 APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

 - name: Upload report
 if: always()
 uses: actions/upload-artifact@v4
 with:
 name: apidog-report
 path: ./apidog-reports

โทเค็นอยู่ใน Repository Secrets และเข้าถึงขั้นตอนเป็น Environment Variable if: always() ในขั้นตอนการอัปโหลดหมายความว่าคุณยังคงได้รับรายงานแม้ว่าการทดสอบจะล้มเหลว ซึ่งเป็นเวลาที่คุณต้องการอ่านมันมากที่สุด หากการทดสอบล้มเหลว ขั้นตอน apidog run จะออกด้วยรหัสที่ไม่ใช่ศูนย์ Job จะเป็นสีแดง และ PR จะแสดงสถานะการตรวจสอบที่ล้มเหลว

การรันใน GitLab CI

รูปแบบเดียวกันใน .gitlab-ci.yml:

stages:
 - test

api-tests:
 stage: test
 image: node:20
 script:
 - npm install -g apidog-cli
 - >
 apidog run
 --access-token "$APIDOG_ACCESS_TOKEN"
 -t 605067
 -e 1629989
 -r junit,cli
 --out-dir ./apidog-reports
 artifacts:
 when: always
 paths:
 - apidog-reports/
 reports:
 junit: apidog-reports/*.xml

มีสองสิ่งที่ควรทราบ เก็บ APIDOG_ACCESS_TOKEN เป็น Masked, Protected CI/CD Variable ภายใต้ Settings ไม่ใช่ในไฟล์ และบล็อก reports: junit: บอก GitLab ให้ Parse JUnit XML และแสดงผลลัพธ์ใน Merge Request Widget เพื่อให้ผู้ตรวจสอบเห็นว่า Assertions ใดล้มเหลวโดยไม่ต้องดาวน์โหลดอะไร

การรันใน Jenkins

ใน Declarative Pipeline ให้เก็บ Token เป็น Jenkins Credential หรือ Global Environment Variable จากนั้นเรียก CLI ใน Stage:

pipeline {
 agent any
 environment {
 APIDOG_ACCESS_TOKEN = credentials('apidog-access-token')
 }
 stages {
 stage('API tests') {
 steps {
 sh 'npm install -g apidog-cli'
 sh 'apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit --out-dir apidog-reports'
 }
 }
 }
 post {
 always {
 junit 'apidog-reports/*.xml'
 archiveArtifacts artifacts: 'apidog-reports/', allowEmptyArchive: true
 }
 }
}

หาก Build Agent ของคุณติดตั้งและแคช CLI ไว้แล้ว ให้ลบไลน์ npm install ออกและเรียก apidog run โดยตรง ขั้นตอน junit ในบล็อก post จะป้อน XML ไปยังกราฟแนวโน้มการทดสอบของ Jenkins; archiveArtifacts จะเก็บรายงาน HTML แนบไปกับ Build หากคุณกำลังพิจารณา Jenkins เทียบกับ Runners อื่นๆ การเปรียบเทียบใน การตั้งค่า ReadyAPI Jenkins CI และทางเลือกที่ง่ายกว่า ครอบคลุมถึงข้อดีข้อเสีย

รูปแบบและสูตรอาหารทั่วไป

Smoke Test หลังการ Deploy รัน Scenario ที่รวดเร็วหนึ่งครั้งกับ Production ทันทีหลังการ Release โดยกำหนดเป้าหมายไปที่ Prod Environment:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e <prodEnvId> -r cli --on-error end

Full Regression Nightly รันทั้งโฟลเดอร์ของ Scenarios ตามกำหนดเวลา โดยรวบรวมความล้มเหลวทั้งหมดไว้ในรายงานเดียว:

apidog run --access-token $APIDOG_ACCESS_TOKEN -f <folderId> -r html,junit --on-error continue --out-dir ./nightly-reports

Data-Driven Run วนซ้ำ Scenario หนึ่งครั้งกับไฟล์ CSV ของ Test Cases:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -d ./test-data.csv -r junit

Branch-Specific Check รัน Scenarios ตามที่มีอยู่ใน Feature Branch ไม่ใช่ main:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 --branch feature-payments -e 1629989 -r cli

Debug ข้อผิดพลาดเฉพาะ CI เมื่อ Scenario ผ่านในเครื่องแต่ล้มเหลวใน Pipeline ให้เพิ่ม --verbose เพื่อดู Request และ Response ระดับ Wire ที่ Runner สร้างขึ้นอย่างแม่นยำ

การแก้ไขปัญหา

ข้อผิดพลาดในการยืนยันตัวตน หากการรันล้มเหลวด้วยข้อผิดพลาดในการยืนยันตัวตน แสดงว่า Token ผิด, หมดอายุ หรือไม่เข้าถึงคำสั่ง Echo การตรวจสอบแบบ Masked (ห้ามแสดง Token เต็ม) และยืนยันว่า CI Secret ของคุณมีการตั้งค่าจริงๆ สร้าง Token ใหม่จากแท็บ CI/CD ของ Scenario หากจำเป็น

"Scenario ไม่พบ" Scenario ID, Project ID หรือ Branch ไม่ตรงกัน คัดลอกคำสั่งใหม่จากแท็บ CI/CD เพื่อให้มั่นใจว่า ID เป็นปัจจุบัน และยืนยันว่า --branch ชี้ไปยังตำแหน่งที่คุณคาดหวัง

การทดสอบผ่านในเครื่องแต่ล้มเหลวใน CI ส่วนใหญ่เกิดจากความแตกต่างของ Environment CI Runner อาจกำหนดเป้าหมายไปที่ Environment -e ที่แตกต่างกัน, เข้าถึง Host ที่ไม่สามารถเข้าถึงได้ หรือไม่มี Variable ที่ Scenario ของคุณขึ้นอยู่กับ รันด้วย --verbose และเปรียบเทียบ Request ที่ CI Runner ส่งกับสิ่งที่คุณส่งในเครื่อง

ข้อผิดพลาดของ Network หรือ TLS กับ Internal Hosts หาก Endpoint ของคุณใช้ Internal CA ให้ส่ง --ssl-extra-ca-certs ใช้ -k เฉพาะเป็นทางเลือกสุดท้ายบน Internal Hosts ที่เชื่อถือได้ซึ่ง Certificate นั้นเป็น Self-Signed

Build ยังคงเป็นสีเขียวแม้ว่าการทดสอบควรจะล้มเหลว ยืนยันว่า Exit Code ของขั้นตอน apidog run เข้าถึง CI จริงๆ หากคุณได้ครอบมันด้วย Shell Pipeline หรือเพิ่ม || true Exit Code ที่ไม่ใช่ศูนย์จะถูกกลืนหายไปและ Gate จะหยุดทำงาน ลบสิ่งใดๆ ที่ Mask Exit Code ออก

Apidog CLI เข้ากับ Workflow จริงได้อย่างไร

CLI เป็นส่วนหนึ่งของ Loop คุณออกแบบและดีบัก Requests ในแอป Apidog คุณเชื่อมโยง Requests เหล่านั้นเข้ากับ Scenario พร้อม Assertions คุณ Commit งานของคุณและ CLI รัน Scenario นั้นใน CI ทุกครั้งที่มีการเปลี่ยนแปลง เมื่อมีบางอย่างเสียหาย รายงานจะบอกคุณว่า Assertion ใดล้มเหลวและ Exit Code จะหยุดการ Deploy คุณแก้ไขมัน Push อีกครั้ง และ Gate เดียวกันจะยืนยันการแก้ไข

ข้อดีของการสร้างการทดสอบด้วย Visual และการรันแบบ Headless คือ ไม่มีใครต้องดูแลการแสดงผลสองแบบของการทดสอบเดียวกัน Scenario ในโปรเจกต์คือการทดสอบ CLI เป็นเพียงผู้ดำเนินการในที่ที่มนุษย์ไม่สามารถอยู่ได้ นี่คือโมเดลที่แตกต่างจาก Script-First Runners ที่การทดสอบและการดำเนินการเป็นไฟล์เดียวกันที่เปราะบาง และเป็นส่วนสำคัญที่ทำให้ทีมย้ายไปใช้ Apidog เป็นทางเลือกของ Postman สำหรับการทดสอบ API

หากคุณยังไม่ได้สร้างการทดสอบ ให้เริ่มต้นในแอป ทำให้ Scenario หนึ่งผ่าน จากนั้นเชื่อมต่อคำสั่ง CLI จากแท็บ CI/CD ของมัน ดาวน์โหลด Apidog เพื่อตั้งค่า Scenario อัตโนมัติครั้งแรกของคุณ และคุณจะมีการตรวจสอบ Pipeline ในบ่ายวันเดียวกันนั้น

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

Apidog CLI ฟรีหรือไม่ ตัว CLI เองเป็นแพ็คเกจ npm ฟรี คุณติดตั้งด้วย npm install -g apidog-cli มันรัน Test Scenarios จากโปรเจกต์ Apidog ของคุณ ดังนั้นสิ่งที่คุณสามารถรันได้ขึ้นอยู่กับแผน Apidog ของคุณ แต่ Command-Line Runner ไม่ใช่ผลิตภัณฑ์ที่ต้องชำระเงินแยกต่างหาก

ฉันต้องเขียนการทดสอบใหม่เป็นโค้ดเพื่อใช้ CLI หรือไม่ ไม่ นั่นคือความแตกต่างหลักจาก Script-First Runners คุณสร้าง Scenarios ด้วย Visual ใน Apidog และ CLI รันมันด้วย ID Scenario คือการทดสอบ CLI เป็นเพียงผู้ดำเนินการ

อะไรคือความแตกต่างระหว่าง Apidog CLI กับ Newman? Newman รัน Postman Collections จาก Command Line Apidog CLI รัน Apidog Test Scenarios บทบาทคล้ายกัน แต่ Apidog Runner ดำเนินการ Scenarios ที่คุณเขียนในแอป Apidog และมาในรูปแบบแพ็คเกจ apidog-cli เดียว ดู Postman CLI vs Newman สำหรับการเปรียบเทียบในฝั่ง Postman

ฉันควรใช้รูปแบบรายงานใดใน CI? ใช้ junit สำหรับผลลัพธ์ที่เครื่องอ่านได้ ซึ่งแดชบอร์ด CI ของคุณจะ Parse เป็น Pass/Fail Tree และเพิ่ม html หากคุณต้องการรายงานที่สามารถเรียกดูได้ซึ่งบันทึกเป็น Build Artifact ตัวเลือกทั่วไปคือ -r html,junit เปิด cli ไว้ด้วยหากคุณต้องการเอาต์พุตที่อ่านง่ายใน Build Log

CLI ทำให้ Build ล้มเหลวได้อย่างไร? ด้วย Exit Code ของมัน เมื่อ Assertion ใดๆ ล้มเหลว apidog run จะออกด้วยรหัสที่ไม่ใช่ศูนย์ ระบบ CI อ่าน Exit Code นั้น ทำเครื่องหมายขั้นตอนว่าล้มเหลว และบล็อกการ Merge หรือการ Deploy คุณไม่ต้องกำหนดค่าอะไรเพิ่มเติมเพื่อให้สิ่งนี้ทำงาน

ฉันสามารถรัน CLI โดยไม่ต้องติดตั้งทั่วโลกได้หรือไม่? ได้ ใช้ npx apidog-cli run ... เพื่อดำเนินการโดยไม่ต้องมีการติดตั้งทั่วโลกแบบถาวร ซึ่งสะดวกสำหรับ CI Runners ชั่วคราว

ฉันต้องใช้ Node.js เวอร์ชันใด? Node.js v16 หรือใหม่กว่า อิมเมจ CI สมัยใหม่ใดๆ ที่มี Node 16+ ก็เป็นไปตามข้อกำหนดแล้ว

ฉันจะรับ Access Token และ Scenario ID ได้ที่ไหน? ทั้งสองอย่างมาจากแท็บ CI/CD ของ Test Scenario ใน Apidog เลือกตัวเลือก Command-Line สร้าง Access Token และคัดลอกคำสั่ง apidog run เต็มรูปแบบที่ Apidog สร้างให้คุณพร้อม ID ที่กรอกไว้แล้ว จากนั้นย้าย Token ไปยัง CI Secret