Cách chạy kiểm thử API tự động trong TeamCity

API của bạn vượt qua mọi bài kiểm tra trên máy tính xách tay. Sau đó, một đồng đội hợp nhất một nhánh đổi tên một trường, và không ai nhận ra cho đến khi một ứng dụng di động bắt đầu gặp sự cố trong môi trường sản xuất. Kiểm thử thủ công đã bỏ sót điều đó vì không ai chạy lại bộ kiểm thử. Đây chính xác là khoảng trống mà tích hợp liên tục (CI) được xây dựng để lấp đầy, và TeamCity là một trong những công cụ mạnh mẽ nhất để làm điều đó.

TeamCity, máy chủ CI/CD của JetBrains, chạy quy trình xây dựng (build pipeline) của bạn mỗi khi mã được đẩy lên. Nó có thể biên dịch, kiểm thử, đóng gói và triển khai mà không cần ai phải nhấp vào nút nào. Phần mà các nhóm thường bỏ qua là tích hợp các bài kiểm thử API thực tế vào quy trình đó. Họ kiểm thử các đơn vị, họ kiểm thử việc build có biên dịch được hay không, và họ triển khai API dựa trên niềm tin. Một trường bị đổi tên, lỗi 500 trong trường hợp đặc biệt, một luồng xác thực bị hỏng; không có gì trong số đó xuất hiện cho đến khi một người dùng thực sự gọi endpoint.

Hướng dẫn này sẽ chỉ cho bạn cách chạy các bài kiểm thử API tự động bên trong TeamCity từ đầu đến cuối. Bạn sẽ thiết kế và xác thực các bài kiểm thử của mình trong Apidog, sau đó chạy chúng không cần giao diện (headless) thông qua Apidog CLI như một bước build của TeamCity. Kết quả là một quy trình sẽ làm lỗi build ngay khi API của bạn ngừng hoạt động đúng cách, trước khi một phản hồi xấu đến tay người dùng.

Bạn sẽ xây dựng gì

Đến cuối cùng, bạn sẽ có:

• Một dự án TeamCity được kết nối với kho lưu trữ Git của bạn
• Một cấu hình build với trigger VCS kích hoạt trên mỗi lần push
• Một bước build chạy bộ kiểm thử API của bạn thông qua Apidog CLI
• Kết quả kiểm thử được phân tích cú pháp hiển thị trong tab Tests của TeamCity
• Một build bị lỗi (màu đỏ) và chặn việc hợp nhất khi một endpoint bị hỏng

Mẫu này hoạt động tương tự cho một dịch vụ nội bộ nhỏ hoặc một API công cộng với hàng trăm endpoint. Bạn mở rộng nó bằng cách thêm các kịch bản kiểm thử trong Apidog, chứ không phải bằng cách chỉnh sửa mã quy trình.

Tại sao kiểm thử API nên được tích hợp vào TeamCity, không chỉ trên máy của bạn

Kiểm thử cục bộ có một lỗi chết người: nó phụ thuộc vào việc ai đó có nhớ chạy nó hay không. CI loại bỏ yếu tố con người khỏi vòng lặp. Mọi commit đều kích hoạt cùng một bộ kiểm thử, trong cùng một môi trường, với cùng các xác nhận (assertions). Không có chuyện “nó hoạt động trên máy của tôi” vì không có máy nào cả; chỉ có một tác nhân build (build agent) chạy chính xác các bước bạn đã định nghĩa.

TeamCity là lựa chọn phù hợp cho điều này vì một vài lý do cụ thể:

