CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/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.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable overview skill with a clear decision workflow, validation checkpoints, and clean one-level-deep progressive disclosure. The main weakness is conciseness: several passages explain concepts Claude already knows and could be trimmed without losing clarity.

Suggestions

Tighten the 'Functional vs contract vs load' section to the distinctions needed for tool selection rather than re-deriving what each discipline is; Claude already knows contract and load testing.

Cut transitional/opinion prose such as 'A healthy project usually has all three eventually. Start with functional.' and the 'Three consequences shape everything below' paragraph, which restates what the later assertions already imply.

Consider moving the per-tool environment/secrets table into the reference file so the spine stays a lean overview + decision table + default first-run path.

DimensionReasoningScore

Conciseness

Mostly efficient and dense, but includes explanatory prose Claude does not need (the 'Three consequences' paragraph, re-deriving what contract and load testing are, lines like 'A healthy project usually has all three eventually. Start with functional.'), so it sits at 'mostly efficient but could be tightened' rather than 'every token earns its place'.

2 / 3

Actionability

Provides copy-paste executable code (Postman pm.test snippet), concrete commands ('npm install -g newman', 'newman run collection.json -e environment.json -r cli,junit'), a decision table that yields a single tool, and explicit 'Success looks like' / 'Verify it can fail' steps, matching the 'fully executable code/commands; copy-paste ready' anchor.

3 / 3

Workflow Clarity

Clear sequenced workflow (read the decision table -> pick a row -> follow the first-runnable path -> point baseUrl at local/staging -> verify it can fail) with an explicit validation checkpoint ('change 200 to 201, rerun, confirm a non-zero exit') and ordered trap fixes, matching the 'clear sequence with explicit validation steps' anchor.

3 / 3

Progressive Disclosure

SKILL.md is an overview that keeps the default Postman path inline and clearly signals a single one-level-deep reference ('First-run commands ... are in references/first-run-commands.md'), which exists and is well-organized per tool; the 'Going deeper' section points to sibling skills rather than nesting references, matching the 'clear overview with well-signaled one-level-deep references' anchor.

3 / 3

Total

11

/

12

Passed

Description

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, specific, third-person description that clearly states what the skill does and gives explicit 'Use when' triggers with natural phrasing. Its only weakness is verbosity — it packs a great deal into one field — but no rubric dimension is violated.

DimensionReasoningScore

Specificity

Lists multiple concrete actions in third person ('Teaches API testing from zero', 'picks one tool from observable project facts', 'gives install and first-run commands', 'the traps that bite first: asserting only on HTTP status, order-dependent tests...hardcoded environment URLs and secrets'), matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

Explicitly answers both what ('Teaches API testing from zero: what functional API testing covers...') and when ('Use when an HTTP API needs automated tests and no tool has been chosen, or when an inherited suite only checks status codes'), matching the 'clearly answers both what AND when with explicit triggers' anchor.

3 / 3

Trigger Term Quality

Natural user phrasing is well covered ('API testing', 'HTTP API needs automated tests', 'no tool has been chosen', 'inherited suite only checks status codes'), matching the 'good coverage of natural terms users would say' anchor rather than the 'some relevant keywords but missing common variations' level.

3 / 3

Distinctiveness Conflict Risk

Occupies a clear niche (API test tool selection/overview) with distinct triggers unlikely to fire for other skills, matching the 'clear niche with distinct triggers; unlikely to conflict' anchor rather than the 'could still overlap' level.

3 / 3

Total

12

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents