วิธีทำการทดสอบ API แบบอัตโนมัติใน Travis CI โดยใช้ Apidog CLI?

API ของคุณทำงานบนเครื่องของคุณ Unit test ผ่านหมด คุณรวมโค้ด, deploy, และหนึ่งชั่วโมงต่อมา เพื่อนร่วมทีมก็ส่งข้อความหาคุณว่า: /checkout endpoint ส่งค่า 500 กลับมาสำหรับผู้ที่มีตะกร้าสินค้าว่างเปล่า ข้อผิดพลาดนี้ไม่เคยอยู่ในโค้ดที่คุณเปลี่ยนแปลงเลย แต่มันอยู่ในสัญญาที่อยู่ห่างออกไปสอง service ที่ไม่มีใครทดสอบซ้ำ นี่คือช่องว่างที่การทดสอบ API ระดับ integration มาเติมเต็ม และนี่คือการตรวจสอบที่คุณต้องการให้รันอัตโนมัติในการ commit ทุกครั้ง แทนที่จะอยู่ในหัวของใครบางคน

Travis CI เป็นหนึ่งในบริการ Continuous Integration แบบโฮสต์ที่เก่าแก่ที่สุด และยังคงทำสิ่งหนึ่งได้ดี: มันคอยเฝ้าดู Git repository ของคุณ, สร้างสภาพแวดล้อมที่สะอาดสำหรับการ push และ pull request ทุกครั้ง, และรันคำสั่งใดๆ ที่คุณใส่ไว้ในไฟล์ .travis.yml ทีมส่วนใหญ่ใช้มันสำหรับ compile-and-unit-test loops มีน้อยทีมที่ใช้มันเพื่อรันการทดสอบ HTTP จริงกับ API ที่กำลังทำงานอยู่ แม้ว่านั่นจะเป็นจุดที่ bug ที่มีค่าใช้จ่ายสูงซ่อนอยู่ เหตุผลคือความยุ่งยาก การเชื่อมต่อตัวรันการทดสอบ API เข้ากับ CI box, การส่งข้อมูลลับอย่างปลอดภัย, และการได้รับสัญญาณ pass/fail กลับมานั้นซับซ้อนมากจนผู้คนมักจะข้ามไป

คู่มือนี้จะอธิบายถึงการปิดช่องว่างนั้นด้วยตัวรันบรรทัดคำสั่งของ Apidog คุณออกแบบและดีบักการทดสอบ API ของคุณในแอปพลิเคชัน Apidog บนเดสก์ท็อป ซึ่งคุณสามารถเห็นคำขอและ assertions ได้ด้วยภาพ จากนั้นรันการทดสอบเดียวกันนั้นแบบ headless ภายใน Travis CI ด้วยคำสั่งเดียว ไม่ต้องเขียน logic การทดสอบใหม่เป็นโค้ด ไม่ต้องดูแล test harness แยกต่างหาก บทความนี้ครอบคลุมเส้นทางทั้งหมด: .travis.yml ขั้นต่ำ, การติดตั้งตัวรัน, การส่ง access token ของคุณอย่างปลอดภัย, การเลือกสิ่งที่จะรัน, การสร้างรายงาน, และการทำให้ build ล้มเหลวอย่างชัดเจนเมื่อ endpoint มีปัญหา ดาวน์โหลด Apidog หากคุณต้องการทำตาม

ทำไมต้องรันการทดสอบ API ใน CI เลย

Unit test ยืนยันว่าฟังก์ชันส่งคืนค่าที่ถูกต้อง การทดสอบ API ยืนยันว่าวงจรการร้องขอ-การตอบสนองทั้งหมดทำงานได้: route มีอยู่จริง, มีการบังคับใช้การตรวจสอบสิทธิ์, รหัสสถานะถูกต้อง, JSON schema ตรงกัน, และค่าภายใน body นั้นสมเหตุสมผล นี่คือโหมดความล้มเหลวที่แตกต่างกัน และแบบที่สองคือสิ่งที่ผู้ใช้ของคุณเจอจริงๆ

