วิธีการใช้งาน Apidog CLI เพื่อทดสอบ API บน GitHub Actions (เวิร์กโฟลว์ฉบับสมบูรณ์)

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

ช่องว่างนั้นคือสิ่งที่ Continuous Integration เข้ามาช่วยแก้ คุณย้ายการทดสอบออกจากเทอร์มินัลในเครื่องของคุณไปยังไปป์ไลน์ที่จะเรียกใช้การทดสอบเหล่านั้นโดยอัตโนมัติ ทุกครั้งที่มีการพุช สำหรับทุกการเปลี่ยนแปลง โดยเฉพาะอย่างยิ่งสำหรับการทดสอบ API วิธีที่สะอาดที่สุดคือการใช้ command-line runner ที่ดำเนินการตามสถานการณ์ที่คุณสร้างไว้แล้ว ส่งคืนรหัสออกสำหรับผลลัพธ์ผ่าน/ไม่ผ่าน และให้ CI ตัดสินใจว่าการสร้างจะสำเร็จ (สีเขียว) หรือล้มเหลว (สีแดง)

button

TL;DR

Apidog CLI เป็นแพ็กเกจ npm ชื่อ apidog-cli ติดตั้งในขั้นตอนเวิร์กโฟลว์ด้วย npm install -g apidog-cli จากนั้นรันสถานการณ์ด้วย apidog run
มันจะดำเนินการสถานการณ์ทดสอบที่คุณออกแบบในแอป Apidog ด้วย ID คุณไม่ต้องแปลงการทดสอบเป็นโค้ด; CLI จะรันสถานการณ์เดียวกันโดยใช้ Access Token สำหรับการยืนยันตัวตน
งาน GitHub Actions ที่เรียบง่ายที่สุดมีสี่ขั้นตอน: checkout, ตั้งค่า Node, ติดตั้ง CLI, รัน apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t <scenarioId> -e <environmentId> -r junit,cli
CLI จะคืนค่าที่ไม่ใช่ศูนย์เมื่อการตรวจสอบใดๆ ล้มเหลว GitHub จะอ่านรหัสออกนั้น ทำให้การตรวจสอบล้มเหลว และบล็อกการรวมโค้ด นั่นคือคุณภาพการควบคุมทั้งหมด; คุณไม่ต้องตั้งค่าอะไรเพิ่มเติม
เก็บ Access Token เป็น GitHub Actions secret และส่งผ่านทาง env: อย่าคอมมิตลงในโค้ด
ใช้ -r junit เพื่อส่งผลลัพธ์ไปยังแดชบอร์ด, -r html สำหรับ artifact ที่สามารถเรียกดูได้ และ if: always() ในขั้นตอนการอัปโหลดเพื่อให้คุณยังคงได้รับรายงานเมื่อการทดสอบล้มเหลว

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

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

CI แก้ปัญหาความน่าเชื่อถือโดยทำให้การรันเป็นไปโดยอัตโนมัติและเป็นมาตรฐาน Pull Request ทุกครั้งจะเรียกใช้งานเดียวกัน บน runner ที่สะอาดเดียวกัน กับสภาพแวดล้อมเดียวกัน เมื่อเอนด์พอยต์เริ่มคืนค่า 500 หรือ response schema มีการเปลี่ยนแปลง การตรวจสอบจะล้มเหลวบน PR ที่เป็นสาเหตุ พร้อมระบุชื่อบุคคลที่พุชการเปลี่ยนแปลงนั้น ข้อเสนอแนะจะมาถึงในไม่กี่นาที ในขณะที่การเปลี่ยนแปลงยังคงสดใหม่ แทนที่จะเป็นหลายวันต่อมาใน Production

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

Apidog CLI ทำอะไรได้บ้าง

นี่คือส่วนที่ช่วยประหยัดเวลาของคุณได้มากที่สุด: คุณไม่จำเป็นต้องเขียนโค้ดทดสอบสำหรับ CLI