• Chuỗi build (Build chains). Bạn có thể làm cho bước kiểm thử API phụ thuộc vào một bước triển khai lên môi trường staging, để các bài kiểm thử luôn chạy trên một bản build mới được triển khai, không bao giờ là bản cũ.
• Lịch sử kiểm thử (Test history). TeamCity theo dõi bài kiểm thử nào đã vượt qua và thất bại qua hàng trăm bản build. Khi một bài kiểm thử bắt đầu không ổn định, bạn sẽ thấy chính xác commit nào đã gây ra nó.
• Điều tra và tắt tạm thời (Investigation and muting). Một endpoint không ổn định có thể được tắt tạm thời và gán cho một chủ sở hữu thay vì chặn việc hợp nhất của mọi người.
• Nhóm tác nhân (Agent pools). Các bộ kiểm thử nặng có thể chạy trên các tác nhân chuyên dụng để chúng không làm chậm các bản build biên dịch của bạn.

Vấn đề là TeamCity không biết cách gọi API của bạn hoặc kiểm tra phản hồi. Nó chạy bất kỳ lệnh nào bạn cung cấp. Vì vậy, công việc thực sự là tạo ra một lệnh duy nhất chạy toàn bộ bộ API của bạn và thoát với mã không bằng 0 khi có gì đó thất bại. Đó là lúc thiết kế kiểm thử trở nên quan trọng.

Bước 1: Thiết kế và xác thực các bài kiểm thử API của bạn trong Apidog

Trước khi bất cứ điều gì chạm đến TeamCity, bạn cần có các bài kiểm thử thực sự chạy tự động. Một bài kiểm thử cần bạn phải xem xét thủ công phản hồi JSON là vô dụng trong CI. Mọi kiểm tra phải là một xác nhận mà máy có thể đánh giá: mã trạng thái là 200, trường id là một số, phản hồi trả về trong vòng 800 ms.

Apidog được xây dựng chính xác cho điều này. Bạn thiết kế yêu cầu, sau đó đính kèm các xác nhận API tự động xác thực phản hồi; mã trạng thái, sự tuân thủ Schema JSON, các giá trị trường cụ thể, thời gian phản hồi. Bạn có thể xâu chuỗi các yêu cầu thành một kịch bản để đầu ra của một cuộc gọi đăng nhập cung cấp token cho yêu cầu tiếp theo. Không yêu cầu viết script cho các trường hợp phổ biến, và có đầy đủ khả năng viết script khi bạn cần.

Một kịch bản thực tế cho API thương mại điện tử có thể trông như thế này:

1. POST /auth/login với thông tin đăng nhập thử nghiệm, xác nhận 200, trích xuất token bearer vào một biến.
2. GET /products?category=books với token đó, xác nhận 200, xác nhận phản hồi là một mảng, xác nhận mỗi mục có price lớn hơn 0.
3. POST /cart/items với ID sản phẩm, xác nhận 201, xác nhận tổng giỏ hàng trả về khớp với giá mặt hàng.
4. GET /cart, xác nhận số lượng mặt hàng là 1.

Mỗi bước có các xác nhận tự động pass hoặc fail. Chạy kịch bản bên trong Apidog trước và xác nhận nó chuyển sang màu xanh lá cây so với môi trường staging của bạn. Nếu nó không thể pass khi bạn chạy thủ công, nó sẽ không bao giờ pass trong CI. Nhóm các kịch bản liên quan vào một bộ kiểm thử để bạn có thể chạy toàn bộ bằng một lệnh duy nhất thay vì từng kịch bản một.

Lợi ích của việc xây dựng các bài kiểm thử theo cách này là các kịch bản bạn sử dụng để gỡ lỗi thủ công trở thành bộ kiểm thử CI của bạn. Bạn không cần duy trì hai bộ kiểm thử song song; một trong GUI để khám phá, một trong mã để tự động hóa. Đó là một nguồn chân lý duy nhất. Nếu bạn đang chuyển từ một framework ưu tiên mã như REST Assured, đây là phần tiết kiệm thời gian nhất: bạn ngừng viết và viết lại mã boilerplate yêu cầu/xác nhận cho mỗi endpoint.

Tải Apidog nếu bạn muốn làm theo. Nó miễn phí để bắt đầu, và CLI là một phần của cùng bộ công cụ.