การรันแบบ local นั้นดีจนกว่าจะไม่ดี การรันแบบ local ขึ้นอยู่กับคุณที่ต้องจำไว้ว่าต้องรัน, เครื่องของคุณตรงกับการตั้งค่าการผลิต, และคุณไม่ได้กำลังดื่มกาแฟในขณะที่ regression เกิดขึ้น Continuous integration ขจัดข้ออ้างทั้งสามนี้ ทุกการ push จะเรียกใช้ชุดการทดสอบเดียวกันในสภาพแวดล้อมเดียวกัน และผลลัพธ์จะแนบไปกับ commit และ pull request เพื่อให้ทุกคนเห็น

มีผลตอบแทนที่ลึกซึ้งยิ่งขึ้นสำหรับทีม API โดยเฉพาะ เมื่อการทดสอบของคุณอยู่ถัดจากการออกแบบ API การเปลี่ยนแปลงที่ทำให้เกิดความเสียหายจะแสดงขึ้นเป็นการยืนยันที่ล้มเหลวทันทีที่ถูก push ไม่ใช่เป็นการแจ้งปัญหา support ticket หากคุณต้องการพื้นฐานแนวคิดว่าสิ่งนี้เข้ากันได้กับ delivery pipeline ได้อย่างไร บทความ CI/CD คืออะไร เป็นคู่มือที่อ่านควบคู่กันไปได้ดี; บทความนี้มุ่งเน้นไปที่การสร้าง Travis CI แบบปฏิบัติจริง

สิ่งที่คุณต้องมีก่อนเริ่มต้น

สามสิ่ง และคุณน่าจะมีสองสิ่งในนั้นอยู่แล้ว

• Git repository ที่เชื่อมต่อกับ Travis CI ระดับฟรีบน travis-ci.com ใช้ได้กับ public และ private repos ภายใต้ขีดจำกัดการใช้งาน

• โปรเจกต์ Apidog ที่มีอย่างน้อยหนึ่ง test scenario ที่คุณสร้างและรันสำเร็จแล้วในแอปพลิเคชันเดสก์ท็อป Test scenario ใน Apidog คือชุดคำขอ API ที่จัดเรียงตามลำดับพร้อมกับ assertions; ลองนึกภาพว่าเป็น end-to-end flow เดียวกัน เช่น "เข้าสู่ระบบ, สร้างคำสั่งซื้อ, ดึงคำสั่งซื้อ, ลบมัน"
• Node.js. Apidog CLI รันบน Node และต้องใช้เวอร์ชัน 16 หรือใหม่กว่า Travis มี Node ให้มาพร้อมใช้งานในสภาพแวดล้อมภาษา node_js ดังนั้นส่วนใหญ่นี่คือการประกาศเพียงบรรทัดเดียว

หากคุณยังไม่ได้สร้าง test scenario ให้ทำในแอปพลิเคชันก่อน จุดประสงค์ทั้งหมดของ workflow นี้คือการดีบักด้วยภาพเพียงครั้งเดียว จากนั้นทำให้เป็นอัตโนมัติตลอดไป การพยายามเขียนการทดสอบแบบไม่เห็นภาพภายใน CI log เป็นเส้นทางที่ช้า สำหรับพื้นฐานของการเขียนการตรวจสอบที่ดี API assertions: คู่มือภาคปฏิบัติ ครอบคลุมวิธีการตรวจสอบรหัสสถานะ, response bodies และ JSON schema ก่อนที่คุณจะ push

ขั้นตอนที่ 1: รับ access token และ scenario ID ของคุณ

Apidog CLI รันการทดสอบที่เก็บไว้ในคลาวด์ของคุณแบบ headless ดังนั้นจึงต้องมีข้อมูลประจำตัวสองส่วน:

1. Access token ที่พิสูจน์ว่าตัวรันได้รับอนุญาตให้อ่านโปรเจกต์ของคุณ สร้างได้จากส่วนการตั้งค่าบัญชี Apidog ของคุณภายใต้ access tokens ปฏิบัติต่อมันเหมือนรหัสผ่าน; มันให้สิทธิ์การเข้าถึง API ไปยังข้อมูลโปรเจกต์ของคุณ
2. Test scenario ID เปิด scenario ในแอปพลิเคชันเดสก์ท็อปและคัดลอก ID ของมัน หรือใช้ตัวเลือก "Run in CI/CD" ซึ่งจะสร้างคำสั่งที่พร้อมใช้งานโดยมี ID กรอกไว้แล้ว

