Why Use This
This skill provides specialized capabilities for vudovn's codebase.
Use Cases
- Developing new features in the vudovn repository
- Refactoring existing code to follow vudovn standards
- Understanding and working with vudovn's codebase structure
Install Guide
2 steps - 1
- 2
Install inside Ananke
Click Install Skill, paste the link below, then press Install.
https://github.com/vudovn/antigravity-kit/tree/main/.agent/skills/webapp-testing
Skill Snapshot
Auto scan of skill assets. Informational only.
Valid SKILL.md
Checks against SKILL.md specification
Source & Community
Updated At Jan 20, 2026, 08:09 AM
Skill Stats
SKILL.md 188 Lines
Total Files 2
Total Size 3.7 KB
License MIT
---
name: webapp-testing
description: Web application testing principles. E2E, Playwright, deep audit strategies.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
---
# Web App Testing
> Discover and test everything. Leave no route untested.
## 🔧 Runtime Scripts
**Execute these for automated browser testing:**
| Script | Purpose | Usage |
|--------|---------|-------|
| `scripts/playwright_runner.py` | Basic browser test | `python scripts/playwright_runner.py https://example.com` |
| | With screenshot | `python scripts/playwright_runner.py <url> --screenshot` |
| | Accessibility check | `python scripts/playwright_runner.py <url> --a11y` |
**Requires:** `pip install playwright && playwright install chromium`
---
## 1. Deep Audit Approach
### Discovery First
| Target | How to Find |
|--------|-------------|
| Routes | Scan app/, pages/, router files |
| API endpoints | Grep for HTTP methods |
| Components | Find component directories |
| Features | Read documentation |
### Systematic Testing
1. **Map** - List all routes/APIs
2. **Scan** - Verify they respond
3. **Test** - Cover critical paths
---
## 2. Testing Pyramid for Web
```
/\ E2E (Few)
/ \ Critical user flows
/----\
/ \ Integration (Some)
/--------\ API, data flow
/ \
/------------\ Component (Many)
Individual UI pieces
```
---
## 3. E2E Test Principles
### What to Test
| Priority | Tests |
|----------|-------|
| 1 | Happy path user flows |
| 2 | Authentication flows |
| 3 | Critical business actions |
| 4 | Error handling |
### E2E Best Practices
| Practice | Why |
|----------|-----|
| Use data-testid | Stable selectors |
| Wait for elements | Avoid flaky tests |
| Clean state | Independent tests |
| Avoid implementation details | Test user behavior |
---
## 4. Playwright Principles
### Core Concepts
| Concept | Use |
|---------|-----|
| Page Object Model | Encapsulate page logic |
| Fixtures | Reusable test setup |
| Assertions | Built-in auto-wait |
| Trace Viewer | Debug failures |
### Configuration
| Setting | Recommendation |
|---------|----------------|
| Retries | 2 on CI |
| Trace | on-first-retry |
| Screenshots | on-failure |
| Video | retain-on-failure |
---
## 5. Visual Testing
### When to Use
| Scenario | Value |
|----------|-------|
| Design system | High |
| Marketing pages | High |
| Component library | Medium |
| Dynamic content | Lower |
### Strategy
- Baseline screenshots
- Compare on changes
- Review visual diffs
- Update intentional changes
---
## 6. API Testing Principles
### Coverage Areas
| Area | Tests |
|------|-------|
| Status codes | 200, 400, 404, 500 |
| Response shape | Matches schema |
| Error messages | User-friendly |
| Edge cases | Empty, large, special chars |
---
## 7. Test Organization
### File Structure
```
tests/
├── e2e/ # Full user flows
├── integration/ # API, data
├── component/ # UI units
└── fixtures/ # Shared data
```
### Naming Convention
| Pattern | Example |
|---------|---------|
| Feature-based | `login.spec.ts` |
| Descriptive | `user-can-checkout.spec.ts` |
---
## 8. CI Integration
### Pipeline Steps
1. Install dependencies
2. Install browsers
3. Run tests
4. Upload artifacts (traces, screenshots)
### Parallelization
| Strategy | Use |
|----------|-----|
| Per file | Playwright default |
| Sharding | Large suites |
| Workers | Multiple browsers |
---
## 9. Anti-Patterns
| ❌ Don't | ✅ Do |
|----------|-------|
| Test implementation | Test behavior |
| Hardcode waits | Use auto-wait |
| Skip cleanup | Isolate tests |
| Ignore flaky tests | Fix root cause |
---
> **Remember:** E2E tests are expensive. Use them for critical paths only.