agentsclimarketplace

Analysis

Skill jovd83/junit5-skill/analysis

JUnit 5 skill pack for creating, debugging, modernizing, documenting, and routing JVM test workflows.

Install
npx -y skills add jovd83/junit5-skill --skill analysis

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when Codex needs to derive JUnit 5 test scenarios from requirements, code, or existing test case definitions such as TDD, BDD, and plain-text specifications.

SKILL.md

3.8 KB, as published. Nobody here has run it

JUnit 5 Analysis

1. Inspect the Source Artifact

  1. Identify whether the source is a requirement, code path, defect report, TDD case, BDD scenario, or plain-text test definition.
  2. Extract the concrete behavior, inputs, outputs, side effects, preconditions, and edge cases.
  3. Keep explicit source traceability in the notes or output.
  4. Read references/source-artifact-types.md when the source format mixes prose, examples, and implementation detail.

2. Normalize the Behavior

  1. Convert narrative language into executable behaviors.
  2. Separate confirmed behavior from inferred coverage.
  3. Label inferred scenarios explicitly instead of presenting them as sourced facts.
  4. Use references/traceability-patterns.md when the user needs the result mapped back to story IDs, sections, or scenario names.

3. Choose the JUnit Shape

  1. Map small deterministic behavior to component tests.
  2. Map framework-backed behavior to slice, repository, or integration tests.
  3. Map service behavior to service-isolated or service-end-to-end tests.
  4. Use parameterized tests for scenario tables or repeated examples.
  5. Read references/source-mapping.md when mapping narrative artifacts into code.
  6. Read references/narrative-formats.md when converting TDD, BDD, or plain-text cases into a JUnit 5 structure.

4. Produce Actionable Output

  1. Output a scenario list, test-class plan, or directly implement the tests when requested.
  2. Preserve the source wording only when it improves traceability.
  3. Flag missing acceptance criteria or ambiguity instead of inventing rules.
  4. When asked to implement directly, keep inferred additions separated from source-backed cases in comments, notes, or test naming.

5. Examples

  1. Input: Turn these Gherkin scenarios into JUnit 5 tests. Output: A traceable list of parameterized and focused test cases aligned to the scenarios.
  2. Input: Derive tests from this service class. Output: A behavioral matrix covering happy path, edge cases, validation, and exception handling.
  3. Input: Convert this plain-text test checklist into executable scenarios. Output: A structured JUnit-oriented scenario plan with inferred gaps labeled separately.
  4. Input: Derive tests from this acceptance criteria section and preserve story traceability. Output: A scenario list or test plan that names the source item and marks any extra inferred coverage explicitly.

6. Troubleshooting

  1. Problem: The source artifact is ambiguous. Fix: Separate confirmed behavior from inferred coverage and call out the gap.
  2. Problem: The narrative cases are repetitive. Fix: Collapse them into parameterized inputs when the assertion logic is shared.
  3. Problem: The code path exposes too many internal branches. Fix: Group by externally visible behavior, not by every private implementation detail.
  4. Problem: The requirement and the code disagree. Fix: Report the disagreement explicitly and avoid silently treating one source as authoritative unless the task says to.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.