jovd83

Rest Assured Skill

This repository provides a RestAssured-skill designed for AI coding assistants

jovd83 0 Updated 2mo ago

Resources

10
GitHub

Install

npx skillscat add jovd83/restassured-skill

Install via the SkillsCat registry.

SKILL.md

Rest Assured Skill

1. Start

  1. Classify the request before writing files.
  2. Use bootstrap/SKILL.md for new modules, missing dependencies, or missing test structure.
  3. Use orchestrator/SKILL.md when the user asks for generic testing help and has not chosen planning, implementation, documentation, or reporting.
  4. Use core/SKILL.md for Rest Assured implementation, assertions, auth, specs, DTOs, JUnit 5 structure, and execution.
  5. Use virtualization/SKILL.md for WireMock, fault injection, or downstream API simulation.
  6. Use analysis/requirements/SKILL.md for epics, stories, acceptance criteria, or prose requirements.
  7. Use analysis/contracts/SKILL.md for OpenAPI or Swagger.
  8. Use analysis/contracts-soap/SKILL.md for WSDL or SOAP contract analysis.
  9. Use coverage_plan/generation/SKILL.md to turn approved requirements and contracts into scenarios.
  10. Use coverage_plan/review/SKILL.md to request user approval before implementation.
  11. Use documentation/ skills for TDD, BDD, plain-text, mixed or absent narrative documentation, documentation sync, code docs, root-cause writeups, traceability reports, coverage-gap reports, OpenAPI change-impact reports, assertion-strength reports, bundled report regeneration, contract-mismatch notes, session-state tracking, or handover.
  12. Use ci/SKILL.md for GitHub Actions, GitLab, Docker, tagging, parallelization, and artifacts.
  13. Use C:\projects\skills\test-artifact-export-skill\SKILL.md for narrative test-case formatting and export artifacts.
  14. Use mappers/, reporters/, and reporting/stakeholder/ for execution reporting and stakeholder workflows.
  15. Prefer canonical narrative docs under docs/tests/<feature>/; keep docs/testing/ for reports, indexes, and generated human-readable portals.

2. Golden Rules

  1. Inspect pom.xml, build.gradle, build.gradle.kts, and CI files before choosing dependency versions.
  2. Default to JUnit 5 for new work unless the repository already standardizes on TestNG.
  3. Prefer reusable RequestSpecification and ResponseSpecification objects over duplicated given() chains.
  4. Assert status, headers, body semantics, and error payloads; do not stop at status code checks.
  5. Create test data per test or per fixture; do not rely on execution order.
  6. Log on failure and redact tokens, cookies, API keys, and personal data.
  7. Use Testcontainers for dependencies owned by the system under test.
  8. Use WireMock only for third-party or unstable dependencies that must be simulated.
  9. Merge business requirements with API contracts before finalizing scenario coverage.
  10. When a live service is available, prefer runtime-observed assertions over contract assumptions and record any mismatch explicitly.
  11. Refuse placeholder tests, fake assertions, and undocumented assumptions.
  12. Keep one canonical narrative artifact per executable scenario whenever the repo uses TDD or plain-text cases.
  13. Use aggregate files under docs/testing/ only as indexes or report entry points when scenario-level files exist.

3. Read Only What You Need

  1. Read capability-map.md when you need a routing shortcut.
  2. Read version-compatibility.md when Java or Rest Assured version selection is unclear.
  3. Read family-conventions.md when naming, directory, or tagging conventions are needed.
  4. Read release-checklist.md when preparing the skill family for publishing.

4. Examples

  1. Input: Create Rest Assured smoke tests for the order API from this OpenAPI file.
    Output: Use analysis/contracts, then coverage_plan/generation, then core.
  2. Input: Set up a Maven JUnit 5 Rest Assured module in this repo.
    Output: Use bootstrap.
  3. Input: Document the approved API scenarios as BDD and export them for Xray.
    Output: Use C:\projects\skills\test-artifact-export-skill\SKILL.md.
  4. Input: The suite fails in CI only when the payment provider is down.
    Output: Use virtualization, ci, and documentation/root_cause.
  5. Input: Create a resumable checkpoint so another agent can continue tomorrow.
    Output: Use documentation/session-state.
  6. Input: The live API does not match OpenAPI. Document the gaps.
    Output: Use documentation/contract-mismatches.
  7. Input: Show which tests cover each endpoint and method.
    Output: Use documentation/traceability-report.
  8. Input: Show the biggest API coverage gaps.
    Output: Use documentation/coverage-gap-report.
  9. Input: Compare these two API contracts and tell me which tests are affected.
    Output: Use documentation/openapi-change-impact-report.
  10. Input: Tell me which Rest Assured tests are weak or only assert status codes.
    Output: Use documentation/assertion-strength-report.
  11. Input: Refresh the full human-readable reporting set for this API module.
    Output: Use documentation/report-bundle.
  12. Input: Check whether the TDD, BDD, or plain-text case files drifted away from the tests.
    Output: Use documentation/documentation-sync.
  13. Input: Document the approved owner API scenarios as TDD.
    Output: Use C:\projects\skills\test-artifact-export-skill\SKILL.md and write one canonical file per scenario under docs/tests/owner/.

5. Troubleshooting

  1. Problem: The user asks for generic API testing help with no scope.
    Fix: Use orchestrator/SKILL.md and force the user goal into planning, implementation, execution, documentation, or reporting.
  2. Problem: The repository mixes Java 11 and Java 17 modules.
    Fix: Read references/version-compatibility.md and choose per-module compatibility instead of forcing one global version.
  3. Problem: The request mixes user stories and OpenAPI input.
    Fix: Run both analysis skills and merge the result in coverage_plan/generation.
  4. Problem: The live service contradicts the contract.
    Fix: Keep the tests aligned with observed runtime behavior and create a mismatch artifact with documentation/contract-mismatches.
  5. Problem: The skill family needs a publish-readiness check before release.
    Fix: Run python scripts/validate_skill_family.py.
  6. Problem: The mapping report points to aggregate documentation files instead of scenario-level artifacts.
    Fix: Move canonical narrative docs into docs/tests/<feature>/ and update traceability to point to the scenario files, not only the index.