Các bài kiểm thử API của bạn vượt qua trên máy của bạn. Sau đó, một đồng đội hợp nhất một thay đổi làm hỏng điểm cuối đăng nhập, và không ai nhận ra cho đến khi khách hàng gửi yêu cầu hỗ trợ. Các bài kiểm thử đã tồn tại. Chúng chỉ không bao giờ chạy vào thời điểm quan trọng: trên yêu cầu kéo (pull request), trước khi hợp nhất (merge).
Khoảng cách đó chính là điều mà tích hợp liên tục (CI - Continuous Integration) khắc phục. Bạn chuyển các bài kiểm thử khỏi thiết bị đầu cuối cục bộ của mình và đưa vào một quy trình (pipeline) tự động chạy chúng, trên mỗi lần đẩy (push), đối với mọi thay đổi. Cụ thể đối với kiểm thử API, cách sạch nhất để làm điều này là sử dụng một trình chạy dòng lệnh (command-line runner) thực thi chính xác các kịch bản bạn đã xây dựng, trả về mã thoát thành công/thất bại, và để CI quyết định liệu bản dựng có màu xanh (thành công) hay màu đỏ (thất bại) hay không.
button
TL;DR (Tóm tắt)
- Apidog CLI là một gói npm,
apidog-cli. Cài đặt nó trong một bước quy trình làm việc (workflow step) vớinpm install -g apidog-cli, sau đó chạy các kịch bản vớiapidog run. - Nó thực thi các kịch bản kiểm thử bạn thiết kế trong ứng dụng Apidog bằng ID. Bạn không cần chuyển các bài kiểm thử thành mã; CLI chạy cùng một kịch bản bằng cách sử dụng mã truy cập (access token) để xác thực.
- Một tác vụ GitHub Actions tối thiểu gồm bốn bước: checkout (tải mã nguồn), thiết lập Node, cài đặt CLI, chạy
apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t <scenarioId> -e <environmentId> -r junit,cli. - CLI sẽ thoát với mã khác 0 khi bất kỳ khẳng định nào thất bại. GitHub đọc mã thoát đó, đánh dấu kiểm tra thất bại và chặn việc hợp nhất. Đó chính là toàn bộ cổng chất lượng (quality gate); bạn không cần cấu hình thêm bất cứ điều gì.
- Lưu mã truy cập dưới dạng bí mật (secret) của GitHub Actions và truyền nó qua
env:. Không bao giờ commit mã này vào kho. - Sử dụng
-r junitđể đưa kết quả vào một bảng điều khiển (dashboard),-r htmlcho một tài liệu (artifact) có thể duyệt được, vàif: always()trên bước tải lên để bạn vẫn nhận được báo cáo khi kiểm thử thất bại.
Tại sao phải chạy kiểm thử API trong CI
Một bài kiểm thử mà chỉ chạy khi bạn nhớ chạy nó là một bài kiểm thử bạn không thể tin cậy. Chạy cục bộ (local run) vẫn ổn khi bạn đang viết kịch bản. Nhưng chúng sẽ trở nên vô dụng khi có một nhóm làm việc, vì máy tính của mỗi nhà phát triển hơi khác nhau và không ai chạy toàn bộ bộ kiểm thử trước mỗi lần đẩy (push).
CI khắc phục vấn đề tin cậy bằng cách làm cho quá trình chạy tự động và đồng bộ. Mỗi yêu cầu kéo (pull request) kích hoạt cùng một tác vụ (job), trên cùng một trình chạy (runner) sạch, đối với cùng một môi trường. Khi một điểm cuối bắt đầu trả về lỗi 500 hoặc một lược đồ phản hồi bị lệch, kiểm tra sẽ thất bại trên PR gây ra nó, kèm theo tên của người đã đẩy thay đổi đó. Phản hồi đến trong vòng vài phút, khi thay đổi vẫn còn mới, thay vì vài ngày sau khi triển khai lên môi trường sản xuất.
Kiểm thử API rất phù hợp với việc này vì chúng nhanh chóng và có tính xác định. Một kịch bản truy cập các điểm cuối thực tế, khẳng định về mã trạng thái và nội dung phản hồi, và hoặc là thành công hoặc là thất bại. Không có trình duyệt lỗi thời, không cần chờ đợi hiển thị. Điều đó làm cho chúng trở nên lý tưởng như một cổng hợp nhất (merge gate): đủ nhanh để chạy trên mỗi PR, đủ quyết đoán để chặn một PR xấu. Nếu bạn muốn tìm hiểu thêm về CI/CD là gì và cách các phần hoạt động cùng nhau, hướng dẫn về CI/CD là gì và cách thức hoạt động của nó sẽ bao gồm các nguyên tắc cơ bản.
Apidog CLI thực sự làm gì
Đây là phần giúp bạn tiết kiệm thời gian nhất: bạn không cần viết mã kiểm thử cho CLI.
Bạn xây dựng các kịch bản kiểm thử của mình một cách trực quan trong ứng dụng Apidog, với các yêu cầu, khẳng định, biến môi trường và dữ liệu bạn cần. CLI là một trình chạy. Với ID kịch bản và mã truy cập, nó sẽ tìm nạp kịch bản đó từ dự án Apidog của bạn và thực thi nó, từng yêu cầu một, đánh giá mọi khẳng định chính xác như ứng dụng sẽ làm. Kết quả là một báo cáo và mã thoát.
Thiết kế đó rất quan trọng đối với CI. Hầu hết các trình chạy kiểm thử yêu cầu bạn duy trì một biểu diễn mã riêng biệt cho các bài kiểm thử của mình; điều bạn chạy trong quy trình sẽ khác biệt so với điều bạn đã thiết kế. Với Apidog, quy trình chạy cùng một kịch bản mà nhóm của bạn đã duy trì trong ứng dụng. Cập nhật một khẳng định trong trình chỉnh sửa trực quan và lần chạy CI tiếp theo sẽ sử dụng nó. Không có bản sao thứ hai cần phải giữ đồng bộ.
File thực thi là apidog, được phân phối dưới dạng gói npm apidog-cli. Mọi lệnh đều bắt đầu với apidog run. Nếu bạn muốn thấy trình chạy được tích hợp vào một quy trình tự động hóa đầy đủ hơn, hướng dẫn về tích hợp Apidog CLI với Claude Skills để tự động hóa kiểm thử API sẽ bao gồm khía cạnh đó; bài viết này tập trung vào các cờ (flags) bạn cần cho một quy trình GitHub Actions.
Trước khi bắt đầu: ba điều bạn cần
Bạn cần ba thông tin trước khi quy trình làm việc có thể chạy. Hai là ID từ dự án Apidog của bạn; một là mã token.
- Một kịch bản kiểm thử. Xây dựng nó trong ứng dụng Apidog nếu bạn chưa có. Đây là những gì CLI sẽ chạy. Một kịch bản đăng nhập và lấy hồ sơ đơn giản là đủ để bắt đầu; bạn có thể mở rộng sau này.
- ID kịch bản và ID môi trường. ID kịch bản cho CLI biết cần chạy gì; ID môi trường cho nó biết ở đâu (dev, staging, production). Cả hai đều hiển thị trong ứng dụng.
- Một mã truy cập (access token). Mã này xác thực CLI với tài khoản Apidog của bạn để nó có thể tìm nạp và chạy kịch bản.
Cách sạch nhất để có tất cả những điều này cùng một lúc là thông qua tab CI/CD của kịch bản. Mở kịch bản kiểm thử bạn muốn tự động hóa, chuyển sang tab CI/CD của nó và chọn tùy chọn dòng lệnh. Nhấp để thêm mã truy cập và tạo một mã. Apidog sẽ tự động tạo lệnh apidog run đầy đủ cho bạn, với mã truy cập, ID kịch bản (-t) và ID môi trường (-e) đã được điền sẵn. Sao chép lệnh đó; đây là cơ sở cho bước CI của bạn.
Một quy tắc đáng nêu ra ngay từ đầu: hãy coi mã truy cập như một mật khẩu. Đừng dán nó vào một file workflow đã được commit. Lưu trữ nó dưới dạng bí mật (secret) của GitHub Actions và tham chiếu nó dưới dạng biến môi trường. Mọi ví dụ dưới đây đều sử dụng $APIDOG_ACCESS_TOKEN chính vì lý do đó.
Bước 1: Lưu mã truy cập dưới dạng bí mật của GitHub
Mở kho lưu trữ của bạn trên GitHub. Đi tới Settings, sau đó Secrets and variables, sau đó Actions, và nhấp vào New repository secret.
- Tên:
APIDOG_ACCESS_TOKEN - Bí mật: dán mã token Apidog đã tạo cho bạn
Lưu lại. Mã token hiện được mã hóa khi lưu trữ và chỉ được hiển thị cho các lần chạy workflow, không bao giờ được in trong nhật ký. Trong workflow, bạn sẽ tham chiếu nó dưới dạng ${{ secrets.APIDOG_ACCESS_TOKEN }} và chuyển nó cho CLI thông qua một khối env:. ID kịch bản và ID môi trường không phải là bí mật; chúng là các ID vô hại, vì vậy bạn có thể viết trực tiếp chúng vào file workflow. Chỉ mã token cần được bảo vệ.
Nếu nhóm của bạn làm việc trên nhiều kho lưu trữ mà tất cả đều truy cập cùng một dự án Apidog, hãy định nghĩa bí mật một lần ở cấp độ tổ chức và cấp quyền truy cập cho các kho lưu trữ liên quan. Cùng tên, một nơi để xoay vòng nó.
Bước 2: Quy trình làm việc tối thiểu
Tạo .github/workflows/api-tests.yml trong kho lưu trữ của bạn. Đây là quy trình làm việc nhỏ nhất nhưng hữu ích: nó chạy kịch bản của bạn trên mỗi yêu cầu kéo (pull request) nhắm mục tiêu đến nhánh 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 }}
Thay thế 605067 bằng ID kịch bản của bạn và 1629989 bằng ID môi trường của bạn. Commit file này, mở một yêu cầu kéo, và theo dõi tab Checks. Tác vụ sẽ khởi động một trình chạy Ubuntu, cài đặt Node 20, cài đặt CLI, và chạy kịch bản của bạn. Nếu mọi khẳng định đều vượt qua, kiểm tra sẽ hiển thị màu xanh. Nếu một cái thất bại, apidog run sẽ thoát với mã khác 0, GitHub sẽ đánh dấu kiểm tra thất bại, và PR sẽ hiển thị dấu X màu đỏ.
Dấu X màu đỏ đó chính là toàn bộ điểm mấu chốt. Không ai phải đọc nhật ký để biết có gì đó bị hỏng; kiểm tra thất bại hiển thị ngay trên yêu cầu kéo.
Một lưu ý về bước cài đặt: lệnh npm install -g apidog-cli toàn cục đơn giản và hoạt động tốt. Nếu bạn không muốn thay đổi các gói toàn cục của trình chạy, bạn có thể bỏ qua bước cài đặt và gọi CLI thông qua npx thay thế:
- 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 }}
Cả hai phương pháp đều chạy cùng một kịch bản. npx gọn gàng hơn trên các trình chạy tạm thời (ephemeral runners); cài đặt toàn cục nhanh hơn một chút khi bạn lưu vào bộ nhớ cache node_modules giữa các lần chạy. Chọn phương pháp nào phù hợp với phong cách của bạn.
Bước 3: Xuất bản một báo cáo bạn thực sự có thể đọc
Một dấu kiểm màu xanh hoặc đỏ cho bạn biết kết quả. Khi một bài kiểm thử thất bại, bạn muốn biết lý do tại sao, và vì điều đó bạn cần báo cáo.
Cờ -r (hoặc --reporters) điều khiển các định dạng báo cáo. Nó chấp nhận cli, html, json, và junit, được phân tách bằng dấu phẩy. Đối với CI, hai định dạng đáng dùng là:
junitxuất ra XML ở định dạng JUnit tiêu chuẩn. Hầu hết các bảng điều khiển CI và công cụ báo cáo kiểm thử đều biết cách phân tích nó thành một cây pass/fail.htmltạo ra một báo cáo độc lập mà bạn có thể lưu dưới dạng tài liệu (build artifact) và mở trong trình duyệt, với đầy đủ yêu cầu và phản hồi cho mỗi bước.
Cũng giữ cli nếu bạn muốn đầu ra dễ đọc trong chính nhật ký bản dựng. Dưới đây là bước chạy được nâng cấp để tạo cả hai định dạng báo cáo và ghi chúng vào một thư mục, cộng với một bước tải lên để báo cáo tồn tại sau khi chạy:
- 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
Hai chi tiết làm cho điều này hoạt động như bạn muốn. Cờ --out-dir cho CLI biết nơi để ghi báo cáo; ở đây là ./apidog-reports, sau đó bước tải lên sẽ lấy nó. Và if: always() trên bước tải lên là điều quan trọng: theo mặc định, GitHub bỏ qua các bước sau nếu một bước thất bại, nhưng bạn muốn báo cáo nhất khi các bài kiểm thử thất bại. if: always() buộc việc tải lên phải chạy bất kể kết quả kiểm thử là gì. Sau khi tác vụ kết thúc, báo cáo sẽ hiển thị dưới mục Artifacts trên trang tóm tắt lần chạy, sẵn sàng để tải xuống.
Cờ -n 1 đặt số lần lặp thành một lần chạy; tăng nó nếu bạn muốn kịch bản được thực thi nhiều lần liên tiếp.
Nếu bạn muốn GitHub hiển thị kết quả JUnit trực tiếp dưới dạng một kiểm tra có chú thích (annotated check) thay vì một tệp có thể tải xuống, hãy thêm hành động published-test-results sau bước chạy và trỏ nó vào ./apidog-reports/*.xml. Điều đó sẽ biến XML thành một bản tóm tắt thành công/thất bại đính kèm vào lần chạy, rất tiện lợi cho các bộ kiểm thử lớn hơn khi việc cuộn nhật ký không thực tế.
Bước 4: Kiểm thử đúng môi trường vào đúng thời điểm
Một yêu cầu kéo (pull request) nên kiểm thử với môi trường staging. Một triển khai lên môi trường sản xuất (production) nên được xác minh với môi trường production. Cùng một kịch bản có thể làm cả hai; bạn chỉ cần thay đổi ID môi trường bằng -e.
Một thiết lập phổ biến, bền vững sử dụng hai trình kích hoạt (triggers) trong một file workflow. Các yêu cầu kéo chạy kịch bản với môi trường staging của bạn như một cổng hợp nhất (merge gate). Các lần đẩy (pushes) lên nhánh main (là kết quả của một lần hợp nhất) chạy cùng một kịch bản với môi trường production như một kiểm thử khói (smoke test) sau triển khai.
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 }}
Hai ID môi trường (1629989 cho staging, 1730055 cho production) là sự khác biệt có ý nghĩa duy nhất. Tác vụ PR xây dựng và lưu trữ báo cáo JUnit để người đánh giá có thể kiểm tra các lỗi; kiểm thử khói production chạy nhanh chóng và thất bại ngay lập tức với --on-error end, điều này dừng lại ở khẳng định lỗi đầu tiên để bạn nhanh chóng phát hiện ra rằng một triển khai đã gặp sự cố.
--on-error rất đáng để biết. Nó kiểm soát điều gì xảy ra khi một bước thất bại giữa chừng kịch bản. end dừng quá trình chạy ở lỗi đầu tiên (phản hồi nhanh, tốt cho kiểm thử khói). continue chạy mọi bước còn lại để bạn thấy tất cả các lỗi trong một báo cáo (tốt cho kiểm tra PR kỹ lưỡng). ignore bỏ qua một bước được biết là không ổn định mà không làm chệch hướng quá trình chạy. Dù bạn chọn cách nào, quá trình chạy vẫn kết thúc với mã thoát khác 0 nếu có bất kỳ điều gì thất bại, vì vậy cổng bảo vệ vẫn hoạt động theo bất kỳ cách nào.
Tiến xa hơn: chạy ma trận, thư mục và kiểm thử dựa trên dữ liệu
Khi cổng bảo vệ cơ bản đã được thiết lập, một vài cờ (flags) sẽ mở rộng nó mà không cần nhiều YAML bổ sung.
Chạy toàn bộ một khu vực tính năng, không chỉ một kịch bản. Thay thế -t <scenarioId> bằng -f <folderId> để chạy mọi kịch bản bên trong một thư mục, hoặc --test-suite <testSuiteId> để chạy một bộ kiểm thử được quản lý. Các bộ kiểm thử là công cụ phù hợp khi bạn muốn một tập hợp các kịch bản cụ thể, có thứ tự được chạy cùng nhau như một tác vụ logic; hướng dẫn về mở rộng kiểm thử API tự động với các bộ kiểm thử sẽ bao gồm thời điểm nên sử dụng chúng.
Kiểm thử nhiều môi trường song song. Một ma trận (matrix) chạy cùng một tác vụ trên nhiều ID môi trường cùng một lúc:
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 khởi động một trình chạy cho mỗi giá trị ma trận, vì vậy staging và production được kiểm thử đồng thời và mỗi môi trường báo cáo kết quả thành công/thất bại riêng.
Chạy các lần lặp từ một tệp dữ liệu. Cờ -d chạy một kịch bản trên các hàng của tệp CSV hoặc JSON, coi mỗi hàng là một lần chạy riêng biệt: apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -d ./test-data.csv -r junit. Đây là cách bạn xác thực cùng một điểm cuối với năm mươi đầu vào mà không cần xây dựng năm mươi kịch bản.
Chạy đối với một nhánh. Nếu nhóm của bạn sử dụng tính năng nhánh của Apidog, --branch <branchName> sẽ trỏ lần chạy đến một nhánh cụ thể thay vì main, điều này cho phép PR của một nhánh tính năng kiểm thử đối với các định nghĩa kịch bản của nhánh đó.
Khắc phục sự cố các lỗi CI phổ biến
Tác vụ hiển thị màu xanh nhưng một bài kiểm thử lẽ ra phải thất bại. Kiểm tra xem mã thoát của bước apidog run có thực sự đến được GitHub hay không. Nếu bạn đã bọc lệnh trong một đường ống shell (shell pipeline) hoặc thêm || true, mã thoát khác 0 sẽ bị nuốt và cổng bảo vệ sẽ ngừng hoạt động một cách âm thầm. Loại bỏ bất cứ thứ gì che giấu mã thoát. Chạy lệnh trên một dòng riêng, hoặc là lệnh cuối cùng trong một khối run:, để trạng thái thoát của nó là trạng thái thoát của bước.
Xác thực thất bại. Nguyên nhân phổ biến nhất là tên bí mật không khớp. Khóa env:, tham chiếu giá trị ${{ secrets.APIDOG_ACCESS_TOKEN }}, và bí mật bạn đã tạo trong Settings đều phải sử dụng cùng một tên. Cũng xác nhận rằng mã token chưa được tạo lại trong Apidog kể từ khi bạn lưu nó; việc tạo lại sẽ làm mất hiệu lực mã cũ.
Thành công cục bộ, thất bại trong CI. Thêm --verbose vào lệnh chạy tạm thời. Nó in ra yêu cầu đầy đủ mà trình chạy đã gửi và phản hồi đầy đủ nó nhận được, điều này thường tiết lộ sự khác biệt, thường là một biến môi trường được thiết lập trên máy của bạn nhưng không có trong môi trường CI, hoặc một dịch vụ staging hoạt động khác với dịch vụ cục bộ của bạn.
Các báo cáo không hiển thị dưới dạng tài liệu (artifacts). Đảm bảo --out-dir trong bước chạy và path: trong bước tải lên trỏ đến cùng một thư mục, và bước tải lên có if: always(). Nếu không có if: always(), một bài kiểm thử thất bại sẽ bỏ qua việc tải lên và bạn sẽ mất báo cáo chính xác vào lúc bạn cần nó nhất.
Trình chạy không thể tiếp cận API của bạn. Nếu môi trường staging hoặc production của bạn nằm sau tường lửa (firewall) hoặc VPN, một trình chạy được GitHub lưu trữ công khai sẽ không thể tiếp cận nó. Bạn sẽ cần một trình chạy tự lưu trữ (self-hosted runner) bên trong mạng của bạn, hoặc một mục trong danh sách cho phép (allowlist entry) cho các dải IP của GitHub.
Cách tiếp cận này so với các lựa chọn thay thế
Bạn có thể viết các bài kiểm thử API dưới dạng mã với một framework, kết nối chúng vào một trình chạy kiểm thử và gọi từ Actions. Điều đó hoạt động, nhưng giờ đây bạn phải duy trì một bộ mã phải được đồng bộ với API và với bất cứ điều gì nhóm của bạn thiết kế trong công cụ API của họ. Cách tiếp cận của Apidog bỏ qua sự trùng lặp đó: kịch bản mà nhóm của bạn đã duy trì trong ứng dụng chính là bài kiểm thử chạy trong CI.
Bạn cũng có thể viết script các lệnh curl thô trong một bước workflow. Tốt cho một lần kiểm tra tình trạng (health check) duy nhất, nhưng gây khó khăn sau đó, vì bạn phải tự tay thực hiện các khẳng định, chuyển đổi môi trường và báo cáo mà CLI cung cấp cho bạn miễn phí.
GitHub Actions cũng không phải là nơi duy nhất cho việc này. Lệnh apidog run chính xác như vậy có thể được đưa vào GitLab CI, Jenkins, CircleCI hoặc bất kỳ trình chạy nào có thể thực thi lệnh shell và đọc mã thoát. Nếu GitHub Actions không phải là nền tảng của bạn, các mẫu ở đây có thể được chuyển đổi trực tiếp; xem hướng dẫn tự động hóa kiểm thử API trong CI/CD để có cái nhìn đa nền tảng, hoặc hướng dẫn về tích hợp kiểm thử tự động của Apidog với Jenkins nếu bạn đang sử dụng Jenkins.
Để xây dựng các kịch bản bạn sẽ chạy, tải xuống Apidog, thiết kế các bài kiểm thử của bạn trong ứng dụng và lấy lệnh CLI từ tab CI/CD của kịch bản. Trình chạy là một gói npm miễn phí; những gì bạn có thể chạy phụ thuộc vào dự án Apidog của bạn, nhưng bản thân trình chạy dòng lệnh không phải là một sản phẩm trả phí riêng biệt.
Tổng kết
Thiết lập này nhỏ hơn vẻ ngoài của nó. Xây dựng một kịch bản trong Apidog, lưu trữ một mã truy cập dưới dạng bí mật của GitHub và thêm một vài bước vào một tệp workflow. Từ đó, mọi yêu cầu kéo sẽ tự động chạy kiểm thử API của bạn, một điểm cuối bị lỗi sẽ chuyển kiểm tra thành màu đỏ trước khi hợp nhất, và báo cáo sẽ chờ trong tab Artifacts bất cứ khi nào bạn cần xem điều gì đã bị hỏng.
Lý do nó vẫn đơn giản là sự phân chia công việc. Ứng dụng Apidog sở hữu các bài kiểm thử; CLI chạy chúng; GitHub đọc mã thoát. Không có gì phải trùng lặp hoặc giữ đồng bộ. Khi bạn cập nhật một khẳng định trong ứng dụng, lần chạy CI tiếp theo sẽ sử dụng nó. Đó là điều khiến việc này đáng làm ngay từ ngày đầu tiên của một dự án thay vì thêm vào sau sự cố sản xuất đầu tiên.
button