Apidog CLI สำหรับ CI/CD: ไพพ์ไลน์ทดสอบ API อัตโนมัติแบบคัดลอก-วาง

คุณเขียนการทดสอบ API ผ่านบนเครื่องของคุณ และนั่นคือที่ที่การทดสอบยังคงอยู่ เพราะการเรียกใช้มันเป็นสิ่งที่ใครบางคนต้องจำไว้ว่าต้องทำ เพื่อนร่วมทีมส่งการเปลี่ยนแปลงในบ่ายวันศุกร์ ปลายทางของระบบยืนยันตัวตน (auth endpoint) เริ่มส่งคืนค่า 500 อย่างเงียบๆ ในโค้ดบางส่วน และผู้ใช้คนแรกที่พบคือผู้ใช้ในวันจันทร์ การครอบคลุมการทดสอบมีอยู่ตลอดเวลา แต่ไม่มีใครเรียกใช้มันในตอนที่จะตรวจจับการถดถอยได้

วิธีแก้ไขคือการย้ายการทดสอบออกจากโปรแกรมแก้ไขของคุณไปอยู่ในไปป์ไลน์ เพื่อให้มันทำงานทุกครั้งที่มีการพุชโดยไม่ต้องมีมนุษย์เข้ามาเกี่ยวข้อง นั่นหมายความว่าคุณต้องมีคำสั่งที่เรียกใช้การทดสอบ API ของคุณแบบไร้หน้าจอ (headlessly) ส่งคืนผลลัพธ์ที่ชัดเจนว่าผ่านหรือไม่ผ่าน และสามารถทำงานร่วมกับระบบ CI ใดๆ ที่คุณใช้อยู่แล้วได้ Apidog CLI ทำสิ่งนั้นได้ คุณสร้างสถานการณ์การทดสอบด้วยภาพใน Apidog จากนั้นเรียกใช้มันจากคำสั่งเทอร์มินัลเดียวที่ CI runner ใดๆ ที่มี Node.js สามารถดำเนินการได้ ไม่ต้องใช้ GUI ไม่ต้องเขียนการทดสอบซ้ำเป็นโค้ด ไม่ต้องมีบริการเพิ่มเติมเพื่อโฮสต์

นี่คือคู่มือแบบคัดลอก-วาง ด้านล่างนี้คุณจะพบไฟล์ไปป์ไลน์ที่พร้อมใช้งานสำหรับ GitHub Actions, GitLab CI, Jenkins, CircleCI และ Azure Pipelines พร้อมด้วยรูปแบบบางส่วนที่ช่วยให้การสร้างที่ผ่านนั้นเป็นไปอย่างซื่อตรง เลือกบล็อกสำหรับแพลตฟอร์มของคุณ เปลี่ยน ID และข้อมูลลับของคุณ แล้วคุณจะมี API tests ที่เป็นเกตสำหรับทุกการผสาน (merge) ภายในสิ้นวัน หากคุณต้องการการอ้างอิงแฟล็กทั้งหมด หัวข้อที่กว้างขึ้นเกี่ยวกับ วิธีการทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD จะครอบคลุมกลยุทธ์ ส่วนหน้านี้เกี่ยวกับการนำไปป์ไลน์ที่ใช้งานได้มาวาง

สิ่งที่คุณกำลังเชื่อมต่อ

Apidog CLI เป็นแพ็คเกจ npm ชื่อ apidog-cli มันเรียกใช้สถานการณ์การทดสอบที่คุณสร้างในแอป Apidog: คำขอแบบลูกโซ่, การยืนยัน, ค่าที่ดึงมาจากคำตอบหนึ่งไปยังอีกคำตอบหนึ่ง, การวนซ้ำที่ขับเคลื่อนด้วยข้อมูล CLI ไม่ได้สร้างรูปแบบการทดสอบของตัวเอง มันจะเข้าไปในโปรเจกต์ของคุณ ค้นหาสถานการณ์ตาม ID เรียกใช้ในลักษณะเดียวกับที่แอปจะทำ และรายงานผลกลับมาพร้อมกับรหัสออก (exit code)

