test-master

Name: test-master
Author: pavel-molyanov

241stars75forks

How to install test-master?

pavel-molyanov/molyanov-ai-dev/test-master

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill test-master

Installs into the current project.

Summary

Testing methodology: when to write which tests, how to ensure test quality, test pyramid strategy. Use when: "напиши тесты", "как тестировать", "проанализируй тесты", "проверь качество тестов", "ревью тестов", "тестовая стратегия

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Test Master
4
5	Test Pyramid:
6	```
7	/\
8	/E2E\ <- Few (3-5 critical flows)
9	/------\
10	/Integr.\ <- Some (all endpoints + DB)
11	/----------\
12	/ Unit \ <- Many (all business logic)
13	/--------------\
14	/ Smoke \ <- Minimal (1-2 basic tests)
15	/------------------\
16	```
17
18	---
19
20	## When to Use Each Test Type
21
22	### Smoke Tests
23	Purpose: Verify basic project setup works.
24
25	Use for:
26	- Testing framework is configured
27	- Environment variables accessible
28	- Basic imports work
29	- Infrastructure is functional
30
31	Written: During infrastructure setup (once per project)
32
33	Setting up smoke tests? Read [smoke-tests.md](references/smoke-tests.md) — CI integration, example templates.
34
35	---
36
37	### Unit Tests
38	Purpose: Test business logic in isolation.
39
40	Use for:
41	- Functions with calculations, validations, transformations
42	- Decision-making logic (if/else, switch)
43	- Data processing and formatting
44	- Error handling logic
45
46	Written: By code-developer during each task (immediately after code)
47
48	Skip for: Simple getters/setters, one-line changes, trivial updates
49
50	Writing unit tests? Read [unit-tests.md](references/unit-tests.md) — patterns, mocking, examples.
51
52	---
53
54	### Integration Tests
55	Purpose: Test API endpoints, database, and external services.
56
57	Use for:
58	- All API endpoints (POST/PUT/DELETE especially)
59	- Database operations (create/update/delete)
60	- External service integrations (payments, email, webhooks)
61
62	Written: As separate task at end of feature (if defined in Tech Spec)
63
64	Rule: Every API endpoint and every DB write operation must have a corresponding integration test. Missing integration tests for these is a quality gap.
65
66	Writing integration tests? Read [integration-tests.md](references/integration-tests.md) — API testing, DB setup, fixtures.
67
68	---
69
70	### E2E Tests
71	Purpose: Test critical user journeys end-to-end.
72
73	Use for:
74	- Top 3-5 most critical user flows
75	- Large features (>5 tasks)
76	- Critical business processes (auth, payment, core features)
77
78	Written: After deploy to dev, before manual testing (if proposed/requested)
79
80	Writing E2E tests? Read [e2e-tests.md](references/e2e-tests.md) — Playwright/Cypress setup, page objects, CI.
81
82	---
83
84	## Decision Framework
85
86	### Should I write unit tests for this?
87
88	YES if:
89	- Function has business logic
90	- Function makes decisions
91	- Function transforms data
92	- Function handles errors
93	- Task specifies testing
94
95	NO if:
96	- Simple getter/setter
97	- One-line text change
98	- Trivial config update
99	- No code written (research/docs)
100
101	### Should I write integration tests?
102
103	YES if:
104	- Tech Spec specifies integration tests
105	- Feature has API endpoints
106	- Feature interacts with database
107	- Feature calls external services
108
109	NO if:
110	- Tech Spec says "None"
111	- Feature is purely client-side
112	- Already covered by E2E tests
113
114	### Should I write E2E tests?
115
116	YES if:
117	- Feature has >5 tasks
118	- Feature touches critical flows
119	- Feature has breaking changes
120	- User explicitly requests
121	- Tech Spec specifies E2E tests
122
123	NO if:
124	- Small feature (<3 tasks)
125	- Non-critical functionality
126	- Well covered by unit + integration tests
127	- Time/cost constraints
128
129	---
130
131	## Key Testing Principles
132
133	1. Write tests immediately - In the same session as the code, before moving on
134	2. Test behavior, not implementation - Focus on what, not how
135	3. Keep tests fast - Unit: milliseconds, Integration: seconds, E2E: minutes
136	4. Isolate tests - Mock external dependencies in unit tests
137	5. One concern per test - Each test validates one thing
138	6. Clear test names - Describe what's tested and expected outcome
139	7. Independent tests - Each test runs with its own setup, no shared state
140	8. Clean state - Always start with known database state
141	9. Tests must verify real behavior - Assert on actual results, not mock calls
142	10. Every test earns its place - Each test catches a specific failure no other test catches (see below)
143
144	---
145
146	## Redundant Testing Anti-pattern
147
148	Tests that duplicate coverage waste time and create maintenance burden.
149
150	Signs of redundant testing:
151	- Same behavior verified by both unit test and integration test with no added value
152	- E2E test that only checks what unit tests already cover
153	- Multiple test files testing the same function with same scenarios
154	- "Tests for completeness" that exist without protecting against real regressions
155
156	Rule: Each test must justify its existence — it catches a specific failure that no other test catches. If removing the test reduces zero confidence, it belongs nowhere.
157
158	---
159
160	## Test Quality Requirements
161
162	### What Makes a BAD Test
163
164	**Tests