วิธีที่ง่ายที่สุดในการได้คำสั่งแรกที่ถูกต้องคือการให้ Apidog เขียนให้คุณ ภายใน test scenario ตัวเลือกการรัน CI/CD จะสร้างสิ่งนี้ขึ้นมา:

apidog run --access-token <your-access-token> -t 5564321 -e 4417023 -r cli

นั่นคือรูปร่างทั้งหมด: ตรวจสอบสิทธิ์, ชี้ไปยัง scenario (-t), ชี้ไปยัง environment (-e), และเลือกรีพอร์เตอร์ (-r) คัดลอกสิ่งนี้, ยืนยันว่ามันรันบนแล็ปท็อปของคุณก่อน, จากนั้นค่อยย้ายมันไปที่ Travis การตรวจสอบในเครื่องจะช่วยให้คุณประหยัดเวลาในการแก้ปัญหา typo ใน token ได้หลายครั้ง

ขั้นตอนที่ 2: จัดเก็บ token เป็นตัวแปร Travis ที่เข้ารหัส

ห้ามวาง access token ของคุณลงใน .travis.yml ไฟล์นั้นถูก commit เข้าสู่ Git และ token ที่รั่วไหลจะทำให้ใครก็ตามสามารถเข้าถึงข้อมูลโปรเจกต์ API ของคุณได้ Travis มีสองทางเลือกที่ปลอดภัย

วิธีที่สะอาดคือการตั้งค่า repository environment variables ใน Travis web UI ไปที่การตั้งค่า repository ของคุณบน Travis, ค้นหา environment variables, และเพิ่ม:

• APIDOG_ACCESS_TOKEN พร้อมค่า token ของคุณ
• APIDOG_ENV_ID พร้อม ID ของ environment ที่คุณต้องการทดสอบ

ปล่อยให้ช่อง "display value in build log" ปิดอยู่ เพื่อไม่ให้ token ถูกพิมพ์ออกมา Travis จะฉีดสิ่งเหล่านี้เข้าไปในทุก build เป็น environment variables จริง และ config ของคุณจะอ้างอิงถึงพวกมันด้วยชื่อ สิ่งนี้ช่วยให้ข้อมูลลับอยู่นอก repository อย่างสมบูรณ์ ซึ่งเป็นพฤติกรรมที่คุณต้องการ; หาก contributor fork repo, token ของคุณจะไม่ถูกรวมไปด้วย

หากคุณต้องการให้ทุกอย่างอยู่ในไฟล์ Travis ก็รองรับตัวแปรที่เข้ารหัสผ่าน CLI ของมัน:

travis encrypt APIDOG_ACCESS_TOKEN="your-token-here" --add env.global

สิ่งนี้จะเขียนข้อมูลที่เข้ารหัสลงใน .travis.yml ซึ่งมีเพียง build ของ repository ของคุณเท่านั้นที่สามารถถอดรหัสได้ วิธีการใดก็ได้ใช้ได้ผล เส้นทาง UI นั้นง่ายกว่าสำหรับทีมส่วนใหญ่และง่ายต่อการเปลี่ยนแปลงเมื่อ token หมดอายุ

ขั้นตอนที่ 3: เขียน .travis.yml

นี่คือการกำหนดค่าขั้นต่ำที่สมบูรณ์ซึ่งติดตั้ง Apidog CLI และรันหนึ่ง scenario ในทุกการ push และ pull request:

language: node_js
node_js:
  - "18"

cache:
  npm: true

install:
  - npm install -g apidog-cli

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli

สามส่วนนี้ทำงาน language: node_js พร้อมเวอร์ชันให้คุณได้ Node runtime ที่ใหม่พอสำหรับ CLI ขั้นตอน install จะติดตั้ง apidog-cli แบบ global เพื่อให้คำสั่ง apidog อยู่ใน path ขั้นตอน script จะรันการทดสอบของคุณ รีพอร์เตอร์ -r cli จะพิมพ์สรุปผล pass/fail ที่อ่านง่ายลงใน Travis log โดยตรง ซึ่งเป็นสิ่งที่คุณจะดูเมื่อมีบางอย่างพัง

สังเกตว่า scenario ID ถูก hardcode แต่ข้อมูลลับมาจาก environment variables นั่นคือการแบ่งที่ถูกต้อง: ID ไม่ละเอียดอ่อน แต่ token ละเอียดอ่อน Commit ไฟล์นี้, push, และ Travis จะรันการทดสอบ API ของคุณโดยอัตโนมัติ build สีเขียวแรกคือช่วงเวลาที่ API ของคุณได้รับตาข่ายนิรภัย