รหัสออกนั้นคือประเด็นสำคัญ เมื่อการยืนยันทั้งหมดผ่าน การทำงานจะออกด้วยรหัส 0 เมื่อมีสิ่งใดล้มเหลว มันจะออกด้วยรหัสที่ไม่ใช่ศูนย์ ระบบ CI จะอ่านรหัสออกนั้น ทำเครื่องหมายว่าขั้นตอนล้มเหลว และบล็อกการผสาน (merge) หรือการปรับใช้ (deploy) คุณไม่จำเป็นต้องกำหนดเกต (gate); เกตคือรหัสออก ตราบใดที่ขั้นตอน apidog run อยู่ในไปป์ไลน์ของคุณ การยืนยันที่ล้มเหลวจะหยุดการทำงานทั้งหมด

สามสิ่งนี้ทำให้การทำงานสำเร็จ และคุณจะเห็นสิ่งเหล่านี้ในทุกบล็อกด้านล่าง:

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

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

คำสั่งเดียวที่ทุกสิ่งสร้างขึ้นมา

นี่คือการรันมาตรฐาน ไฟล์ไปป์ไลน์ทุกไฟล์คือส่วนห่อหุ้ม (wrapper) รอบบรรทัดนี้:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 \
  -e 1629989 \
  -n 1 \
  -r html,junit \
  --out-dir ./apidog-reports

แต่ละส่วนทำหน้าที่อะไร:

--access-token ใช้ตรวจสอบสิทธิ์การรัน มันอ่านค่าจากตัวแปรสภาพแวดล้อม $APIDOG_ACCESS_TOKEN ซึ่งคุณกำหนดค่าจากข้อมูลลับ
-t 605067 เรียกใช้สถานการณ์การทดสอบด้วย ID นั้น เปลี่ยน -t เป็น -f <folderId> เพื่อเรียกใช้ทั้งโฟลเดอร์ หรือ --test-suite <id> เพื่อเรียกใช้ชุดทดสอบที่จัดเตรียมไว้
-e 1629989 กำหนดเป้าหมายสภาพแวดล้อม นี่คือวิธีที่สถานการณ์เดียวกันทำงานกับ staging ในการตรวจสอบ PR และ production ในการทดสอบ smoke test หลังการปรับใช้
-n 1 เรียกใช้สถานการณ์หนึ่งครั้ง เพิ่มค่าเพื่อวนซ้ำ หรือใช้คู่กับ -d <file> เพื่อขับเคลื่อนการวนซ้ำจากไฟล์ข้อมูล CSV หรือ JSON
-r html,junit เลือกรูปแบบรายงาน junit จะส่งออก XML ที่แดชบอร์ด CI ของคุณแยกวิเคราะห์เป็นโครงสร้างผ่าน/ไม่ผ่าน; html คือรายงานที่สามารถเปิดดูได้ซึ่งคุณบันทึกเป็น build artifact เพิ่ม cli หากคุณต้องการเอาต์พุตที่อ่านได้ในบันทึกด้วย
--out-dir ./apidog-reports คือที่ที่รายงานจะถูกบันทึก

ผู้รายงานคือความแตกต่างระหว่าง "การสร้างล้มเหลว" กับ "นี่คือการยืนยันที่ล้มเหลวและคำตอบที่ทำให้เกิดความล้มเหลวนั้น" JUnit XML เป็นรูปแบบที่เกือบทุกแพลตฟอร์มเข้าใจโดยกำเนิด ดังนั้นจึงปรากฏในทั้งห้าบล็อกด้านล่าง

GitHub Actions

วางสิ่งนี้ลงใน .github/workflows/api-tests.yml มันจะเรียกใช้สถานการณ์ของคุณในทุก pull request ที่ทำกับ main อัปโหลดรายงานเป็น 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

