Use for testing HTTP endpoints directly using cross-platform API testing tools. Covers .http files (VS Code REST Client, JetBrains HTTP Client), Bruno collections, Postman/Newman, k6 for functional API verification, environment management, and CI integration patterns.
USE FOR: .http files, Bruno, Postman, Newman, REST Client, k6 API tests, HTTP endpoint testing, API collections, environment variables, API functional verification, HTTP request scripting, API test automation
DO NOT USE FOR: browser-based testing (use e2e-testing), contract verification between services (use contract-testing), load/stress testing at scale (use performance-testing)
Use for testing HTTP endpoints directly using cross-platform API testing tools. Covers .http files (VS Code REST Client, JetBrains HTTP Client), Bruno collections, Postman/Newman, k6 for functional API verification, environment management, and CI integration patterns.
USE FOR: .http files, Bruno, Postman, Newman, REST Client, k6 API tests, HTTP endpoint testing, API collections, environment variables, API functional verification, HTTP request scripting, API test automation
DO NOT USE FOR: browser-based testing (use e2e-testing), contract verification between services (use contract-testing), load/stress testing at scale (use performance-testing)
API testing verifies HTTP endpoints directly without a browser or UI layer. It validates request/response contracts, status codes, headers, payloads, authentication, and error handling at the transport level. API tests are faster than E2E tests and provide high confidence that your services behave correctly.
Cross-Platform Tools
Tool
Type
Strengths
.http files
VS Code REST Client / JetBrains HTTP Client
Version-controlled, inline in IDE, variable support
Bruno
Desktop + CLI
Git-friendly .bru collections, open source, no cloud sync required
Postman / Newman
Desktop + CLI
Rich GUI, team collaboration, extensive scripting, CI via Newman
k6
CLI (JavaScript)
Scripted API tests with checks and thresholds, doubles as load tool
// environments/development.bru
vars {
baseUrl: http://localhost:3000
authToken: dev-token-123
}
// environments/staging.bru
vars {
baseUrl: https://staging-api.example.com
authToken: staging-token-456
}
Bruno CLI Runner (CI Integration)
# Install Bruno CLI
npm install -g @usebruno/cli
# Run entire collection
bru run --env development
# Run specific folder
bru run collection/users --env staging
# Output JUnit report for CI
bru run --env staging --output results.xml --format junit
Postman / Newman
Collection Structure
Postman collections are JSON files containing organized API requests with folders, variables, and test scripts.
// Test response status and structure
pm.test("Status code is 200", () => {
pm.response.to.have.status(200);
});
pm.test("Response has required fields", () => {
const json = pm.response.json();
pm.expect(json).to.have.property("id");
pm.expect(json).to.have.property("name");
pm.expect(json).to.have.property("email");
});
pm.test("Response time is under 500ms", () => {
pm.expect(pm.response.responseTime).to.be.below(500);
});
// Store value for chaining
pm.environment.set("userId", pm.response.json().id);
Newman CLI Runner (CI Integration)
# Install Newman
npm install -g newman
# Run collection with environment
newman run collection.json \
--environment staging.postman_environment.json \
--reporters cli,junit \
--reporter-junit-export results.xml
# Run with iteration data
newman run collection.json \
--environment staging.postman_environment.json \
--iteration-data test-data.csv \
--iteration-count 5
# Fail on test errors (for CI gates)
newman run collection.json \
--environment staging.postman_environment.json \
--bail
k6 is typically associated with load testing, but it excels at functional API verification too. Its JavaScript-based scripting, built-in checks, and threshold system make it powerful for API testing in CI pipelines.
# Run with default settings
k6 run tests/api/users.k6.js
# Run with environment variables
k6 run tests/api/users.k6.js \
--env BASE_URL=https://staging-api.example.com \
--env AUTH_TOKEN=staging-token
# Output JSON results for CI
k6 run tests/api/users.k6.js --out json=results.json
# Output JUnit-compatible results (via xk6-junit extension or summary handler)
k6 run tests/api/users.k6.js --summary-export=summary.json
# .github/workflows/api-tests.ymljobs:api-tests:runs-on:ubuntu-lateststrategy:matrix:environment: [staging]
steps:-uses:actions/checkout@v4# Run .http file tests via httpyac (CLI runner for .http files)-run:npxhttpyactests/api/**/*.http--all--env${{matrix.environment}}# Run Bruno collection-run:npx@usebruno/cliruntests/api/bruno--env${{matrix.environment}}# Run k6 functional tests-run:|
k6 run tests/api/k6/users.k6.js \
--env BASE_URL=${{ secrets.STAGING_API_URL }} \
--env AUTH_TOKEN=${{ secrets.STAGING_AUTH_TOKEN }}
Best Practices
General
Version-control your API test collections alongside the code they test.
Use environment files to separate configuration from test logic.
Never commit secrets — use environment variables, .env files (gitignored), or CI secrets.
Assert on response structure, not just status codes — validate required fields, types, and values.
