qa-api-testing
API testing: 8 skills (api-chaos-runner, api-testing-getting-started, karate-testing, postman-collections, restassured-testing, restler-fuzzing, schemathesis-fuzzing, tavern-testing) and 2 agents (api-test-author, api-test-tool-selector).
Install this plugin
/plugin install qa-api-testing@testland-qaPart of role bundles: qa-role-automation-engineer, qa-role-sdet, qa-role-backend
qa-api-testing
API testing across Postman/Newman, RestAssured, Karate, Tavern; Schemathesis + RESTler fuzzing; and an API chaos runner that injects latency / error rates during test runs.
Components
| Type | Name | Description |
|---|---|---|
| Skill | postman-collections | Author Postman collections; run via Newman CLI; configure JUnit / JSON reporters for CI gating. |
| Skill | restassured-testing | Author REST Assured (Java) given/when/then tests; status + JSON/XML path + OAuth2/Basic/API-key auth; run via JUnit 5 + Maven Failsafe. |
| Skill | karate-testing | Author Karate .feature files; use the match keyword with fuzzy validators; run via JUnit 5 + Maven Surefire. |
| Skill | tavern-testing | YAML-based API tests (test_*.tavern.yaml) auto-discovered by pytest; built-in matchers + variable saving across stages. |
| Skill | schemathesis-fuzzing | Property-based API fuzzing from OpenAPI / GraphQL schema; canonical checks (status / schema / content-type / headers / 5xx); CLI + pytest integration. |
| Skill | restler-fuzzing | Stateful API fuzzing with Microsoft RESTler: 4-stage workflow (compile → test → fuzz-lean → fuzz); bug buckets + replay logs. |
| Skill | api-chaos-runner | Run API tests under Toxiproxy-injected latency / timeout / bandwidth / reset_peer; produce a resilience matrix. |
| Agent | api-test-tool-selector | Reads target API project markers (*.openapi.yaml / *.proto / *.graphql / Postman collection / language stack) plus testing goal (functional vs fuzzing vs chaos) and recommends one tool from the 7 skills above with rationale and the matching SKILL.md to read next. |
| Agent | api-test-author | Authors one API test artifact per endpoint + scenario in the chosen tool's idiomatic shape (Postman request, REST Assured Java test, Karate feature, Tavern YAML stage, Schemathesis test, RESTler grammar, or Chaos Runner scenario). Sibling of qa-mobile/mobile-test-author. |
| Skill | api-testing-overview | Junior on-ramp: what API testing is, which tool to pick, and a first request + assertion. |
Install
/plugin marketplace add testland/qa
/plugin install qa-api-testing@testland-qaSkills
api-chaos-runner
Runs the project's existing API tests under injected network chaos - latency, timeouts, dropped connections, bandwidth caps, packet loss - via Toxiproxy (notes on Pumba / Gremlin / LitmusChaos). Builds a per-scenario chaos matrix and reports which assertions break under which conditions, verifying resilience patterns (retry, circuit-breaker, timeout, fallback). Unlike schemathesis-fuzzing and restler-fuzzing, which generate new tests from a schema, this drives your EXISTING example-based suite.
api-testing-overview
Teaches API testing from zero: what functional API testing covers, how it differs from contract testing and load testing, and a decision table that picks one tool from observable project facts (language and build file, whether an OpenAPI or GraphQL schema exists, functional vs spec-conformance fuzzing vs stateful security fuzzing, whether non-engineers read the tests). Names the real options (Postman with newman, REST Assured, Karate, Tavern, Schemathesis, RESTler), gives install and first-run commands with what a passing run looks like, and the traps that bite first: asserting only on HTTP status, order-dependent tests sharing server state, and hardcoded environment URLs and secrets. Use when an HTTP API needs automated tests and no tool has been chosen, or when an inherited suite only checks status codes.
karate-testing
Authors Karate `.feature` files using its Gherkin-flavored DSL for HTTP API tests, leverages the `match` keyword with fuzzy validators (#number / #string / #regex / contains / arrays), runs the suite via JUnit 5 plus Maven Surefire, and produces JUnit XML for CI gating. Use when the project is on the JVM and prefers a feature-file authoring flow over Java-DSL fluent chains; for those fluent chains use restassured-testing, for the same YAML-style flow on a Python/pytest stack use tavern-testing.
postman-collections
Authors Postman collections (requests + tests + variables + environments), runs them headless via the Newman CLI, configures reporters (cli / json / junit / html) for CI artifact upload, and uses iteration data files (JSON / CSV) for data-driven runs. Use when the project ships HTTP API tests authored in Postman and the team needs CI execution alongside or instead of the Postman desktop runner.
restassured-testing
Authors REST Assured (Java) API tests using the given().when().then() BDD-style DSL - status code + JSON/XML path assertions + authentication (Basic, OAuth2, API key). Configures Maven / Gradle dependencies, runs via JUnit 5, and emits Surefire / JaCoCo reports for CI gating. Use when the project is on the JVM and wants type-safe API tests in the app's own language; for a Gherkin feature-file flow on the same JVM use karate-testing, for YAML tests on the pytest stack use tavern-testing.
restler-fuzzing
Runs stateful REST API fuzzing using Microsoft's RESTler - infers producer-consumer dependencies from an OpenAPI spec, drives sequences of requests (POST → GET → DELETE chains), and reports 5xx errors, resource leaks, and hierarchy violations. Wraps the canonical 4-stage workflow (compile → test → fuzz-lean → fuzz). Use when the API is stateful (resources are created, queried, modified, deleted) and Schemathesis's stateless fuzzing is missing the multi-step bugs.
schemathesis-fuzzing
Generates property-based API tests automatically from an OpenAPI 2/3.x or GraphQL schema using Schemathesis, runs them via the `schemathesis run` CLI or as a pytest decorator, configures the canonical checks (status_code_conformance, response_schema_conformance, content_type_conformance, response_headers_conformance, not_a_server_error), and gates CI on schema-conformance failures plus 5xx detection. Use when the project ships an OpenAPI or GraphQL schema and the team wants schema-driven coverage that scales as the API evolves.
tavern-testing
Authors Tavern API tests as YAML files (`test_*.tavern.yaml`) with `test_name` + `stages` + `request` + `response` blocks, runs them through the Tavern pytest plugin (auto-discovered), and gates CI on the resulting JUnit XML. Covers RESTful, MQTT, and gRPC variants. Use when the project runs on pytest and prefers YAML over a Python- or Java-DSL; on the JVM use karate-testing or restassured-testing instead, and for schema-driven property-based fuzzing on the same pytest stack use schemathesis-fuzzing.
Agents
api-test-author
Action-taking agent that authors ONE API test file per behavior spec - detects tool via api-test-tool-selector (or accepts an override), then emits a Postman collection request, REST Assured test, Karate feature, Tavern YAML stage, Schemathesis spec-driven test, or RESTler grammar using the chosen tool's idiomatic patterns. Distinct from qa-contract-testing/contract-test-scaffolder (consumer/provider Pact tests). Sibling of qa-mobile/mobile-test-author and the per-language unit-test authors in qa-unit-tests-{net,js,jvm,python,go-rust}. Use when adding one API test (functional, not contract or load) to an existing test project.
api-test-tool-selector
Action-taking agent that reads a target API project (`*.openapi.yaml`, `*.proto`, `*.graphql`, `pact.json`, `package.json`, `pom.xml`, `requirements.txt`, Postman collection JSON) and recommends one API test tool - Postman, REST Assured, Karate, Tavern, Schemathesis, RESTler, or API Chaos Runner - plus rationale and the preloaded SKILL.md to read next. Distinct from `qa-contract-testing/contract-test-scaffolder` (consumer/provider contract tests against a Pact). Use when starting a new API test project and the team has not yet committed to a tool.