People who liked this also viewed

6 picks

Type

test-master

241stars75forks

View on GitHub

How to install test-master?

pavel-molyanov/molyanov-ai-dev/test-master

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill test-master

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Test Master
4
5	Test Pyramid:
6	```
7	/\
8	/E2E\ <- Few (3-5 critical flows)
9	/------\
10	/Integr.\ <- Some (all endpoints + DB)
11	/----------\
12	/ Unit \ <- Many (all business logic)
13	/--------------\
14	/ Smoke \ <- Minimal (1-2 basic tests)
15	/------------------\
16	```
17
18	---
19
20	## When to Use Each Test Type
21
22	### Smoke Tests
23	Purpose: Verify basic project setup works.
24
25	Use for:
26	- Testing framework is configured
27	- Environment variables accessible
28	- Basic imports work
29	- Infrastructure is functional
30
31	Written: During infrastructure setup (once per project)
32
33	Setting up smoke tests? Read [smoke-tests.md](references/smoke-tests.md) — CI integration, example templates.
34
35	---
36
37	### Unit Tests
38	Purpose: Test business logic in isolation.
39
40	Use for:
41	- Functions with calculations, validations, transformations
42	- Decision-making logic (if/else, switch)
43	- Data processing and formatting
44	- Error handling logic
45
46	Written: By code-developer during each task (immediately after code)
47
48	Skip for: Simple getters/setters, one-line changes, trivial updates
49
50	Writing unit tests? Read [unit-tests.md](references/unit-tests.md) — patterns, mocking, examples.
51
52	---
53
54	### Integration Tests
55	Purpose: Test API endpoints, database, and external services.
56
57	Use for:
58	- All API endpoints (POST/PUT/DELETE especially)
59	- Database operations (create/update/delete)
60	- External service integrations (payments, email, webhooks)
61
62	Written: As separate task at end of feature (if defined in Tech Spec)
63
64	Rule: Every API endpoint and every DB write operation must have a corresponding integration test. Missing integration tests for these is a quality gap.
65
66	Writing integration tests? Read [integration-tests.md](references/integration-tests.md) — API testing, DB setup, fixtures.
67
68	---
69
70	### E2E Tests
71	Purpose: Test critical user journeys end-to-end.
72
73	Use for:
74	- Top 3-5 most critical user flows
75	- Large features (>5 tasks)
76	- Critical business processes (auth, payment, core features)
77
78	Written: After deploy to dev, before manual testing (if proposed/requested)
79
80	Writing E2E tests? Read [e2e-tests.md](references/e2e-tests.md) — Playwright/Cypress setup, page objects, CI.
81
82	---
83
84	## Decision Framework
85
86	### Should I write unit tests for this?
87
88	YES if:
89	- Function has business logic
90	- Function makes decisions
91	- Function transforms data
92	- Function handles errors
93	- Task specifies testing
94
95	NO if:
96	- Simple getter/setter
97	- One-line text change
98	- Trivial config update
99	- No code written (research/docs)
100
101	### Should I write integration tests?
102
103	YES if:
104	- Tech Spec specifies integration tests
105	- Feature has API endpoints
106	- Feature interacts with database
107	- Feature calls external services
108
109	NO if:
110	- Tech Spec says "None"
111	- Feature is purely client-side
112	- Already covered by E2E tests
113
114	### Should I write E2E tests?
115
116	YES if:
117	- Feature has >5 tasks
118	- Feature touches critical flows
119	- Feature has breaking changes
120	- User explicitly requests
121	- Tech Spec specifies E2E tests
122
123	NO if:
124	- Small feature (<3 tasks)
125	- Non-critical functionality
126	- Well covered by unit + integration tests
127	- Time/cost constraints
128
129	---
130
131	## Key Testing Principles
132
133	1. Write tests immediately - In the same session as the code, before moving on
134	2. Test behavior, not implementation - Focus on what, not how
135	3. Keep tests fast - Unit: milliseconds, Integration: seconds, E2E: minutes
136	4. Isolate tests - Mock external dependencies in unit tests
137	5. One concern per test - Each test validates one thing
138	6. Clear test names - Describe what's tested and expected outcome
139	7. Independent tests - Each test runs with its own setup, no shared state
140	8. Clean state - Always start with known database state
141	9. Tests must verify real behavior - Assert on actual results, not mock calls
142	10. Every test earns its place - Each test catches a specific failure no other test catches (see below)
143
144	---
145
146	## Redundant Testing Anti-pattern
147
148	Tests that duplicate coverage waste time and create maintenance burden.
149
150	Signs of redundant testing:
151	- Same behavior verified by both unit test and integration test with no added value
152	- E2E test that only checks what unit tests already cover
153	- Multiple test files testing the same function with same scenarios
154	- "Tests for completeness" that exist without protecting against real regressions
155
156	Rule: Each test must justify its existence — it catches a specific failure that no other test catches. If removing the test reduces zero confidence, it belongs nowhere.
157
158	---
159
160	## Test Quality Requirements
161
162	### What Makes a BAD Test
163
164	**Tests

People who liked this also viewed

6 picks

Type