หากคุณดูแลหลายบริการและต้องการโมเดลทางความคิดร่วมกันในทุกตัวรัน บทความ การทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD จะแสดงรูปแบบเดียวกันที่ใช้กับแพลตฟอร์มอื่นๆ และ เวอร์ชัน GitHub Actions แทบจะเหมือนกันในแง่ของแนวคิด หากคุณเคยย้าย

ขั้นตอนที่ 4: ทำให้ build ล้มเหลวเมื่อการทดสอบล้มเหลว

นี่คือส่วนที่ทีมมักจะลืม และมันจะบั่นทอนการทำงานทั้งหมดอย่างเงียบๆ งาน CI จะมีประโยชน์ก็ต่อเมื่อการทดสอบที่ล้มเหลวทำให้ build กลายเป็นสีแดง หากตัวรันออกด้วยรหัสศูนย์ไม่ว่าจะเกิดอะไรขึ้น คุณก็กำลังสร้างเครื่องพิมพ์ log ที่มีค่าใช้จ่ายสูงมาก

ข่าวดี: Apidog CLI ทำสิ่งที่ถูกต้องอยู่แล้ว เมื่อ assertion ล้มเหลว กระบวนการ apidog run จะออกจากระบบด้วยรหัสสถานะที่ไม่ใช่ศูนย์ และ Travis ถือว่าการออกจากระบบที่ไม่ใช่ศูนย์ใดๆ ในช่วง script เป็นความล้มเหลวของ build ดังนั้นการกำหนดค่าขั้นต่ำข้างต้นจึงล้มเหลวอย่างถูกต้องตั้งแต่ต้น คุณไม่จำเป็นต้องเพิ่มส่วนเชื่อมต่อพิเศษ

สิ่งที่คุณสามารถปรับแต่งได้คือพฤติกรรมการรันในช่วงกลาง scenario เมื่อคำขอเดียวเกิดข้อผิดพลาด แฟล็ก --on-error ควบคุมสิ่งนี้:

• --on-error end จะหยุด scenario ที่ความล้มเหลวครั้งแรก ได้รับการตอบรับที่เร็วที่สุด แต่ผลลัพธ์น้อยลง
• --on-error continue จะรันขั้นตอนที่เหลือเพื่อให้คุณเห็นความล้มเหลวทั้งหมดในการรันครั้งเดียว
• --on-error ignore จะดำเนินการต่อไปและไม่ปล่อยให้ข้อผิดพลาดหยุดการรัน

สำหรับ CI, continue มักจะเป็นจุดที่เหมาะสม: คุณต้องการภาพรวมทั้งหมดว่าอะไรเสียโดยที่งานไม่หยุดทำงานหลังจากการยืนยันสีแดงครั้งแรก แต่ยังคงจบด้วยการออกที่ไม่ใช่ศูนย์เพื่อให้ build ล้มเหลว บรรทัด script ที่เหมาะสมจะมีลักษณะดังนี้:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli --on-error continue

หลีกเลี่ยงความเย้ายวนที่จะเพิ่ม || true ไปยังคำสั่งเพื่อ "ทำให้ build ผ่าน" นั่นเป็นการกลืนกินรหัสสถานะและนำจุดบอดที่คุณต้องการกำจัดกลับมาอีกครั้ง

ขั้นตอนที่ 5: สร้างและเก็บรายงาน HTML

รีพอร์เตอร์ cli นั้นใช้ได้ดีสำหรับการตรวจสอบอย่างรวดเร็ว แต่เมื่อ build ล้มเหลว คุณมักจะต้องการ artifact ที่สมบูรณ์ยิ่งขึ้น: คำขอใด, assertion ใด, response body จริงๆ เป็นอย่างไร CLI สร้างรายงาน HTML ด้วยรีพอร์เตอร์ html และคุณสามารถซ้อนรีพอร์เตอร์ในการรันครั้งเดียวได้

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli,html --out-dir ./apidog-reports