มีสองรายละเอียดที่สำคัญ โทเค็นอยู่ใน Settings → Secrets and variables → Actions ในชื่อ APIDOG_ACCESS_TOKEN และเข้าถึงขั้นตอนผ่าน env:. และ if: always() ในขั้นตอนการอัปโหลดหมายความว่าคุณยังคงได้รับรายงานเมื่อการทดสอบล้มเหลว ซึ่งเป็นช่วงเวลาที่คุณต้องการอ่านมันจริงๆ หากสถานการณ์ล้มเหลว ขั้นตอน apidog run จะออกด้วยรหัสที่ไม่ใช่ศูนย์ งานจะถูกทำเครื่องหมายเป็นสีแดง และ PR จะแสดงการตรวจสอบที่ล้มเหลว สำหรับคำแนะนำเชิงลึกสำหรับแพลตฟอร์มนี้โดยเฉพาะ โปรดดูที่ วิธีการทำให้การทดสอบ API เป็นอัตโนมัติใน GitHub Actions

GitLab CI

แนวคิดเดียวกันใน .gitlab-ci.yml อิมเมจ node:20 มีรันไทม์อยู่แล้ว ดังนั้นการตั้งค่าเดียวที่ต้องทำคือการติดตั้ง

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 ไว้ภายใต้ Settings → CI/CD → Variables เป็นตัวแปรที่ถูกปกปิด (masked) และป้องกัน (protected) เพื่อไม่ให้ปรากฏในบันทึก บล็อก reports: junit: เป็นส่วนที่ผู้ใช้ GitLab มักจะพลาด: มันจะบอก GitLab ให้แยกวิเคราะห์ XML และแสดงผลลัพธ์ในวิดเจ็ตคำขอรวม (merge request widget) ผู้ตรวจสอบจะเห็นว่าการยืนยันใดล้มเหลวโดยไม่ต้องดาวน์โหลดสิ่งใด

Jenkins

สำหรับไปป์ไลน์แบบ declarative ให้เก็บโทเค็นเป็น Jenkins credential และดึงเข้าไปในสภาพแวดล้อม จากนั้นเรียกใช้ CLI ใน stage บล็อก post จะป้อน JUnit XML เข้าสู่กราฟแนวโน้มการทดสอบของ Jenkins และเก็บรายงาน HTML ไว้ในการสร้าง

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 agents ของคุณมี CLI ถูกแคชไว้แล้ว ให้ลบแถว npm install ออกและเรียกใช้ apidog run โดยตรง Apidog ยังมีคู่มือการผสานรวมเฉพาะสำหรับ Jenkins ด้วย หากคุณต้องการใช้เส้นทางปลั๊กอินแทนที่จะเป็นขั้นตอนเชลล์: ผสานรวมการทดสอบอัตโนมัติของ Apidog กับ Jenkins สำหรับ CI/CD

CircleCI

ใน .circleci/config.yml ให้ใช้ Node convenience image และเก็บโทเค็นเป็นตัวแปรสภาพแวดล้อมของโปรเจกต์ภายใต้ Project Settings → Environment Variables

version: 2.1

jobs:
  api-tests:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - run:
          name: Install Apidog CLI
          command: npm install -g apidog-cli
      - run:
          name: Run API test scenario
          command: |
            apidog run \
              --access-token "$APIDOG_ACCESS_TOKEN" \
              -t 605067 \
              -e 1629989 \
              -r junit,cli \
              --out-dir ./apidog-reports
      - store_test_results:
          path: ./apidog-reports
      - store_artifacts:
          path: ./apidog-reports
          destination: apidog-reports

workflows:
  test:
    jobs:
      - api-tests

store_test_results เทียบเท่ากับบล็อก JUnit ของ GitLab; ชี้ไปที่ไดเรกทอรีรายงาน และ CircleCI จะแสดงการยืนยันที่ล้มเหลวในแท็บ Tests ของมัน store_artifacts จะเก็บรายงาน HTML ที่แนบไว้ เพื่อให้คุณสามารถเปิดดูได้จากหน้า build

Azure Pipelines

