CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/spock-tests

Configures and runs Spock - Groovy-based JVM testing framework with given/when/then BDD blocks, where: data tables for parametrized tests, built-in mocking via Mock()/Stub()/Spy(), interaction-based testing (verify method calls in declarative DSL), implicit assertions in then: blocks. Use when working with Java/Kotlin codebases that benefit from Groovy DSL expressiveness, or maintaining existing Spock projects.

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 lean, highly actionable Spock tutorial with complete executable examples and clean section organization. Its main gap is workflow clarity: the install-to-CI sequence lacks an explicit verification checkpoint and error-recovery guidance.

Suggestions

Add an explicit validation checkpoint after Step 1, e.g. 'Run ./gradlew test to confirm Spock is wired up before writing specs.'

Include a short error-recovery note for common failures (e.g., missing groovy plugin, JUnit Platform not enabled) so the workflow has a fix-and-retry feedback loop.

Frame Step 2's first test as the install-verification gate so the setup workflow has an explicit pass/fail checkpoint.

DimensionReasoningScore

Conciseness

The body is code- and table-heavy with minimal prose and no concept padding (no 'what a framework is' exposition). It is not a 2 because there is no removable unnecessary explanation — the few editorial lines are brief and aid skill selection.

3 / 3

Actionability

Provides complete executable artifacts — a full build.gradle.kts, copy-paste Groovy specs covering data tables, Mock/Stub/Spy, cardinality, lifecycle, and a CI yaml snippet. It is not a 2 because the code is executable and complete rather than pseudocode with missing details.

3 / 3

Workflow Clarity

Steps 1-8 are clearly sequenced, but there is no explicit validation checkpoint (e.g., 'run ./gradlew test to confirm the install') and no error-recovery feedback loop. It is not a 3 because explicit validation steps / feedback loops are absent; it is not a 1 because the sequence itself is clear.

2 / 3

Progressive Disclosure

No bundle files exist; the single SKILL.md is well-organized into clear sections with one-level-deep external references ([sp-docs] -> spockframework.org) and sister-skill pointers. It is not a 2 because the inline content is coherent tutorial material rather than reference bloat that should be split, and references are clearly signaled.

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, third-person description that names concrete Spock capabilities, gives natural trigger terms, and pairs an explicit 'what' with an explicit 'Use when' clause. It is clearly distinguishable from sibling JVM testing skills.

DimensionReasoningScore

Specificity

Lists multiple concrete capabilities — 'data tables for parametrized tests', 'built-in mocking via Mock()/Stub()/Spy()', 'interaction-based testing', 'implicit assertions in then: blocks' — beyond a vague domain statement. It is not a 2 because the action set is comprehensive and specific, not just 'domain and some actions'.

3 / 3

Completeness

Explicitly states what it does ('Configures and runs Spock - Groovy-based JVM testing framework with ...') and when to use it ('Use when working with Java/Kotlin codebases ... or maintaining existing Spock projects'). It is not a 2 because the 'when' is explicit, not merely implied.

3 / 3

Trigger Term Quality

Covers natural terms users would say — 'Spock', 'Groovy', 'given/when/then BDD', 'data tables', 'mocking', 'Java/Kotlin', 'Spock projects'. It is not a 2 because common variations are present rather than missing.

3 / 3

Distinctiveness Conflict Risk

Targets a named framework (Spock) with distinct triggers and is scoped away from JUnit/Kotest niches, so it is unlikely to fire for the wrong skill. It is not a 2 because the niche is clearly distinct rather than only 'somewhat specific'.

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