-r cli,html จะพิมพ์ไปยัง log และเขียนไฟล์ HTML แบบ stand-alone --out-dir กำหนดตำแหน่งที่รายงานจะถูกบันทึก โดยค่าเริ่มต้นคือ ./apidog-reports หากต้องการให้รายงานนั้นอยู่รอดหลังจาก build สิ้นสุด ให้ deploy ไปยังตำแหน่งที่ Travis สามารถเผยแพร่ได้ เช่น S3 bucket หรือ GitHub Pages ในบล็อก deploy รูปแบบทั่วไป:

deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN
  local_dir: apidog-reports
  on:
    branch: main

หากคุณไม่ต้องการจัดการพื้นที่จัดเก็บ artifact เลย CLI สามารถ push รายงานไปยัง Apidog cloud ด้วย --upload-report ซึ่งทีมของคุณสามารถเปิดได้จากลิงก์โดยไม่ต้องมีการโฮสต์เพิ่มเติม นี่คือตัวเลือกที่ดูแลรักษาน้อยที่สุดสำหรับทีมที่กระจายตัว

ขั้นตอนที่ 6: เพิ่ม environments, data และ matrix runs

scenario เดียวกับ environment เดียวเป็นจุดเริ่มต้นที่ดี pipeline จริงๆ เติบโตไปในสามทิศทาง และแฟล็ก CLI ก็สอดคล้องกับแต่ละทิศทางอย่างชัดเจน

หลาย environment แฟล็ก -e เลือก base URL และตัวแปรของ environment ใดที่จะใช้ รัน scenario เดียวกันกับ staging ในทุกการ push และกับ production ใน cron build ทุกคืนโดยการสลับ environment ID งาน Travis cron ถูกกำหนดค่าต่อ repository ใน UI การตั้งค่า

การรันแบบขับเคลื่อนด้วยข้อมูล แฟล็ก -d (รูปแบบยาว --iteration-data) ป้อนไฟล์ CSV หรือ JSON เข้าไปใน scenario ของคุณเพื่อให้รันหนึ่งครั้งต่อแถว นี่คือวิธีที่คุณจะครอบคลุมกรณีขอบเขต: input ที่ถูกต้อง, ช่องที่ขาดหายไป, payloads ที่มีขนาดใหญ่เกินไป, อักขระพิเศษ, ทั้งหมดจากคำจำกัดความ scenario เดียว จับคู่กับ -n (--iteration-count) เมื่อคุณต้องการจำนวนการทำซ้ำที่กำหนดไว้แทนที่จะเป็นการทำซ้ำที่ขับเคลื่อนด้วยไฟล์

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -d ./test-data.csv -r cli

Scenarios แบบขนาน Travis build matrices ช่วยให้คุณรันหลาย scenarios พร้อมกันในงานแบบขนาน กำหนด environment-variable matrix ที่แต่ละรายการมี scenario ID ที่แตกต่างกัน และแต่ละ matrix job จะรันหนึ่งตัว build จะเป็นสีเขียวก็ต่อเมื่อทั้งหมดผ่านเท่านั้น

env:
  - SCENARIO_ID=5564321   # checkout flow
  - SCENARIO_ID=5564322   # auth flow
  - SCENARIO_ID=5564323   # search flow

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t $SCENARIO_ID -e $APIDOG_ENV_ID -r cli

เมื่อ suites มีขนาดใหญ่ขึ้น การจัดระเบียบ scenarios เป็น test suites สำหรับการทดสอบ API อัตโนมัติ จะช่วยให้ matrix จัดการได้ง่ายขึ้น แทนที่จะกลายเป็นกำแพงของ ID

ทำไมวิธีนี้ถึงดีกว่าการเขียนโค้ดการทดสอบด้วยมือใน CI script ของคุณ

คุณสามารถเขียนการทดสอบ API โดยตรงใน Travis script ด้วย curl และ jq หรือเป็นการรัน Newman ของ collection ที่ export ออกมา ทั้งสองวิธีใช้ได้ผลและทั้งสองวิธีก็มีปัญหาเมื่อเวลาผ่านไป

แนวทาง curl-บวก-shell เปลี่ยน assertion ทุกตัวให้กลายเป็นการเปรียบเทียบสตริงที่ไม่เสถียร การตรวจสอบฟิลด์ JSON ที่ซ้อนกันกลายเป็นคาถา jq; การตรวจสอบ schema แทบเป็นไปไม่ได้; และทันทีที่ API ของคุณเพิ่มฟิลด์ ครึ่งหนึ่งของ greps ของคุณก็ต้องเขียนใหม่ คุณจะจบลงด้วยการดูแลรักษาความรู้ API ชุดที่สองที่แย่กว่าเดิมใน Bash