คุณสร้างสถานการณ์การทดสอบของคุณด้วยภาพในแอป Apidog โดยมีคำขอ, การตรวจสอบ, ตัวแปรสภาพแวดล้อม และข้อมูลที่คุณต้องการ CLI เป็นตัวรัน เมื่อได้รับ ID สถานการณ์และ Access Token มันจะดึงสถานการณ์นั้นจากโปรเจกต์ Apidog ของคุณและดำเนินการทีละคำขอ ประเมินการตรวจสอบแต่ละรายการเหมือนที่แอปจะทำ ผลลัพธ์ที่ได้คือรายงานและรหัสออก

การออกแบบนั้นสำคัญสำหรับ CI test runner ส่วนใหญ่จะขอให้คุณรักษารูปแบบโค้ดของการทดสอบแยกต่างหาก; สิ่งที่คุณรันในไปป์ไลน์จะแตกต่างจากสิ่งที่คุณออกแบบ ด้วย Apidog ไปป์ไลน์จะรันสถานการณ์เดียวกันที่ทีมของคุณดูแลอยู่แล้วในแอป อัปเดตการตรวจสอบใน visual editor และการรัน CI ครั้งถัดไปก็จะรับการเปลี่ยนแปลงนั้นไป ไม่มีสำเนาที่สองที่ต้องดูแลให้ซิงค์กัน

ไบนารีคือ apidog ซึ่งเผยแพร่เป็นแพ็กเกจ npm ชื่อ apidog-cli ทุกคำสั่งเริ่มต้นด้วย apidog run หากคุณต้องการดู runner ที่รวมอยู่ในเวิร์กโฟลว์อัตโนมัติที่สมบูรณ์ยิ่งขึ้น คำแนะนำใน การผสานรวม Apidog CLI กับ Claude Skills สำหรับการทำงานอัตโนมัติของการทดสอบ API ครอบคลุมมุมมองนั้น; บทความนี้เน้นที่แฟล็กที่คุณต้องการสำหรับไปป์ไลน์ GitHub Actions

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

คุณต้องการข้อมูลสามอย่างก่อนที่เวิร์กโฟลว์จะทำงาน สองอย่างเป็น ID จากโปรเจกต์ Apidog ของคุณ; หนึ่งอย่างเป็นโทเค็น

สถานการณ์การทดสอบ สร้างขึ้นในแอป Apidog หากคุณยังไม่ได้ทำ นี่คือสิ่งที่ CLI จะรัน สถานการณ์การเข้าสู่ระบบและดึงข้อมูลโปรไฟล์เพียงหนึ่งเดียวก็เพียงพอที่จะเริ่มต้น คุณสามารถขยายขนาดได้ในภายหลัง
ID สถานการณ์และ ID สภาพแวดล้อม ID สถานการณ์บอก CLI ว่าจะรันอะไร; ID สภาพแวดล้อมบอกว่าที่ไหน (dev, staging, production) ทั้งสองอย่างสามารถมองเห็นได้ในแอป
Access Token สิ่งนี้ใช้ยืนยันตัวตน CLI กับบัญชี Apidog ของคุณ เพื่อให้สามารถดึงข้อมูลและรันสถานการณ์ได้

วิธีที่สะอาดที่สุดในการรับทั้งหมดนี้พร้อมกันคือแท็บ CI/CD ของสถานการณ์ เปิดสถานการณ์การทดสอบที่คุณต้องการทำให้เป็นอัตโนมัติ สลับไปที่แท็บ CI/CD และเลือกตัวเลือก Command-line คลิกเพื่อเพิ่ม Access Token และสร้างขึ้นมา Apidog จะประกอบคำสั่ง apidog run ที่สมบูรณ์ให้คุณ โดยมี Access Token, ID สถานการณ์ (-t) และ ID สภาพแวดล้อม (-e) กรอกไว้เรียบร้อยแล้ว คัดลอกคำสั่งนั้น; มันเป็นพื้นฐานสำหรับขั้นตอน CI ของคุณ

