Tdd

Skill jovd83/Cypress-skill/documentation/test_cases/tdd

End-to-end Cypress skill pack for planning, authoring, debugging, documenting, and operationalizing test automation.

Install

npx -y skills add jovd83/Cypress-skill --skill tdd

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

Legacy Cypress-specific alias for TDD-style case documentation. Prefer the standalone `test-artifact-export-skill` skill for formatting approved test cases or building export-ready artifacts, and use this only when Cypress-local conventions must be preserved explicitly.

SKILL.md

3.6 KB, as published. Nobody here has run it

Telemetry & Logging

[!IMPORTANT] All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: ./log-dispatch.cmd --skill <skill_name> --intent <intent> --model <model_name> --reason <reason> (or ./log-dispatch.sh on Linux)

Documenting Test Cases: TDD format

Use this skill when the team wants formal, traceable test-case documents rather than lightweight notes.

1. Storage & Organization

Store TDD-style test cases in a stable, feature-oriented structure:

Root directory: docs/tests/
Subfolders: one folder per feature, epic, or domain area
Files: one markdown file per scenario group, story, or coherent test slice

Example structure:

docs/tests/
|-- auth/
|   |-- registration.md
|   `-- login.md
`-- collections/
    `-- create-collection.md

2. Granular Traceability

Link the document to the automation at the test level whenever possible, not just the file level.

Required format: file_name @ file_path#test_name
Example: auth-settings.cy.ts @ cypress/e2e/regression/auth-settings.cy.ts#AUTH-US02: User Login

If the test does not exist yet, keep the intended script field explicit and mark the document as design-stage output.

3. Structure & Fields

Produce a markdown document with these fields:

title: informative, unique, and requirement-aware
description: concise purpose of the scenario
test_suite: feature, epic, or suite grouping
Covered requirement: the requirement, story, or acceptance-criteria reference
preconditions: system state required before execution, formatted as a lettered list
steps: markdown table with Step, Action, and Expected result
execution_type: usually Automated, but can be explicit when mixed or manual
design_status: Draft, Ready, or Obsolete
test_engineer: engineer or agent identifier
test_level: priority or level using the team convention
jira: relevant Jira or tracker reference when available
Test script: granular implementation link or planned destination

4. Example Template

title: [AUTH-US02] MSS: User Login
description: Validates end-to-end UI behavior for "User Login" in epic "Authentication & Settings".
test_suite: Authentication & Settings
Covered requirement: AUTH-US02
preconditions:
A) Test database is seeded with fixtures.
B) Application is running.
steps:
| Step | Action | Expected result |
|---|---|---|
| 1 | Navigate to login page | Page renders |
| 2 | Enter credentials | Login successful |
execution_type: Automated
design_status: Ready
test_engineer: Codex
test_level: 1
jira: AUTH-102
Test script: auth-settings.cy.ts @ cypress/e2e/regression/auth-settings.cy.ts#AUTH-US02: User Login