Bước 2: Chạy Apidog CLI cục bộ trước

Không bao giờ gỡ lỗi một lệnh mới lần đầu tiên bên trong CI. Vòng lặp phản hồi trong máy chủ CI rất khắc nghiệt; bạn push, chờ tác nhân, đọc log, sửa một ký tự, push lại. Hãy chứng minh lệnh hoạt động trên máy của bạn, sau đó sao chép phiên bản hoạt động đó vào TeamCity.

Apidog CLI chạy trên Node.js, vì vậy hãy cài đặt nó toàn cầu bằng npm:

npm install -g apidog-cli

Xác nhận nó đã được cài đặt:

apidog --version

Bây giờ hãy chạy kịch bản kiểm thử của bạn. CLI có thể chạy một kịch bản hoặc bộ kiểm thử trực tiếp từ dự án Apidog của bạn bằng cách tham chiếu ID của nó, được xác thực bằng mã thông báo truy cập, hoặc từ một tệp đã xuất cục bộ. Cách tiếp cận trực tuyến giữ cho các bài kiểm thử của bạn là nguồn chân lý duy nhất; bất cứ điều gì nhóm của bạn chỉnh sửa trong Apidog đều là thứ chạy trong CI, không có bước xuất nào có thể bị quên.

Tạo mã thông báo truy cập từ cài đặt tài khoản Apidog của bạn, sau đó chạy:

apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -e "$APIDOG_ENV_ID" \
 -r cli,html,junit

Một vài điều cần lưu ý ở đây:

• --access-token xác thực lần chạy. Truyền nó trực tiếp như thế này, hoặc đăng nhập một lần bằng apidog login --with-token.
• -e chọn môi trường để chạy; staging, production-readonly, bất cứ điều gì bạn đã định nghĩa trong Apidog. Bạn chỉ các bài kiểm thử tương tự đến các URL cơ sở khác nhau bằng cách thay đổi ID này.
• -r chọn các trình báo cáo. cli in đầu ra dễ đọc cho con người ra console, html tạo ra một báo cáo bạn có thể duyệt, và báo cáo định dạng JUnit là thứ cho phép TeamCity phân tích và hiển thị kết quả kiểm thử cá nhân.

Khi quá trình chạy hoàn tất, CLI thoát 0 nếu mọi thứ vượt qua và khác 0 nếu bất kỳ xác nhận nào thất bại. Mã thoát đó là toàn bộ trò chơi trong CI: mã thoát khác 0 cho TeamCity biết để đánh dấu bản build là thất bại.

Đối với các bài kiểm thử cần chạy trên nhiều đầu vào, CLI hỗ trợ chạy dựa trên dữ liệu (data-driven runs). Chỉ nó vào một tệp CSV hoặc JSON và nó sẽ lặp lại kịch bản một lần cho mỗi hàng:

apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -d test-data/checkout-cases.csv \
 -r cli,junit

Đây là cách bạn kiểm thử hàng trăm ID sản phẩm hoặc một bảng các payload không hợp lệ mà không cần viết hàng trăm kịch bản. Mỗi hàng trở thành một lần lặp riêng với kết quả pass/fail riêng.

Khi bạn thấy đầu ra màu xanh lá cây cục bộ, bạn đã có một lệnh đáng tin cậy. Sao chép nó. Chính xác lệnh đó sẽ được đưa vào TeamCity.

Bước 3: Kết nối TeamCity với kho lưu trữ của bạn

Bây giờ hãy chuyển sang TeamCity. Mục tiêu của bước này là cung cấp cho TeamCity một dự án, chỉ nó vào mã của bạn và cho phép nó kích hoạt các bản build trên mỗi lần push.

Nếu bạn đang chạy TeamCity lần đầu tiên, cách đơn giản nhất là sử dụng Docker image chính thức. Nó sẽ cung cấp cho bạn một máy chủ đang hoạt động trong vài phút:

docker run -d --name teamcity-server \
 -v ~/teamcity/datadir:/data/teamcity_server/datadir \
 -v ~/teamcity/logs:/opt/teamcity/logs \
 -p 8111:8111 \
 jetbrains/teamcity-server

Mở http://localhost:8111, hoàn tất thiết lập lần chạy đầu tiên (chọn cơ sở dữ liệu, tài khoản quản trị), và bạn sẽ đến bảng điều khiển. Các thiết lập sản xuất sử dụng cơ sở dữ liệu bên ngoài phù hợp và các tác nhân build chuyên dụng, nhưng để theo dõi hướng dẫn này, tác nhân đi kèm là đủ.

Tạo dự án:

1. Vào Administration và chọn Create project.
2. Chọn From a repository URL và dán đường dẫn Git remote của bạn (HTTPS hoặc SSH).
3. Thêm thông tin xác thực nếu kho lưu trữ là riêng tư; một deploy key hoặc personal access token.
4. TeamCity quét kho lưu trữ và phải tự động phát hiện các bước build. Bạn có thể để nó làm điều đó, nhưng đối với các bài kiểm thử API, việc tự cấu hình bước trong phần tiếp theo sẽ rõ ràng hơn.

TeamCity tạo một VCS root (kết nối của nó với kho lưu trữ của bạn) và một cấu hình build (tập hợp các bước chạy). Với VCS root đã có, hãy thiết lập trigger để các bản build tự động kích hoạt:

1. Mở cấu hình build của bạn và vào Triggers.
2. Thêm một VCS Trigger.
3. Giữ nguyên quy tắc mặc định để mọi thay đổi đối với nhánh được theo dõi sẽ đưa một bản build vào hàng đợi.

Từ đây, mỗi lần push vào kho lưu trữ của bạn sẽ bắt đầu một bản build. Hiện tại bản build đó không làm gì hữu ích; bước tiếp theo sẽ cung cấp cho nó lệnh kiểm thử API.

Bước 4: Thêm Apidog CLI làm bước build

Đây là phần cốt lõi của thiết lập. Bạn đang thêm một bước build cài đặt CLI trên tác nhân và chạy bộ kiểm thử của bạn.

Trong cấu hình build của bạn, mở Build Steps và thêm một bước mới loại Command Line. Chọn Custom script và dán:

#!/bin/bash
set -e

# Cài đặt Apidog CLI trên tác nhân build
npm install -g apidog-cli

# Chạy bộ kiểm thử API và xuất báo cáo JUnit cho TeamCity
apidog run \
 --access-token "%env.APIDOG_ACCESS_TOKEN%" \
 -e "%env.APIDOG_ENV_ID%" \
 -r cli,junit \
 --out-dir reports

Đó là lệnh tương tự mà bạn đã thử nghiệm cục bộ, với hai thay đổi cho CI. Thứ nhất, set -e làm cho script bị hủy bỏ khi có bất kỳ lỗi nào. Thứ hai, các bí mật được tham chiếu dưới dạng tham số TeamCity (%env.APIDOG_ACCESS_TOKEN%) thay vì được mã hóa cứng; bạn sẽ định nghĩa chúng tiếp theo.

Nếu tác nhân build của bạn chưa có Node.js, hãy cài đặt nó sớm hơn trong chuỗi hoặc sử dụng một ảnh tác nhân bao gồm nó. Các ảnh Docker tác nhân TeamCity chính thức và hầu hết các pool tác nhân đám mây đều có Node.js. Bạn cũng có thể chạy toàn bộ bước bên trong một container Node bằng cách đặt bước chạy trong một ảnh Docker như node:20.

Một chi tiết đáng chú ý: CLI phải chạy sau khi API của bạn đã được triển khai và có thể truy cập được. Nếu TeamCity đang kiểm thử một dịch vụ vừa được triển khai lên staging, hãy làm cho bản build kiểm thử phụ thuộc vào bản build triển khai bằng cách sử dụng Snapshot Dependency hoặc Build Chain. Điều đó đảm bảo rằng các bài kiểm thử luôn gọi phiên bản API mà commit này đã tạo ra, không bao giờ là phiên bản trước đó.