กฎหนึ่งที่ควรกล่าวถึงล่วงหน้า: ปฏิบัติต่อ Access Token เหมือนรหัสผ่าน อย่าเอาไปวางลงในไฟล์เวิร์กโฟลว์ที่คอมมิตไปแล้ว เก็บเป็น GitHub Actions secret และอ้างอิงเป็นตัวแปรสภาพแวดล้อม ตัวอย่างทั้งหมดด้านล่างใช้ $APIDOG_ACCESS_TOKEN ด้วยเหตุผลนี้

ขั้นตอนที่ 1: เก็บ Access Token เป็น GitHub Secret

เปิด repository ของคุณบน GitHub ไปที่ Settings จากนั้น Secrets and variables จากนั้น Actions และคลิก New repository secret

ชื่อ: APIDOG_ACCESS_TOKEN
Secret: วางโทเค็นที่ Apidog สร้างให้คุณ

บันทึกไว้ โทเค็นได้รับการเข้ารหัสเมื่อไม่ได้ใช้งานและเปิดเผยเฉพาะการรันเวิร์กโฟลว์เท่านั้น ไม่มีการพิมพ์ในบันทึก ในเวิร์กโฟลว์คุณจะอ้างอิงถึงมันเป็น ${{ secrets.APIDOG_ACCESS_TOKEN }} และส่งให้ CLI ผ่านบล็อก env: ID สถานการณ์และ ID สภาพแวดล้อมไม่ใช่ความลับ; เป็น ID ที่ไม่มีอันตราย ดังนั้นคุณสามารถเขียนลงในไฟล์เวิร์กโฟลว์ได้โดยตรง เฉพาะโทเค็นเท่านั้นที่ต้องการการป้องกัน

หากทีมของคุณทำงานข้ามหลาย repository ที่ทั้งหมดใช้โปรเจกต์ Apidog เดียวกัน ให้กำหนด secret เพียงครั้งเดียวที่ระดับองค์กรแทน และให้สิทธิ์การเข้าถึงแก่ repo ที่เกี่ยวข้อง ชื่อเดียวกัน มีที่เดียวในการหมุนเวียน

ขั้นตอนที่ 2: เวิร์กโฟลว์ที่เรียบง่ายที่สุด

สร้างไฟล์ .github/workflows/api-tests.yml ใน repository ของคุณ นี่คือเวิร์กโฟลว์ที่เล็กที่สุดที่สามารถทำประโยชน์ได้: มันจะรันสถานการณ์ของคุณทุกครั้งที่มี Pull Request ที่มุ่งเป้าไปที่ main

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 \
            -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

แทนที่ 605067 ด้วย ID สถานการณ์ของคุณ และ 1629989 ด้วย ID สภาพแวดล้อมของคุณ คอมมิตไฟล์นี้ เปิด Pull Request และดูที่แท็บ Checks งานจะเริ่มต้น Ubuntu runner ติดตั้ง Node 20 ติดตั้ง CLI และรันสถานการณ์ของคุณ หากการตรวจสอบทั้งหมดผ่าน การตรวจสอบจะแสดงสีเขียว หากมีรายการใดล้มเหลว apidog run จะคืนค่าที่ไม่ใช่ศูนย์ GitHub จะทำให้การตรวจสอบล้มเหลว และ PR จะแสดงเครื่องหมายกากบาทสีแดง

เครื่องหมายกากบาทสีแดงนั้นคือประเด็นทั้งหมด ไม่มีใครต้องอ่านบันทึกเพื่อทราบว่ามีบางอย่างเสียหาย; การตรวจสอบที่ล้มเหลวจะแสดงอยู่บน Pull Request เลย

หมายเหตุเกี่ยวกับขั้นตอนการติดตั้ง: การรัน npm install -g apidog-cli แบบ Global นั้นง่ายและใช้งานได้ หากคุณไม่ต้องการเปลี่ยนแปลงแพ็กเกจ Global ของ runner คุณสามารถข้ามขั้นตอนการติดตั้งและเรียกใช้ CLI ผ่าน npx แทนได้:

      - name: Run API test scenario
        run: npx apidog-cli run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -e 1629989 -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

