Initial commit: antigravity-claudekit
This commit is contained in:
111
skills/ck-web-testing/SKILL.md
Normal file
111
skills/ck-web-testing/SKILL.md
Normal file
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: ck-web-testing
|
||||
description: Web testing with Playwright, Vitest, k6. Use for E2E, unit, integration, load, security, visual regression, accessibility testing, test automation setup, flakiness mitigation, Core Web Vitals.
|
||||
---
|
||||
|
||||
# ck-web-testing
|
||||
|
||||
Comprehensive web testing across all layers: unit, integration, E2E, load, security, visual regression, accessibility. Embeds the `tester` agent role.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Running test suites after feature implementation
|
||||
- Setting up test infrastructure from scratch
|
||||
- Diagnosing flaky or failing tests
|
||||
- Coverage analysis and gap identification
|
||||
- Performance and Core Web Vitals testing
|
||||
- Accessibility audits (WCAG)
|
||||
- Security testing (OWASP Top 10)
|
||||
- Before any merge to main
|
||||
|
||||
## Don't Use When
|
||||
|
||||
- Writing production code — implement first, then test
|
||||
- Debugging a specific code bug (not test issue) — use `ck-debug`
|
||||
- Load testing infrastructure setup — use `ck-devops`
|
||||
|
||||
## Quick Start Commands
|
||||
|
||||
```bash
|
||||
npx vitest run # Unit tests
|
||||
npx playwright test # E2E tests
|
||||
npx playwright test --ui # E2E with interactive UI
|
||||
k6 run load-test.js # Load tests
|
||||
npx @axe-core/cli https://example.com # Accessibility
|
||||
npx lighthouse https://example.com # Performance
|
||||
```
|
||||
|
||||
## Testing Strategy Models
|
||||
|
||||
| Model | Structure | Best For |
|
||||
|-------|-----------|----------|
|
||||
| Pyramid | Unit 70% > Integration 20% > E2E 10% | Monoliths |
|
||||
| Trophy | Integration-heavy | Modern SPAs |
|
||||
| Honeycomb | Contract-centric | Microservices |
|
||||
|
||||
## Working Process
|
||||
|
||||
1. Identify testing scope based on recent changes or requirements
|
||||
2. Run type check / analyze commands to catch syntax errors first
|
||||
3. Run appropriate test suites using project-specific commands
|
||||
4. Analyze results, paying close attention to failures
|
||||
5. Generate and review coverage reports
|
||||
6. Validate build processes if relevant
|
||||
7. Create comprehensive summary report
|
||||
|
||||
## Test Execution Commands
|
||||
|
||||
- JavaScript/TypeScript: `npm test`, `yarn test`, `pnpm test`, `bun test`
|
||||
- Coverage: `npm run test:coverage`
|
||||
- Python: `pytest` or `python -m unittest`
|
||||
- Go: `go test ./...`
|
||||
- Rust: `cargo test`
|
||||
|
||||
## CI/CD Integration
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- run: npm run test:unit # Gate 1: fast fail
|
||||
- run: npm run test:e2e # Gate 2: after unit pass
|
||||
- run: npm run test:a11y # Accessibility
|
||||
- run: npx lhci autorun # Performance
|
||||
```
|
||||
|
||||
## Reference Areas
|
||||
|
||||
- **Unit & Integration**: Vitest, browser mode, AAA pattern
|
||||
- **E2E**: Playwright fixtures, sharding, selector strategies
|
||||
- **Component Testing**: React/Vue/Angular patterns
|
||||
- **Test Data**: Factories, fixtures, seeding strategies
|
||||
- **Database Testing**: Testcontainers, transactions
|
||||
- **Cross-Browser**: Browser/device matrix
|
||||
- **Mobile**: Touch gestures, swipe, orientation testing
|
||||
- **Performance**: LCP/CLS/INP, Lighthouse CI
|
||||
- **Visual Regression**: Screenshot comparison
|
||||
- **Flakiness**: Stability strategies, retry logic
|
||||
- **Accessibility**: WCAG, axe-core
|
||||
- **Security**: OWASP Top 10 checklist
|
||||
- **API**: Supertest, GraphQL testing
|
||||
- **Load**: k6 patterns
|
||||
|
||||
## Output Report Format
|
||||
|
||||
- **Test Results Overview**: Total run, passed, failed, skipped
|
||||
- **Coverage Metrics**: Line, branch, function coverage percentages
|
||||
- **Failed Tests**: Detailed failures with error messages and stack traces
|
||||
- **Performance Metrics**: Execution time, slow tests identified
|
||||
- **Build Status**: Success/failure with warnings
|
||||
- **Critical Issues**: Blocking issues requiring immediate attention
|
||||
- **Recommendations**: Actionable tasks to improve quality
|
||||
- **Next Steps**: Prioritized list of testing improvements
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- All critical paths have test coverage
|
||||
- Both happy path and error scenarios validated
|
||||
- Tests are isolated (no interdependencies)
|
||||
- Tests are deterministic and reproducible
|
||||
- Test data cleaned up after execution
|
||||
- Never ignore failing tests just to pass the build
|
||||
|
||||
**IMPORTANT:** Sacrifice grammar for concision. List unresolved questions at end if any.
|
||||
Reference in New Issue
Block a user