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; Schemathesis + RESTler fuzzing; and an API chaos runner that injects latency / error rates during test runs.
Choosing a tool
Functional API testing (request in, assertions on status + body) is what this plugin covers. Two neighbor disciplines are easy to confuse with it: contract testing ("will the consumer still work when the provider deploys?") is Pact's job - see the qa-contract-testing plugin; load testing ("does it hold up at 500 rps?") is k6 / JMeter - see qa-load-testing. A functional suite run in a loop is not a load test.
Read down the "What you can observe" column and stop at the first row that matches your project:
| What you can observe | Your goal | Start with | Why this one |
|---|---|---|---|
pom.xml or build.gradle, tests already run under JUnit, engineers write and read the tests | Functional | restassured-testing | Tests are plain Java in the existing src/test/java tree, so the build, CI, and IDE already work. No new runtime. |
| JVM project, but testers or analysts who do not write Java must read or edit the tests | Functional | karate-testing | Tests are .feature files in Gherkin shape and are directly executable: no step-definition glue code to maintain. |
package.json, or the team already has a Postman collection JSON in the repo | Functional | postman-collections | Author in the GUI, run the exact same collection headlessly in CI with newman run. |
| An OpenAPI (2.0/3.x) or GraphQL schema is committed or served, and you want broad coverage without hand-writing per-endpoint tests | Spec conformance | schemathesis-fuzzing | Generates inputs from your schema; coverage grows automatically as the schema grows. |
An OpenAPI spec and the API is a resource lifecycle (POST creates, GET reads, DELETE removes), and you want security and reliability bugs | Stateful fuzzing | restler-fuzzing | Stateful REST API fuzzing; infers request dependencies to reach deeper service states. |
| The suite is green and you want to know how it behaves under network faults | Resilience | api-chaos-runner | Runs the functional suite under Toxiproxy-injected latency / timeouts / resets. |
Tie-breakers when two rows match: match the service's own language; a schema flips the answer only for coverage goals (most teams end up with a small hand-written suite plus Schemathesis, not one instead of the other); fuzzers are additive, never first - get a functional suite green before fuzzing; if nothing matches, use Postman + newman (needs only Node, works against any HTTP API, portable collection JSON).
Universal traps regardless of tool: asserting only on the status code (assert at least one body field too), order-dependent tests sharing server state (create per-test data with unique keys), hardcoded environment URLs and secrets (every tool has an environment mechanism - use it from the first test), and pointing any of it at production (fuzzers generate requests designed to be unusual - target local or staging).
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 | 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-author | Authors one API test artifact per endpoint + scenario in the chosen tool's idiomatic shape (Postman request, REST Assured Java test, Karate feature, Schemathesis test, or RESTler grammar). Picks the tool from the decision table above when not specified. |
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.
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
Repairs Postman and Newman runs in CI - a reporter that never writes the HTML file the pipeline expects, a nightly job that fires requests as fast as it can until a partner API rate-limits it, or a report with one row per request when the collection asserts a dozen things between them. 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 drives data-driven runs from JSON / CSV iteration files. Use when HTTP API tests are authored in Postman and need to run, pace themselves, and report correctly in CI.
restassured-testing
Strengthens and speeds up JVM API test suites - assertions so loose that an empty `200 OK` passed for three days, a 220-test suite spending fourteen minutes mostly waiting on sequential HTTP calls, or endpoints exercised through a hand-rolled JDK HTTP client with JSON parsed by hand. Authors REST Assured (Java) tests in the given().when().then() BDD-style DSL: status code and JSON / XML path assertions, authentication (Basic, OAuth2, API key), Maven / Gradle dependencies, JUnit 5 execution, and Surefire / JaCoCo reports for CI gating. Use when the project is on the JVM and its API tests miss real assertions, run too slowly, or are written by hand.
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.