ทั้งสองวิธีรันสถานการณ์เดียวกัน npx นั้นเรียบร้อยกว่าบน ephemeral runner; การติดตั้งแบบ Global จะเร็วกว่าเล็กน้อยเมื่อคุณแคช node_modules ระหว่างการรัน เลือกวิธีที่เหมาะสมกับสไตล์ของคุณ

ขั้นตอนที่ 3: เผยแพร่รายงานที่คุณสามารถอ่านได้จริง

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

แฟล็ก -r (หรือ --reporters) ควบคุมรูปแบบรายงาน โดยรับค่า cli, html, json และ junit คั่นด้วยจุลภาค สำหรับ CI มีสองรูปแบบที่สำคัญ:

junit ส่งออก XML ในรูปแบบ JUnit มาตรฐาน แดชบอร์ด CI และเครื่องมือรายงานผลการทดสอบเกือบทั้งหมดรู้วิธีแยกวิเคราะห์เป็นโครงสร้างผ่าน/ไม่ผ่าน
html สร้างรายงานแบบ self-contained ที่คุณสามารถบันทึกเป็น build artifact และเปิดในเบราว์เซอร์ได้ พร้อมคำขอและการตอบกลับที่สมบูรณ์สำหรับแต่ละขั้นตอน

เก็บ cli ไว้ด้วยหากคุณต้องการเอาต์พุตที่อ่านได้ในบันทึกการสร้างเอง นี่คือขั้นตอนการรันที่ได้รับการปรับปรุงเพื่อสร้างทั้งสองรูปแบบรายงานและเขียนลงในไดเรกทอรี พร้อมด้วยขั้นตอนการอัปโหลดเพื่อให้รายงานคงอยู่หลังจากการรัน:

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

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

รายละเอียดสองอย่างที่ทำให้สิ่งนี้ทำงานได้ตามที่คุณต้องการ แฟล็ก --out-dir บอก CLI ว่าจะเขียนรายงานที่ไหน; ในที่นี้คือ ./apidog-reports ซึ่งขั้นตอนการอัปโหลดจะดึงไป และ if: always() ในขั้นตอนการอัปโหลดเป็นสิ่งสำคัญ: โดยค่าเริ่มต้น GitHub จะข้ามขั้นตอนถัดไปเมื่อขั้นตอนหนึ่งล้มเหลว แต่คุณต้องการรายงานมากที่สุดเมื่อการทดสอบล้มเหลว if: always() บังคับให้อัปโหลดทำงานไม่ว่าผลลัพธ์การทดสอบจะเป็นอย่างไร หลังจากงานเสร็จสิ้น รายงานจะปรากฏใต้ Artifacts บนหน้ารายงานสรุปการรัน พร้อมสำหรับการดาวน์โหลด

แฟล็ก -n 1 ตั้งค่าจำนวนการวนซ้ำเป็นหนึ่งครั้ง; เพิ่มค่านี้หากคุณต้องการให้สถานการณ์ถูกดำเนินการหลายครั้งติดต่อกัน

หากคุณต้องการให้ GitHub แสดงผลลัพธ์ JUnit แบบอินไลน์เป็น annotated check แทนที่จะเป็นไฟล์ที่ดาวน์โหลดได้ ให้เพิ่ม published-test-results action หลังจากขั้นตอนการรันและชี้ไปที่ ./apidog-reports/*.xml ซึ่งจะแปลง XML เป็นสรุปผลผ่าน/ไม่ผ่านที่แนบมากับการรัน ซึ่งมีประโยชน์สำหรับชุดการทดสอบขนาดใหญ่ที่ไม่สามารถเลื่อนดูบันทึกได้อย่างสะดวก

ขั้นตอนที่ 4: ทดสอบสภาพแวดล้อมที่เหมาะสมในเวลาที่เหมาะสม

Pull Request ควรทดสอบกับ staging การปรับใช้กับ production ควรได้รับการยืนยันกับ production สถานการณ์เดียวกันสามารถทำได้ทั้งสองอย่าง; คุณเพียงแค่เปลี่ยน ID สภาพแวดล้อมด้วย -e

การตั้งค่าที่นิยมและทนทานคือการใช้สองทริกเกอร์ในไฟล์เวิร์กโฟลว์เดียว Pull Request จะรันสถานการณ์กับสภาพแวดล้อม staging ของคุณเป็น merge gate การพุชไปยัง main (ซึ่งเป็นผลจากการรวมโค้ด) จะรันสถานการณ์เดียวกันกับ production เป็น post-deploy smoke test

name: API tests

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  pr-check:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Test staging
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r junit,cli \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: staging-report
          path: ./apidog-reports

  prod-smoke:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Smoke test production
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1730055 \
            -r cli \
            --on-error end
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

ID สภาพแวดล้อมสองชุด (1629989 สำหรับ staging, 1730055 สำหรับ production) เป็นความแตกต่างที่มีความหมายเพียงอย่างเดียว งาน PR จะสร้างและเก็บถาวรรายงาน JUnit เพื่อให้ผู้ตรวจสอบสามารถตรวจสอบความล้มเหลวได้; การทดสอบ smoke test สำหรับ production จะรันอย่างรวดเร็วและล้มเหลวอย่างรวดเร็วด้วย --on-error end ซึ่งจะหยุดที่การตรวจสอบที่เสียเป็นครั้งแรก เพื่อให้คุณทราบได้อย่างรวดเร็วว่าการปรับใช้มีปัญหา

--on-error เป็นสิ่งที่ควรทราบ มันควบคุมว่าจะเกิดอะไรขึ้นเมื่อขั้นตอนล้มเหลวระหว่างสถานการณ์ end จะหยุดการรันเมื่อเกิดความล้มเหลวครั้งแรก (ข้อเสนอแนะที่รวดเร็ว เหมาะสำหรับการทดสอบ smoke test) continue จะรันทุกขั้นตอนที่เหลือเพื่อให้คุณเห็นความล้มเหลวทั้งหมดในรายงานเดียว (ดีสำหรับการตรวจสอบ PR อย่างละเอียด) ignore จะข้ามขั้นตอนที่มีแนวโน้มที่จะไม่เสถียรโดยไม่ทำให้การรันหยุดชะงัก ไม่ว่าคุณจะเลือกแบบใด การรันก็ยังคงสิ้นสุดด้วยรหัสออกที่ไม่ใช่ศูนย์หากมีสิ่งใดล้มเหลว ดังนั้นเกตจึงยังคงทำงานอยู่ดี

ไปต่อ: การรันแบบ Matrix, โฟลเดอร์ และการทดสอบที่ขับเคลื่อนด้วยข้อมูล

เมื่อติดตั้งเกตพื้นฐานแล้ว แฟล็กบางตัวก็สามารถขยายฟังก์ชันการทำงานได้โดยไม่ต้องเพิ่ม YAML มากนัก

รันพื้นที่ฟีเจอร์ทั้งหมด ไม่ใช่แค่สถานการณ์เดียว สลับ -t <scenarioId> เป็น -f <folderId> เพื่อรันทุกสถานการณ์ภายในโฟลเดอร์ หรือ --test-suite <testSuiteId> เพื่อรันชุดการทดสอบที่จัดเตรียมไว้ ชุดการทดสอบเป็นเครื่องมือที่เหมาะสมเมื่อคุณต้องการชุดสถานการณ์ที่เฉพาะเจาะจงและเรียงลำดับให้รันพร้อมกันเป็นงานเชิงตรรกะเดียว; คู่มือเกี่ยวกับการ ขยายขนาดการทดสอบ API อัตโนมัติด้วย Test Suites ครอบคลุมว่าเมื่อใดควรใช้

ทดสอบหลายสภาพแวดล้อมพร้อมกัน Matrix จะรันงานเดียวกันข้าม ID สภาพแวดล้อมหลายรายการในคราวเดียว:

jobs:
  api-tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        env-id: [1629989, 1730055]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Run scenario against ${{ matrix.env-id }}
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e ${{ matrix.env-id }} \
            -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

GitHub จะสร้าง runner หนึ่งตัวต่อค่า Matrix หนึ่งค่า ดังนั้น staging และ production จะถูกทดสอบพร้อมกัน และแต่ละอันจะรายงานผลผ่าน/ไม่ผ่านของตัวเอง

ขับเคลื่อนการวนซ้ำจากไฟล์ข้อมูล แฟล็ก -d จะรันสถานการณ์เดียวผ่านแถวของไฟล์ CSV หรือ JSON โดยถือว่าแต่ละแถวเป็นการผ่านแยกต่างหาก: apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -d ./test-data.csv -r junit นี่คือวิธีที่คุณตรวจสอบเอนด์พอยต์เดียวกันกับอินพุตห้าสิบรายการโดยไม่ต้องสร้างห้าสิบสถานการณ์

รันกับ branch หากทีมของคุณใช้คุณสมบัติ branch ของ Apidog --branch <branchName> จะชี้การรันไปที่ branch ที่เฉพาะเจาะจงแทนที่จะเป็น main ซึ่งช่วยให้ PR ของ feature branch ทดสอบกับคำจำกัดความสถานการณ์ของ branch นั้นได้

การแก้ไขปัญหาความล้มเหลวทั่วไปของ CI

งานเป็นสีเขียวแต่การทดสอบควรจะล้มเหลว ตรวจสอบว่ารหัสออกของขั้นตอน apidog run ไปถึง GitHub จริงๆ หรือไม่ หากคุณห่อคำสั่งไว้ใน shell pipeline หรือต่อท้ายด้วย || true รหัสออกที่ไม่ใช่ศูนย์จะถูกกลืนหายไปและเกตจะหยุดทำงานโดยไม่มีสัญญาณใดๆ ลบสิ่งใดก็ตามที่ซ่อนรหัสออก รันคำสั่งบนบรรทัดของตัวเอง หรือเป็นคำสั่งสุดท้ายในบล็อก run: เพื่อให้สถานะออกของมันเป็นสถานะออกของขั้นตอน

การยืนยันตัวตนล้มเหลว สาเหตุที่พบบ่อยที่สุดคือชื่อ secret ไม่ตรงกัน คีย์ env: การอ้างอิงค่า ${{ secrets.APIDOG_ACCESS_TOKEN }} และ secret ที่คุณสร้างใน Settings ทั้งหมดต้องใช้ชื่อเดียวกัน นอกจากนี้ยืนยันว่าโทเค็นไม่ได้ถูกสร้างใหม่ใน Apidog ตั้งแต่คุณบันทึกไว้; การสร้างใหม่จะทำให้โทเค็นเก่าไม่ถูกต้อง

ผ่านบนเครื่อง แต่ล้มเหลวใน CI เพิ่ม --verbose ไปที่คำสั่งรันชั่วคราว มันจะพิมพ์คำขอทั้งหมดที่ runner ส่งไปและคำตอบทั้งหมดที่ได้รับกลับมา ซึ่งมักจะเผยให้เห็นความแตกต่าง ซึ่งบ่อยครั้งเป็นตัวแปรสภาพแวดล้อมที่ตั้งค่าไว้บนเครื่องของคุณแต่ไม่ได้ตั้งค่าในสภาพแวดล้อม CI หรือบริการ staging ที่ทำงานแตกต่างจากในเครื่องของคุณ

รายงานไม่แสดงเป็น artifacts ตรวจสอบให้แน่ใจว่า --out-dir ในขั้นตอนการรันและ path: ในขั้นตอนการอัปโหลดชี้ไปยังไดเรกทอรีเดียวกัน และขั้นตอนการอัปโหลดมี if: always() หากไม่มี if: always() การทดสอบที่ล้มเหลวจะข้ามการอัปโหลดไป และคุณจะสูญเสียรายงานในเวลาที่คุณต้องการมันมากที่สุด

runner ไม่สามารถเข้าถึง API ของคุณได้ หากสภาพแวดล้อม staging หรือ production ของคุณอยู่หลังไฟร์วอลล์หรือ VPN, public GitHub-hosted runner จะไม่สามารถเข้าถึงได้ คุณจะต้องมี self-hosted runner ภายในเครือข่ายของคุณ หรือรายการอนุญาตสำหรับช่วง IP ของ GitHub

สิ่งนี้แตกต่างจากทางเลือกอื่นอย่างไร

คุณสามารถเขียนการทดสอบ API เป็นโค้ดด้วยเฟรมเวิร์ก เชื่อมโยงเข้ากับ test runner และเรียกใช้จาก Actions นั่นใช้งานได้ แต่ตอนนี้คุณกำลังดูแลชุดโค้ดที่ต้องคงความสอดคล้องกับ API และสิ่งที่ทีมของคุณออกแบบในเครื่องมือ API ของพวกเขา วิธีการของ Apidog ข้ามการทำซ้ำนั้นไป: สถานการณ์ที่ทีมของคุณดูแลอยู่แล้วในแอปคือการทดสอบที่รันใน CI

คุณยังสามารถเขียนสคริปต์การเรียก curl แบบดิบๆ ในขั้นตอนเวิร์กโฟลว์ได้ ดีสำหรับการตรวจสอบสถานะครั้งเดียว แต่จะยากเมื่อมากกว่านั้น เพราะคุณต้องเขียนการตรวจสอบ การเปลี่ยนสภาพแวดล้อม และการรายงานด้วยตนเอง ซึ่ง CLI มีให้คุณฟรี

GitHub Actions ไม่ใช่แพลตฟอร์มเดียวสำหรับสิ่งนี้ คำสั่ง apidog run เดียวกันนี้สามารถใช้ได้กับ GitLab CI, Jenkins, CircleCI หรือ runner ใดๆ ที่สามารถรันคำสั่ง shell และอ่านรหัสออกได้ หาก GitHub Actions ไม่ใช่แพลตฟอร์มของคุณ รูปแบบเหล่านี้สามารถนำไปใช้ได้โดยตรง; ดู คู่มือการทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD สำหรับมุมมองข้ามแพลตฟอร์ม หรือคำแนะนำเกี่ยวกับ การผสานรวมการทดสอบอัตโนมัติของ Apidog กับ Jenkins หากคุณใช้ Jenkins

ในการสร้างสถานการณ์ที่คุณจะรัน ดาวน์โหลด Apidog ออกแบบการทดสอบของคุณในแอป และคัดลอกคำสั่ง CLI จากแท็บ CI/CD ของสถานการณ์ runner เป็นแพ็กเกจ npm ฟรี; สิ่งที่คุณสามารถรันได้ขึ้นอยู่กับโปรเจกต์ Apidog ของคุณ แต่ตัว command-line runner เองไม่ใช่ผลิตภัณฑ์ที่ต้องชำระเงินแยกต่างหาก

สรุป

การตั้งค่านี้เล็กกว่าที่เห็น สร้างสถานการณ์ใน Apidog เก็บ Access Token หนึ่งอันเป็น GitHub secret และเพิ่มขั้นตอนเล็กน้อยในไฟล์เวิร์กโฟลว์ จากนั้น Pull Request ทุกครั้งจะรันการทดสอบ API ของคุณโดยอัตโนมัติ เอนด์พอยต์ที่ล้มเหลวจะทำให้การตรวจสอบเป็นสีแดงก่อนการรวมโค้ด และรายงานจะรออยู่ในแท็บ Artifacts เมื่อใดก็ตามที่คุณต้องการดูว่ามีอะไรเสียหาย

เหตุผลที่มันยังคงเรียบง่ายคือการแบ่งงาน แอป Apidog เป็นเจ้าของการทดสอบ; CLI ทำการรัน; GitHub อ่านรหัสออก ไม่ต้องมีการทำซ้ำหรือดูแลให้ซิงค์กัน เมื่อคุณอัปเดตการตรวจสอบในแอป การรัน CI ครั้งถัดไปจะใช้สิ่งนั้น นั่นคือสิ่งที่ทำให้สิ่งนี้คุ้มค่าที่จะทำตั้งแต่วันแรกของโปรเจกต์ แทนที่จะทำหลังจากเกิดเหตุการณ์ใน Production ครั้งแรก

button