Bmad qa generate e2e tests
Skill mannnrachman/pi-bmad/skills/bmad-qa-generate-e2e-tests
BMad Method v6.10.0 packaged for Pi Coding Agent. Global & project-local install, portable defaults, project-scoped outputs, /bmad-init initializer. Retains bmad-investigate.
npx -y skills add mannnrachman/pi-bmad --skill bmad-qa-generate-e2e-testsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 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
Generate end to end automated tests for existing features. Use when the user says "create qa automated tests for [feature]"
SKILL.md
5.6 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
QA Generate E2E Tests Workflow
Goal: Generate automated API and E2E tests for implemented code.
Your Role: You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the bmad-code-review skill for that).
Conventions
- Bare paths (e.g.
checklist.md) resolve from the skill root. {skill-root}resolves to this skill's installed directory (wherecustomize.tomllives).{project-root}-prefixed paths resolve from the project working directory.{skill-name}resolves to the skill directory's basename.
On Activation
Step 1: Resolve the Workflow Block
Run: python3 {skill-root}/../../runtime/scripts/resolve_customization.py --skill {skill-root} --key workflow
If the script fails, resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
{skill-root}/customize.toml— defaults{project-root}/_bmad/custom/{skill-name}.toml— team overrides{project-root}/_bmad/custom/{skill-name}.user.toml— personal overrides
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.
Step 2: Execute Prepend Steps
Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.
Step 3: Load Persistent Facts
Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.
Step 4: Load Config
Load config from the merged output of python3 {skill-root}/../../runtime/scripts/resolve_config.py --project-root {project-root} --key core --key modules.bmm and resolve:
project_name,user_namecommunication_language,document_output_languageimplementation_artifactsdateas system-generated current datetime- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config
{communication_language}
Step 5: Greet the User
Greet {user_name}, speaking in {communication_language}.
Step 6: Execute Append Steps
Execute each entry in {workflow.activation_steps_append} in order.
Activation is complete. If activation_steps_prepend or activation_steps_append were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
Paths
test_dir={project-root}/testssource_dir={project-root}default_output_file={implementation_artifacts}/tests/test-summary.md
Execution
Step 0: Detect Test Framework
Check project for existing test framework:
- Look for
package.jsondependencies (playwright, jest, vitest, cypress, etc.) - Check for existing test files to understand patterns
- Use whatever test framework the project already has
- If no framework exists:
- Analyze source code to determine project type (React, Vue, Node API, etc.)
- Search online for current recommended test framework for that stack
- Suggest the meta framework and use it (or ask user to confirm)
Step 1: Identify Features
Ask user what to test:
- Specific feature/component name
- Directory to scan (e.g.,
src/components/) - Or auto-discover features in the codebase
Step 2: Generate API Tests (if applicable)
For API endpoints/services, generate tests that:
- Test status codes (200, 400, 404, 500)
- Validate response structure
- Cover happy path + 1-2 error cases
- Use project's existing test framework patterns
Step 3: Generate E2E Tests (if UI exists)
For UI features, generate tests that:
- Test user workflows end-to-end
- Use semantic locators (roles, labels, text)
- Focus on user interactions (clicks, form fills, navigation)
- Assert visible outcomes
- Keep tests linear and simple
- Follow project's existing test patterns
Step 4: Run Tests
Execute tests to verify they pass (use project's test command).
If failures occur, fix them immediately.
Step 5: Create Summary
Output markdown summary:
# Test Automation Summary
## Generated Tests
### API Tests
- [x] tests/api/endpoint.spec.ts - Endpoint validation
### E2E Tests
- [x] tests/e2e/feature.spec.ts - User workflow
## Coverage
- API endpoints: 5/10 covered
- UI features: 3/8 covered
## Next Steps
- Run tests in CI
- Add more edge cases as needed
Keep It Simple
Do:
- Use standard test framework APIs
- Focus on happy path + critical errors
- Write readable, maintainable tests
- Run tests to verify they pass
Avoid:
- Complex fixture composition
- Over-engineering
- Unnecessary abstractions
For Advanced Features:
If the project needs:
- Risk-based test strategy
- Test design planning
- Quality gates and NFR assessment
- Comprehensive coverage analysis
- Advanced testing patterns and utilities
Install Test Architect (TEA) module: https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/
Output
Save summary to: {default_output_file}
Done! Tests generated and verified. Validate against ./checklist.md.
On Complete
Run: python3 {skill-root}/../../runtime/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete
If the resolved workflow.on_complete is non-empty, follow it as the final terminal instruction before exiting.
Gives 0 of the 12 instructions most e2e browser skills give in ~1.3k tokens
Counted across 407 of the 410 authors here whose files we hold, read 2026-08-06
- use page object model patternin 35 of 407, across 25 files
- Snapshot to get element refsin 24 of 407, across 14 files
- keep tests independentin 23 of 407, across 18 files
- Interact using refs from the latest snapshotin 23 of 407, across 11 files
- clean up test data after each testin 21 of 407, across 15 files
- test user behavior not implementationin 20 of 407, across 14 files
- quarantine flaky tests explicitlyin 19 of 407, across 10 files
- wait for specific network conditionsin 18 of 407, across 8 files
- re-snapshot after navigation or dom changesin 17 of 407, across 10 files
- Detect running dev servers before writing test codein 17 of 407, across 7 files
- use web-first assertionsin 17 of 407, across 14 files
- capture screenshots or videos on test failurein 17 of 407, across 14 files
Said here and by no other author read
- resolve the workflow block on activation
- execute prepend and append activation steps in order
- speak output in the configured communication language
- generate api tests for endpoints
- generate e2e tests for ui features
- create a markdown test summary
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.