CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/wiremock-stubs

Authors WireMock stub mappings for HTTP service mocking - `stubFor` with verb/path/header matchers + `willReturn` response shaping, lifecycle via `WireMockServer` (start / stop) or JUnit `WireMockExtension`, request verification via `verify()`, and dynamic-port allocation for parallel tests. Use when the project is JVM-based and tests need to mock HTTP dependencies (third-party APIs, internal microservices) at the network layer.

76

Quality

95%

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

87%

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

A dense, code-forward reference skill with executable examples and clean one-level-deep progressive disclosure. Its only weak spot is workflow_clarity: guidance is topically organized rather than presented as an explicit validated step sequence.

Suggestions

Add a short numbered 'Authoring workflow' (1. add dependency, 2. configure @WireMockTest with dynamicPort, 3. stubFor the expected request, 4. exercise the SUT, 5. verify() the request was made, 6. on mismatch fix the stub/SUT and re-run) to make the validate->fix->retry loop explicit and lift workflow_clarity to 3.

Call out the stub-match-miss feedback signal inline near the verify() section (e.g., 'if verify() reports 0 matching requests, check the SUT's actual URL/headers against your matcher') rather than only in the CI note.

Replace the '3.x' Gradle placeholder with the same ${wiremock.version} pinning convention used in the Maven snippet so both install paths are consistent and unambiguous.

DimensionReasoningScore

Conciseness

Lean and code-forward with no lecturing on what WireMock or HTTP mocking is; version references are vague placeholders ('3.x', '${wiremock.version}') rather than dated specifics, so they do not penalize token efficiency.

3 / 3

Actionability

Provides fully executable JUnit 4 (@Rule) and JUnit 5 (@WireMockTest) stub examples, a verify() snippet, and a copy-paste CI workflow YAML—copy-paste ready with specific methods.

3 / 3

Workflow Clarity

Content is organized by topic (install, author, verify, CI) rather than as a sequenced workflow; the verify() validation checkpoint is present but implicit, not an explicit numbered feedback loop. Not a 3 because no explicit validate->fix->retry sequence is drawn, and not a 1 because the stub->exercise->verify cycle is clearly conveyed.

2 / 3

Progressive Disclosure

A concise overview links to one real one-level-deep reference (references/matchers-and-scenarios.md, verified to exist) for the matcher/scenario catalog, with a References section listing external docs and sibling skills—easy navigation, content appropriately split.

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 well-crafted description: third-person voice, concrete capabilities, an explicit 'Use when' trigger, and a clear niche distinct from sibling mocking skills. It scores at the top of every dimension.

DimensionReasoningScore

Specificity

Lists multiple concrete actions—"stubFor with verb/path/header matchers + willReturn response shaping", "request verification via verify()", "dynamic-port allocation"—matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

Explicitly answers both what (authors stub mappings, lifecycle, verification, dynamic ports) and when ("Use when the project is JVM-based and tests need to mock HTTP dependencies"), matching the explicit-trigger anchor.

3 / 3

Trigger Term Quality

Covers natural terms a user would say—"WireMock", "HTTP service mocking", "mock HTTP dependencies", "third-party APIs", "internal microservices", "parallel tests"—with good coverage of the domain's common phrasings.

3 / 3

Distinctiveness Conflict Risk

Clear JVM/WireMock niche with explicit boundary against the JS counterpart "msw-handlers", making conflict with other skills unlikely.

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