Bước 5: Lưu trữ bí mật dưới dạng tham số TeamCity

Mã truy cập của bạn là một thông tin xác thực. Nó không thuộc về tập lệnh build, kho lưu trữ của bạn hoặc nhật ký build. TeamCity có một nơi hạng nhất cho điều này.

1. Trong cấu hình build của bạn (hoặc dự án gốc, để chia sẻ giữa các cấu hình), mở Parameters.
2. Thêm một tham số mới có tên env.APIDOG_ACCESS_TOKEN.
3. Đặt Spec của nó là Password. Điều này ẩn giá trị trong giao diện người dùng và xóa nó khỏi nhật ký build.
4. Dán mã truy cập Apidog của bạn làm giá trị.
5. Thêm env.APIDOG_ENV_ID theo cách tương tự với ID môi trường của bạn (cái này không phải là bí mật, nhưng giữ nó làm tham số cho phép bạn thay đổi môi trường mà không cần chỉnh sửa tập lệnh).

Việc định nghĩa các tham số này ở cấp độ dự án thay vì cấp độ cấu hình build có nghĩa là mọi bản build kiểm thử API trong dự án đó đều kế thừa chúng. Thay đổi token một lần, và mọi pipeline sẽ nhận giá trị mới.

Tham số mật khẩu là sự khác biệt giữa một token sống an toàn trong TeamCity và một token bị rò rỉ vào một tệp nhật ký mà cả nhóm có thể đọc được. Hãy coi nó như bạn coi mật khẩu cơ sở dữ liệu.

Bước 6: Hiển thị kết quả kiểm thử trong tab Tests của TeamCity

Một bản build chuyển sang màu đỏ cho bạn biết có điều gì đó đã bị hỏng. Một bản build cho biết bài kiểm thử nào bị hỏng sẽ cho bạn biết nơi cần tìm. Đó là những gì báo cáo JUnit mang lại cho bạn.

Trình báo cáo -r junit ghi một tệp XML ở định dạng JUnit, định dạng kết quả kiểm thử CI tiêu chuẩn mà TeamCity đọc nguyên bản. Bạn chỉ TeamCity vào tệp đó bằng tính năng Build feature XML Report Processing.