แนวทาง collection-runner นั้นดีกว่า แต่เชื่อมโยง CI ของคุณกับพิธีกรรมการ export-and-sync: แก้ไขการทดสอบในเครื่องมือหนึ่ง, export, commit JSON, หวังว่ามันจะไม่คลาดเคลื่อนจากความเป็นจริง การคลาดเคลื่อนนั้นเป็นเรื่องจริง และเป็นสาเหตุของข้อร้องเรียน "การทดสอบผ่านแต่ API เสียหาย" เราได้เขียนเกี่ยวกับโหมดความล้มเหลวที่แน่นอนนี้ในบทความ ทำไม Postman collections ของคุณจึงไม่ใช่แหล่งที่มาของความจริง และหากคุณกำลังรัน collections ใน CI วันนี้ บทความ วิธีการรัน Postman collections ใน CI โดยไม่ต้องใช้ Newman ครอบคลุมเส้นทางการย้าย

โมเดล Apidog จะปิดวงจรนี้ การทดสอบของคุณ, การออกแบบ API ของคุณ, environment ของคุณ, และ mock server ของคุณอยู่รวมกันในที่เดียว CLI จะรันเวอร์ชันปัจจุบันของการทดสอบเหล่านั้น ไม่มีอะไรต้อง export และไม่มีอะไรต้องคลาดเคลื่อน คุณดีบัก assertion ที่ผิดพลาดด้วยภาพในแอป บันทึก และการรัน CI ครั้งถัดไปก็จะรับการเปลี่ยนแปลงไป แหล่งความจริงเดียวนี้คือเหตุผลทั้งหมดในการใช้ตัวรันที่สร้างขึ้นมาโดยเฉพาะแทนที่จะเป็นกอง script shell หากคุณกำลังประเมินเทียบกับการตั้งค่าปัจจุบันของคุณ การรวบรวม ทางเลือก Postman ที่ดีที่สุดสำหรับการทดสอบ API จะนำเสนอตัวเลือกต่างๆ เคียงข้างกัน

หมายเหตุเกี่ยวกับ Travis CI โดยเฉพาะ

Travis เป็น CI แบบโอเพนซอร์สเริ่มต้นมาหลายปี และมี repository เก่าๆ จำนวนมากที่ยังคงใช้งานอยู่ หากคุณกำลังเริ่มต้นใหม่ในปี 2026 ก็ควรทราบว่าภูมิทัศน์ได้เปลี่ยนไปแล้ว; GitHub Actions, GitLab CI และ CircleCI เป็นผู้รองรับโปรเจกต์ใหม่ส่วนใหญ่ในปัจจุบัน และบทความ การเปรียบเทียบเครื่องมือ CI/CD ที่ดีที่สุด ของเราจะอธิบายว่าแต่ละตัวเหมาะสมกับอะไร ข่าวดีคือ Apidog CLI ถูกออกแบบมาให้ไม่ขึ้นกับแพลตฟอร์ม คำสั่ง apidog run เดียวกันกับที่ใช้ใน .travis.yml ของคุณ ก็ใช้ได้ใน GitHub Actions step, .gitlab-ci.yml ของ GitLab หรือ Jenkins stage หากคุณย้ายออกจาก Travis การทดสอบ API ของคุณก็จะย้ายตามไปโดยไม่มีการเปลี่ยนแปลง; มีเพียงคีย์ YAML รอบๆ เท่านั้นที่แตกต่างกัน ความสามารถในการพกพานี้เป็นประโยชน์ที่เงียบแต่เป็นจริงของการเก็บ logic การทดสอบไว้นอกไวยากรณ์เฉพาะของ CI

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

ฉันจำเป็นต้องติดตั้งแอปพลิเคชันเดสก์ท็อป Apidog บน CI box หรือไม่? ไม่ แอปพลิเคชันเดสก์ท็อปมีไว้สำหรับออกแบบและดีบักการทดสอบ Travis ต้องการเพียงแพ็กเกจ npm apidog-cli และ Node 16+ runtime ซึ่งสภาพแวดล้อมภาษา node_js มีให้พร้อมแล้ว CLI จะดึงและรัน scenarios ที่เก็บไว้ในคลาวด์ของคุณแบบ headless

