qa-api-testing
API testing with Postman and Newman, REST Assured and Karate, plus Schemathesis and RESTler fuzzing and API tests run under injected network chaos. An authoring agent (api-test-author) picks the tool from observable project facts and writes one functional test per endpoint and scenario.
/plugin install qa-api-testing@testland-qaFirst time? Add the marketplace with /plugin marketplace add testland/qa
- Category
- Functional testing
- Version
v1.7.10- Contents
- 6 skills · 1 agent
Skills6
api-chaos-runnerUse when an existing API test suite should be rerun under network faults to prove retries, timeouts, circuit breakers and fallbacks work.skillkarate-testingUse when a JVM project wants HTTP API tests written as Karate .feature files instead of Java code: the Gherkin-style DSL, match with fuzzy validators, JUnit 5 and Maven runs, and JUnit XML for CI.skillpostman-collectionsRepairs 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.skillrestassured-testingUse whenever Java/JVM API tests need writing or fixing: loose assertions that let an empty 200 pass, slow sequential suites, or hand-rolled HTTP clients.skillrestler-fuzzingUse when a stateful REST API (resources created, read, changed and deleted in sequence) needs fuzzing that finds multi-step bugs stateless fuzzers miss.skillschemathesis-fuzzingUse whenever an API has an OpenAPI or GraphQL schema and needs tests generated from it: fuzzing every endpoint for 5xx errors and schema violations.skill
Agents1
About 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).