1. Mở Build Features trong cấu hình build của bạn.
2. Thêm XML report processing.
3. Đặt loại báo cáo là Ant JUnit.
4. Đặt đường dẫn theo dõi để khớp với đầu ra của bạn, ví dụ reports/*.xml.

Chạy một bản build. Mở nó và nhấp vào tab Tests. Bạn sẽ thấy mỗi kịch bản và xác nhận là một bài kiểm thử riêng lẻ với trạng thái pass/fail và thời gian. Khi một bài kiểm thử thất bại, TeamCity hiển thị thông báo lỗi trực tiếp, liên kết nó với commit đã gây ra nó và theo dõi nó trong các bản build sau này. Nếu cùng một bài kiểm thử thất bại hai lần liên tiếp, TeamCity có thể đánh dấu nó là một lỗi mới thay vì một lỗi không ổn định.

Đây là lợi ích của việc chọn đầu ra JUnit trước đó. Nếu không có nó, một lỗi là một bản build màu đỏ và một bức tường văn bản console. Với nó, bạn có một lịch sử kiểm thử có cấu trúc, có thể tìm kiếm, biến "bản build API bị hỏng" thành "xác nhận tổng giỏ hàng bắt đầu thất bại trong commit a3f9c2."

Bước 7: Làm lỗi build và chặn việc hợp nhất

Mục đích của tất cả điều này là để ngăn chặn mã xấu được hợp nhất. Hai điều làm cho điều đó xảy ra.

Thứ nhất, mã thoát. Vì Apidog CLI thoát với mã khác không khi có bất kỳ xác nhận nào thất bại và tập lệnh của bạn sử dụng set -e, một bài kiểm thử thất bại sẽ làm cho bước build thất bại, từ đó làm cho build thất bại. Bạn không cần cấu hình thêm bất cứ điều gì; một bài kiểm thử API đỏ là một build đỏ theo mặc định.

Thứ hai, cổng hợp nhất. Nếu nhóm của bạn làm việc với pull requests hoặc merge requests, hãy cấu hình nhà cung cấp Git của bạn (GitHub, GitLab, Bitbucket) để yêu cầu kiểm tra TeamCity phải pass trước khi hợp nhất. TeamCity báo cáo trạng thái build của nó trở lại commit thông qua tính năng build Commit Status Publisher:

1. Thêm tính năng build Commit Status Publisher.
2. Chọn nhà cung cấp dịch vụ lưu trữ VCS của bạn.
3. Thêm mã truy cập để TeamCity có thể đăng trạng thái.

Bây giờ, một người đóng góp mở PR, TeamCity chạy bộ API trên nhánh của họ, và nút hợp nhất vẫn bị vô hiệu hóa cho đến khi bộ kiểm thử chuyển sang màu xanh. Kịch bản đổi tên trường từ đầu hướng dẫn này sẽ bị phát hiện ở đây, trên nhánh, trước khi nó đến được nhánh chính.

Một quy trình đầy đủ thực tế

Ghép các mảnh lại với nhau, một cấu hình build hoạt động cho một quy trình kiểm thử API trông như thế này:

• VCS root trỏ vào kho lưu trữ của bạn, với VCS trigger trên nhánh chính và các nhánh PR.
• Bước build 1: triển khai dịch vụ đến môi trường staging (hoặc khởi động nó trong một Docker container trên tác nhân).
• Bước build 2: lệnh Apidog CLI từ Bước 4, chạy bộ kiểm thử của bạn trên môi trường staging đó.
• Tính năng build: XML report processing đọc reports/*.xml.
• Tính năng build: Commit Status Publisher báo cáo trạng thái trở lại nhà cung cấp Git của bạn.
• Tham số: env.APIDOG_ACCESS_TOKEN (mật khẩu) và env.APIDOG_ENV_ID.

Đối với các nhóm giữ toàn bộ cấu hình CI trong kiểm soát phiên bản, TeamCity hỗ trợ định nghĩa tất cả những điều này trong một Kotlin DSL (.teamcity/settings.kts) được commit vào kho lưu trữ, thay vì nhấp qua giao diện người dùng. Bước build vẫn là lệnh apidog run giống nhau; DSL chỉ mô tả cấu hình dưới dạng mã để nó được xem xét và phiên bản hóa cùng với mọi thứ khác.

Bạn có thể chạy bộ kiểm thử không chỉ trên mỗi lần push. Thêm một Schedule Trigger để chạy toàn bộ bộ kiểm thử hồi quy (regression suite) mỗi đêm trên môi trường staging, để bạn bắt được những thay đổi xảy ra giữa các commit; một phụ thuộc của bên thứ ba đã thay đổi, một cơ sở dữ liệu bị rơi vào trạng thái lạ. Chạy API hàng đêm là một loại bảo hiểm rẻ tiền và chúng giúp commit đầu tiên vào buổi sáng không phải thừa hưởng môi trường bị hỏng của ngày hôm qua.

So sánh với các nền tảng CI khác

Mẫu hình ở đây có thể di chuyển được. Lệnh chạy các bài kiểm thử của bạn (apidog run với mã thông báo truy cập và trình báo cáo JUnit) là giống hệt nhau bất kể máy chủ CI nào gọi nó. Chỉ có phần bao bọc thay đổi:

• Trong GitHub Actions, bạn sẽ đặt cùng lệnh đó vào một bước workflow YAML. Chúng tôi đề cập đến điều đó trong Cách tự động hóa kiểm thử API trong GitHub Actions.
• Trong Jenkins, nó nằm trong một stage của Jenkinsfile. Xem Cách tích hợp kiểm thử tự động Apidog với Jenkins cho CI/CD.
• Chiến lược rộng hơn trên bất kỳ nền tảng nào đều có trong Cách tự động hóa kiểm thử API trong CI/CD.

Nếu bạn vẫn đang chọn một máy chủ CI, so sánh các công cụ CI/CD tốt nhất của chúng tôi sẽ phân tích vị trí của TeamCity so với các lựa chọn thay thế. Điểm mạnh của TeamCity là chuỗi build, lịch sử kiểm thử chi tiết và Kotlin DSL; đây là lựa chọn mạnh mẽ cho các nhóm đã ở trong hệ sinh thái JetBrains hoặc đang chạy các quy trình đa giai đoạn phức tạp.

Các vấn đề thường gặp và cách khắc phục

Bản build không tìm thấy lệnh apidog. Node.js không được cài đặt trên tác nhân, hoặc thư mục bin npm toàn cục không có trong PATH của tác nhân. Thêm một bước cài đặt Node sớm hơn trong chuỗi, hoặc chạy bước đó bên trong một Docker image node:20.

Các bài kiểm thử pass cục bộ nhưng thất bại trong CI với lỗi kết nối. Tác nhân build không thể tiếp cận API của bạn. Một URL staging có thể phân giải trên VPN máy tính xách tay của bạn có thể không thể tiếp cận được từ một tác nhân đám mây. Xác nhận môi trường bạn chọn với -e trỏ đến một máy chủ mà tác nhân thực sự có thể truy cập, và rằng bất kỳ quyền truy cập mạng hoặc quy tắc tường lửa cần thiết nào đều bao gồm tác nhân.

Xác thực thất bại chỉ trong CI. Kiểm tra xem tham số mật khẩu có được viết chính xác như trong script tham chiếu đến nó và token chưa hết hạn. Một lỗi phổ biến là định nghĩa APIDOG_ACCESS_TOKEN trong khi script đọc %env.APIDOG_ACCESS_TOKEN%; tiền tố env. rất quan trọng.

Các bài kiểm thử không ổn định; chúng pass và fail trên cùng một mã. Thường là vấn đề về thời gian hoặc thứ tự dữ liệu. Sử dụng các xác nhận thời gian phản hồi của Apidog để làm nổi bật các endpoint chậm, và làm cho mỗi kịch bản thiết lập và dọn dẹp dữ liệu của riêng nó để các lần chạy không phụ thuộc vào phần còn lại của nhau. Tính năng tắt tạm thời và điều tra của TeamCity cho phép bạn cách ly một bài kiểm thử không ổn định để nó ngừng chặn mọi người trong khi bạn khắc phục nguyên nhân gốc rễ.

Tab Tests trống rỗng mặc dù build đã chạy. Đường dẫn xử lý báo cáo XML không khớp với nơi CLI đã ghi báo cáo. Xác nhận --out-dir trong lệnh và đường dẫn giám sát trong tính năng build trỏ đến cùng một vị trí.

Câu hỏi thường gặp

Tôi có cần viết mã để chạy kiểm thử API trong TeamCity không? Không. Bạn thiết kế các bài kiểm thử một cách trực quan trong Apidog với các xác nhận, và "mã" duy nhất trong TeamCity là lệnh apidog run một dòng trong bước build Command Line. Đó là sự khác biệt chính so với cách tiếp cận ưu tiên mã như REST Assured, nơi mỗi endpoint cần mã yêu cầu và xác nhận được viết thủ công.

Tôi có thể chạy các bài kiểm thử trên các môi trường khác nhau không? Có. Định nghĩa từng môi trường (staging, pre-prod, production-readonly) trong Apidog, sau đó chuyển đổi môi trường nào chạy trong CI bằng cách thay đổi tham số ID môi trường -e. Các bài kiểm thử tương tự sẽ chạy trên bất kỳ môi trường nào bằng cách trỏ đến một URL cơ sở khác.

Làm cách nào để giữ mã truy cập của tôi an toàn trong TeamCity? Lưu trữ nó dưới dạng tham số TeamCity với đặc tả Password. Điều đó sẽ ẩn nó trong giao diện người dùng và xóa nó khỏi nhật ký build. Không bao giờ mã hóa cứng nó trong tập lệnh build hoặc commit nó vào kho lưu trữ của bạn. Định nghĩa nó ở cấp độ dự án để bạn có thể xoay vòng nó một lần cho tất cả các quy trình.

Một bài kiểm thử API thất bại có thực sự chặn việc hợp nhất không? Có, với hai phần được thiết lập. Apidog CLI thoát với mã khác không khi có bất kỳ xác nhận nào thất bại, điều này làm cho bản build TeamCity thất bại. Thêm tính năng build Commit Status Publisher và yêu cầu kiểm tra trong các quy tắc bảo vệ nhánh của nhà cung cấp Git của bạn, và nút hợp nhất sẽ bị vô hiệu hóa cho đến khi bộ kiểm thử pass.

Sự khác biệt giữa việc chạy kiểm thử trực tuyến so với từ một tệp đã xuất là gì? Chạy trực tuyến bằng ID dự án và mã truy cập có nghĩa là các bài kiểm thử của bạn trong Apidog là nguồn chân lý duy nhất; bất cứ điều gì nhóm chỉnh sửa là thứ chạy trong CI. Chạy từ một tệp đã xuất ghim các bài kiểm thử vào một phiên bản đã commit trong kho lưu trữ của bạn. Trực tuyến đơn giản hơn để giữ đồng bộ; đã xuất cung cấp cho bạn các bài kiểm thử đi kèm với mã. Hầu hết các nhóm bắt đầu trực tuyến.

Tôi có thể chạy toàn bộ bộ kiểm thử hồi quy theo lịch trình thay vì trên mỗi lần push không? Có. Thêm Schedule Trigger vào cấu hình build để chạy hàng đêm (hoặc hàng giờ) trên môi trường staging. Nhiều nhóm chạy một bộ smoke test nhanh trên mỗi lần push và toàn bộ bộ kiểm thử hồi quy theo lịch trình hàng đêm, để phản hồi nhanh và phạm vi bao phủ sâu không cạnh tranh nhau về thời gian.

Tổng kết

Một quy trình TeamCity chạy các bài kiểm thử API của bạn trên mỗi commit thay đổi quy tắc kinh tế của một endpoint bị hỏng. Thay vì khách hàng tìm thấy lỗi, bản build tìm thấy nó; trên nhánh, trước khi hợp nhất, với xác nhận thất bại chính xác và commit gây ra nó được trình bày rõ ràng trong tab Tests.

Thiết lập này gói gọn trong ba phần chuyển động: các bài kiểm thử với các xác nhận thực tế mà bạn xây dựng trong Apidog, một lệnh apidog run duy nhất chạy chúng không cần giao diện và thoát với mã khác không khi thất bại, và một cấu hình build TeamCity chạy lệnh đó, phân tích kết quả JUnit và báo cáo trạng thái trở lại nhà cung cấp Git của bạn. Khi đã thiết lập, bạn duy trì phạm vi bao phủ bằng cách thêm các kịch bản trong Apidog, chứ không phải bằng cách chỉnh sửa mã quy trình.

Tải Apidog để thiết kế bộ kiểm thử đầu tiên của bạn, chứng minh lệnh CLI hoạt động cục bộ, sau đó đưa nó vào TeamCity. Từ thời điểm đó trở đi, API của bạn sẽ được kiểm thử theo cùng một cách cho mỗi commit, cho dù ai đó có nhớ chạy nó hay không.