build-scenario-tests

Solid

Inspect an unfamiliar repository, turn a focused Markdown behavior scenario into a deterministic test in the repository's native test stack, run it, and preserve traceability between intent and code. Use when asked to add scenario tests, compile acceptance criteria or Given/When/Then Markdown into executable tests, reproduce a user-visible regression, or convert a narrow workflow specification into stable web, API, CLI, desktop, or mobile interaction coverage. Do not use for broad exploratory journeys or agent-judged smoke tests.

Testing & QA 196 stars 7 forks Updated 3 weeks ago MIT

Install

View on GitHub

Quality Score: 85/100

Stars 20%
76
Recency 20%
90
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Build Scenario Tests Compile one small behavior contract into deterministic, repository-native test code. Understand the host project before choosing a harness, command, fixture, selector, or assertion. ## Operating contract - Treat repository instructions and existing tests as authoritative. - Keep each scenario focused on one behavior and one reason to fail. - Compile into the test stack the repository already uses. Add a dependency only when no suitable harness exists and the user accepts the tradeoff. - Make setup, inputs, actions, and expected results deterministic. - Prefer public behavior over implementation details. Assert what a user or external caller can observe. - Keep the Markdown scenario beside the test or in the repository's established specification directory. Record the mapping in both artifacts. - Never weaken an assertion merely to make a test pass. ## Workflow ### 1. Pass the repository-understanding gate Read the nearest `AGENTS.md` or equivalent instructions, product README, contribution guide, manifests, test configuration, and the smallest relevant product documentation. Use repository search to find the implementation entry point, neighboring tests, fixtures, stable selectors, and validation commands. Trace the relevant action from its public entry point through the state boundary to the observable result. Do not read the entire tree without a reason. Before editing, be able to state: ```text product surface: behavior source: relevant...

Details

Author
tamdogood
Repository
tamdogood/builder-essential-skills
Created
2 months ago
Last Updated
3 weeks ago
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Testing & QA Listed

implement-scenarios

Implements automated tests for existing Gherkin scenarios (`.feature` files) the BDD way — outside-in and client-first: classify each scenario's best testing strategy, write the test that binds to it, watch it fail for the right reason, then drive the UI/API and domain code until it passes. Use whenever the user has `.feature` files and wants to automate, implement, wire up, or "make pass" their scenarios; turn Gherkin/BDD/SpecFlow/Reqnroll/Cucumber specs into real xUnit/NUnit/Vitest/Jest/pytest/Playwright tests; build a feature test-first (TDD) from acceptance criteria; decide which scenarios belong in unit vs service (Testcontainers) vs end-to-end tests; or keep a traceability link between scenarios and the tests that verify them — even when they don't say "BDD" or "TDD". This is BDD's automation step, the one that runs after define-behavior writes the Gherkin and review-feature-suite audits it. Do not use it to author or refine the Gherkin itself (that is define-behavior) or to reconcile a suite of feature

0 Updated today
azborgonovo
Testing & QA Listed

writing-tests

Use when adding or changing a test in this repo — the tier map (where a new guard goes), the scenario-first rule, the no-prose-presence-guards and no-mirror-harnesses rules, the mjs-seam grep exception, and the mutation-catalog anchoring obligations.

2 Updated today
manoldonev
Testing & QA Listed

testing-scenarios

Generate a test pass from a PRD, user story, or acceptance criteria — happy paths, boundaries, error handling, permissions, and state-transition cases, each with steps and expected results, traced back to the source spec. Use when the user asks to test a PRD or feature, wants test cases, test scenarios, a QA checklist, edge cases, or asks how to verify something before release.

2 Updated 1 weeks ago
strategysoul