ใน azure-pipelines.yml ให้ติดตั้ง Node ด้วย task เรียกใช้ CLI และเผยแพร่ผลลัพธ์ JUnit เพิ่ม APIDOG_ACCESS_TOKEN เป็นตัวแปรลับในไปป์ไลน์ (หรือดึงมาจาก Azure Key Vault variable group) จากนั้นแมปเข้าสู่ env ของขั้นตอนสคริปต์

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'
    displayName: 'Install Node.js'

  - script: npm install -g apidog-cli
    displayName: 'Install Apidog CLI'

  - script: |
      apidog run \
        --access-token "$APIDOG_ACCESS_TOKEN" \
        -t 605067 \
        -e 1629989 \
        -r junit,html \
        --out-dir ./apidog-reports
    displayName: 'Run API test scenario'
    env:
      APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

  - task: PublishTestResults@2
    condition: always()
    inputs:
      testResultsFormat: 'JUnit'
      testResultsFiles: 'apidog-reports/*.xml'
      testRunTitle: 'Apidog API tests'

มาโคร $(APIDOG_ACCESS_TOKEN) จะอ่านตัวแปรลับของไปป์ไลน์; การแมปผ่าน env จะช่วยให้มันไม่ปรากฏใน command line ที่มองเห็นได้ PublishTestResults@2 พร้อม condition: always() ทำให้ผลลัพธ์ปรากฏในแท็บ Tests ไม่ว่าการรันจะผ่านหรือล้มเหลว สำหรับคำแนะนำที่สมบูรณ์ยิ่งขึ้นเกี่ยวกับแพลตฟอร์มนี้ Apidog มีคู่มือแนะนำเฉพาะสำหรับการทดสอบ API ใน Azure DevOps pipeline

รูปแบบที่ทำให้เกตซื่อตรง

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

ทำการทดสอบ Smoke test ทันทีหลังจากการปรับใช้ เรียกใช้สถานการณ์ที่รวดเร็วหนึ่งรายการกับ production ทันทีที่การเผยแพร่เกิดขึ้น ชี้ไปที่สภาพแวดล้อม prod และหยุดเมื่อพบความล้มเหลวครั้งแรก:

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

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

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

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

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

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

ทดสอบ feature branch ไม่ใช่ main เรียกใช้สถานการณ์ตามที่มันมีอยู่ใน branch:

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

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

เมื่อการสร้างโกหกคุณ

มีโหมดความล้มเหลวบางอย่างที่เกิดขึ้นบ่อยพอที่จะกล่าวถึง เพราะแต่ละโหมดจะบั่นทอนเกตอย่างเงียบๆ

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

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

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

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

ข้อผิดพลาด TLS กับโฮสต์ภายใน หากปลายทางของคุณใช้ CA ภายใน ให้ส่งใบรับรอง CA เพิ่มเติมแทนที่จะปิดใช้งานการตรวจสอบ ใช้ -k (ข้ามการตรวจสอบ SSL) เป็นทางเลือกสุดท้ายเท่านั้นกับโฮสต์ภายในที่เชื่อถือได้ซึ่งมีใบรับรองแบบ self-signed ห้ามใช้กับสาธารณะเด็ดขาด

ทำไมต้องสร้างด้วยภาพและรันแบบไร้หน้าจอ

มีการออกแบบที่แท้จริงภายใต้ทั้งหมดนี้ และมันก็คุ้มค่าที่จะกล่าวถึง ด้วย script-first runners การทดสอบและการดำเนินการจะอยู่ในไฟล์เดียวกัน ดังนั้นสคริปต์ที่เปราะบางจึงเป็นทั้งการทดสอบและจุดคอขวดของคุณ ใน Apidog สถานการณ์ในโปรเจกต์ของคุณคือการทดสอบ และ CLI เพียงแค่เรียกใช้มันในที่ที่มนุษย์ไม่สามารถทำได้ ไม่มีใครต้องดูแลการแสดงผลสองแบบของการตรวจสอบเดียวกัน คุณสร้างได้อย่างรวดเร็วในเครื่องมือสร้างภาพ คุณรันโดยอัตโนมัติในไปป์ไลน์ และทั้งสองจะซิงค์กันอยู่เสมอเพราะมันเป็นสิ่งประดิษฐ์เดียวกัน นั่นเป็นส่วนสำคัญที่ว่าทำไมทีมต่างๆ จึงมองว่า Apidog เป็น ทางเลือก Postman สำหรับการทดสอบ API เมื่อ CI เข้ามามีบทบาท และทำไม การยืนยัน API ที่แข็งแกร่งจึงสำคัญกว่า runner ที่คุณใช้ห่อหุ้มมัน

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