ฉันจะหา access token และ scenario ID ได้จากที่ไหน? สร้าง access token ในการตั้งค่าบัญชี Apidog ของคุณภายใต้ access tokens Scenario ID สามารถเห็นได้ในแอปพลิเคชันเดสก์ท็อปในแต่ละ test scenario; ตัวเลือก "Run in CI/CD" ในตัวยังสร้างคำสั่งที่สมบูรณ์พร้อม ID ที่กรอกไว้ล่วงหน้า ซึ่งเป็นวิธีที่เร็วที่สุดในการเริ่มต้นใช้งาน

ฉันจะเก็บ token ไว้นอก repository ได้อย่างไร? ตั้งค่าเป็น repository environment variable ใน Travis web UI โดยปิดการแสดงผล build-log จากนั้นอ้างอิงถึงมันเป็น $APIDOG_ACCESS_TOKEN ใน config ของคุณ หรืออีกทางหนึ่ง ใช้ travis encrypt เพื่อเก็บค่าที่เข้ารหัสไว้ใน .travis.yml ห้าม commit raw token โดยเด็ดขาด

Build จะล้มเหลวจริงๆ หากการทดสอบล้มเหลวหรือไม่? ใช่ คำสั่ง apidog run จะออกจากระบบด้วยค่าที่ไม่ใช่ศูนย์เมื่อ assertion ล้มเหลว และ Travis จะถือว่าการออกจากระบบด้วยค่าที่ไม่ใช่ศูนย์ใดๆ ในช่วง script เป็น build ที่ล้มเหลว เพียงแค่ไม่ไปกดรหัสออกด้วย || true ใช้ --on-error continue หากคุณต้องการให้รายงานความล้มเหลวทั้งหมดในการรันครั้งเดียวในขณะที่ build ยังคงล้มเหลว

ฉันสามารถรันการทดสอบกับหลาย environment หรือด้วยชุดข้อมูลหลายชุดได้หรือไม่? ใช่ ใช้ -e เพื่อสลับ environment (staging เมื่อ push, production ใน cron กลางคืน), -d เพื่อป้อนไฟล์ข้อมูล CSV หรือ JSON สำหรับการทำซ้ำแบบขับเคลื่อนด้วยข้อมูล และ Travis build matrix เพื่อรันหลาย scenarios ในงานแบบขนาน

ฉันสามารถใช้สิ่งนี้ได้หรือไม่หากฉันไม่ได้ใช้ Travis CI? ใช่ คำสั่ง CLI เหมือนกันในทุกแพลตฟอร์ม สลับ YAML รอบข้างสำหรับ GitHub Actions, GitLab CI หรือ Jenkins และบรรทัด apidog run จะยังคงเหมือนเดิม

สรุป

การนำการทดสอบ API เข้าสู่ Travis CI มีสี่ขั้นตอนหลัก: จัดเก็บ access token ของคุณเป็นตัวแปรที่เข้ารหัส, ติดตั้ง apidog-cli ในขั้นตอน install, รัน scenario ของคุณด้วย apidog run ในขั้นตอน script, และปล่อยให้รหัสออกที่ไม่ใช่ศูนย์ทำให้ build ล้มเหลว จากนั้นคุณสามารถเพิ่มรายงาน HTML, หลาย environment, การทำซ้ำแบบขับเคลื่อนด้วยข้อมูล และ matrix แบบขนานเมื่อ suite ของคุณเติบโตขึ้น

เหตุผลที่ต้องทำด้วยตัวรันเฉพาะแทนที่จะเป็นกองคำสั่ง curl คือแหล่งความจริงเดียว คุณออกแบบและดีบักด้วยภาพ จากนั้นรันเวอร์ชันปัจจุบันของการทดสอบเหล่านั้นในทุก commit โดยไม่มีขั้นตอนการ export ที่จะทำให้เกิดการคลาดเคลื่อน Regression ของ /checkout ของคุณจะถูกจับได้ใน pull request ไม่ใช่ในการผลิต

สร้าง test scenario แรกของคุณ จากนั้นดาวน์โหลด Apidog และเชื่อมต่อเข้ากับการ push ครั้งถัดไปของคุณ เมื่อ build แรกเป็นสีเขียว ทุก commit หลังจากนั้นจะมาพร้อมกับตาข่ายนิรภัย