หากการทดสอบของคุณยังคงอยู่ในโปรแกรมแก้ไขของใครบางคน นั่นคือช่องว่างที่คุณต้องปิดให้ได้ในสัปดาห์นี้ ดาวน์โหลด Apidog สร้างสถานการณ์หนึ่งให้ผ่าน คัดลอกคำสั่ง apidog run จากแท็บ CI/CD และวางบล็อกด้านบนสำหรับแพลตฟอร์มของคุณ คุณจะมีการทดสอบ API ที่เป็นเกตสำหรับทุกการผสาน (merge) ในบ่ายวันเดียวกัน

ปุ่ม

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

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

ฉันต้องเขียนการทดสอบใหม่เป็นโค้ดหรือไม่? ไม่ คุณสร้างสถานการณ์ด้วยภาพใน Apidog และ CLI จะเรียกใช้มันด้วย ID สถานการณ์คือการทดสอบ; CLI เป็นเพียงตัวดำเนินการ นั่นคือประเด็นหลักที่แยกมันออกจาก script-first runners.

การทดสอบที่ล้มเหลวจะทำให้ build ของฉันล้มเหลวได้อย่างไร? ผ่านรหัสออก (exit code) เมื่อการยืนยันใดๆ ล้มเหลว apidog run จะออกด้วยรหัสที่ไม่ใช่ศูนย์ ระบบ CI ของคุณจะอ่านค่านี้ ทำเครื่องหมายว่าขั้นตอนล้มเหลว และบล็อกการผสาน (merge) หรือการปรับใช้ (deploy) คุณไม่จำเป็นต้องเพิ่มการกำหนดค่าพิเศษใดๆ เพื่อให้เกตทำงานได้

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

ฉันต้องติดตั้ง Apidog บน CI server หรือไม่? ไม่ CI runner เพียงแค่ต้องการ Node.js (เวอร์ชัน 16 หรือใหม่กว่า) และแพ็คเกจ apidog-cli ไม่จำเป็นต้องมีแอปพลิเคชันเดสก์ท็อป ไม่มี GUI ไม่มีไฟล์ไลเซนส์บนเครื่อง แพ็คเกจพร้อมโทเค็นการเข้าถึงก็เพียงพอแล้ว

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

สิ่งนี้แตกต่างจาก Newman อย่างไร? Newman เรียกใช้ Postman collections จาก command line ส่วน Apidog CLI เรียกใช้สถานการณ์การทดสอบของ Apidog บทบาททั้งสองขนานกัน แต่ Apidog runner จะดำเนินการสถานการณ์ที่คุณสร้างในแอปและมาพร้อมกับแพ็คเกจ apidog-cli เพียงตัวเดียว ดู Postman CLI vs Newman สำหรับการเปรียบเทียบในมุมของ Postman

ฉันจะรับโทเค็นการเข้าถึงและ ID ได้จากที่ไหน? ทั้งหมดนี้มาจากแท็บ CI/CD ของสถานการณ์การทดสอบใน Apidog เลือกตัวเลือก command-line สร้างโทเค็นการเข้าถึง และคัดลอกคำสั่ง apidog run ที่สมบูรณ์ซึ่ง Apidog สร้างขึ้นพร้อมกับ ID สถานการณ์และสภาพแวดล้อมที่กรอกไว้แล้ว จากนั้นย้ายโทเค็นไปยัง CI secret และอ้างอิงถึงมันในชื่อ $APIDOG_ACCESS_TOKEN