testing

Name: testing
Author: krzysztofsurdy

48installs1forks

How to install testing?

krzysztofsurdy/code-virtuoso/testing

$npx -y skills add krzysztofsurdy/code-virtuoso --skill testing

Installs into the current project.

Summary

Stack-agnostic testing principles, strategies, and patterns for building reliable test suites. Use when the user asks to design a test strategy, choose between unit/integration/e2e tests, apply TDD, fix flaky tests, improve test quality, use test doubles (mocks, stubs, fakes, spi

Files · 1

View on GitHub

SKILL.md

1	# Testing
2
3	A disciplined approach to verifying that software behaves correctly, remains stable under change, and communicates intent to future developers. Good tests act as living documentation, a safety net for refactoring, and a design feedback mechanism.
4
5	This skill covers universal testing concepts that apply regardless of language, framework, or tooling.
6
7	## When to Use
8
9	- Designing a test strategy for a new project or feature
10	- Deciding what level of testing (unit, integration, e2e) a piece of code needs
11	- Evaluating whether existing tests are providing value or creating drag
12	- Applying TDD to drive design decisions
13	- Debugging a flaky or brittle test suite
14	- Reviewing test code for quality and maintainability
15
16	## Testing Pyramid
17
18	The testing pyramid describes the ideal distribution of tests across three levels. More tests at the base, fewer at the top.
19
20	```
21	/ E2E \ Few, slow, expensive
22	/----------\
23	/ Integration \ Moderate number, moderate speed
24	/----------------\
25	/ Unit Tests \ Many, fast, cheap
26	/____________________\
27	```
28
29	### Unit Tests (Base)
30
31	- Test a single unit of behavior in isolation (a function, a method, a small class)
32	- No I/O, no database, no network, no file system
33	- Execute in milliseconds
34	- Should form the majority of your test suite (roughly 70%)
35	- Fast feedback loop enables rapid iteration
36
37	### Integration Tests (Middle)
38
39	- Test how multiple units collaborate, or how code interacts with external systems
40	- May involve a real database, message queue, or HTTP endpoint
41	- Execute in seconds
42	- Verify that wiring, configuration, and contracts between components work
43	- Roughly 20% of your test suite
44
45	### End-to-End Tests (Top)
46
47	- Test complete user journeys through the full system
48	- Interact with the application as a user would
49	- Slowest, most brittle, most expensive to maintain
50	- Reserve for critical business paths only
51	- Roughly 10% of your test suite
52
53	### The Ice Cream Cone Antipattern
54
55	The inverted pyramid: many e2e tests, few unit tests. Symptoms:
56
57	- Test suite takes hours to run
58	- Tests break constantly due to UI changes or timing issues
59	- Developers stop running tests locally
60	- Feedback loop is too slow to support continuous delivery
61
62	Fix: Identify what each e2e test is actually verifying. Push that verification down to the lowest possible level. Most business logic can be tested at the unit level.
63
64	## Test Design Principles
65
66	### Arrange-Act-Assert (AAA)
67
68	Every test should follow three distinct phases:
69
70	1. Arrange — set up the preconditions and inputs
71	2. Act — execute the behavior under test
72	3. Assert — verify the expected outcome
73
74	Keep each phase clearly separated. If Arrange dominates the test, extract a builder or factory. If Act requires multiple steps, you may be testing too much at once.
75
76	### One Assertion per Concept
77
78	A test should verify one logical concept. This does not mean literally one `assert` call — asserting multiple properties of a single result is fine. What matters is that the test fails for exactly one reason.
79
80	```
81	// Good: one concept — "completed order has correct totals"
82	assert order.subtotal == 100
83	assert order.tax == 21
84	assert order.total == 121
85
86	// Bad: two unrelated concepts in one test
87	assert order.total == 121
88	assert emailService.wasCalled()
89	```
90
91	### Test Naming
92
93	Test names should describe the behavior, not the implementation. A good test name answers: "What scenario is being tested, and what is the expected outcome?"
94
95	Patterns that work across languages:
96	- `should_return_zero_when_cart_is_empty`
97	- `rejects_negative_quantities`
98	- `applies_discount_for_premium_customers`
99
100	Avoid names like `testCalculate`, `test1`, or `testGetterSetter`.
101
102	### Test Independence and Isolation
103
104	Each test must be completely independent of every other test:
105
106	- No shared mutable state between tests
107	- No required execution order
108	- Each test sets up its own preconditions and cleans up after itself
109	- A single failing test should not cascade into other failures
110
111	### Deterministic Tests
112
113	A test must produce the same result every time it runs, regardless of:
114
115	- The current time or date
116	- The order of test execution
117	- The machine it runs on
118	- Network availability
119	- Other tests running in parallel
120
121	Non-deterministic tests (flaky tests) destroy trust in the test suite and are worse than no tests at all.
122
123	### FIRST Principles
124
125	\| Principle \| Meaning \|
126	\|---\|---\|
127	\| *

People who liked this also viewed

6 picks

Type

testing

48installs1forks

View on GitHub

How to install testing?

krzysztofsurdy/code-virtuoso/testing

$npx -y skills add krzysztofsurdy/code-virtuoso --skill testing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Testing
2
3	A disciplined approach to verifying that software behaves correctly, remains stable under change, and communicates intent to future developers. Good tests act as living documentation, a safety net for refactoring, and a design feedback mechanism.
4
5	This skill covers universal testing concepts that apply regardless of language, framework, or tooling.
6
7	## When to Use
8
9	- Designing a test strategy for a new project or feature
10	- Deciding what level of testing (unit, integration, e2e) a piece of code needs
11	- Evaluating whether existing tests are providing value or creating drag
12	- Applying TDD to drive design decisions
13	- Debugging a flaky or brittle test suite
14	- Reviewing test code for quality and maintainability
15
16	## Testing Pyramid
17
18	The testing pyramid describes the ideal distribution of tests across three levels. More tests at the base, fewer at the top.
19
20	```
21	/ E2E \ Few, slow, expensive
22	/----------\
23	/ Integration \ Moderate number, moderate speed
24	/----------------\
25	/ Unit Tests \ Many, fast, cheap
26	/____________________\
27	```
28
29	### Unit Tests (Base)
30
31	- Test a single unit of behavior in isolation (a function, a method, a small class)
32	- No I/O, no database, no network, no file system
33	- Execute in milliseconds
34	- Should form the majority of your test suite (roughly 70%)
35	- Fast feedback loop enables rapid iteration
36
37	### Integration Tests (Middle)
38
39	- Test how multiple units collaborate, or how code interacts with external systems
40	- May involve a real database, message queue, or HTTP endpoint
41	- Execute in seconds
42	- Verify that wiring, configuration, and contracts between components work
43	- Roughly 20% of your test suite
44
45	### End-to-End Tests (Top)
46
47	- Test complete user journeys through the full system
48	- Interact with the application as a user would
49	- Slowest, most brittle, most expensive to maintain
50	- Reserve for critical business paths only
51	- Roughly 10% of your test suite
52
53	### The Ice Cream Cone Antipattern
54
55	The inverted pyramid: many e2e tests, few unit tests. Symptoms:
56
57	- Test suite takes hours to run
58	- Tests break constantly due to UI changes or timing issues
59	- Developers stop running tests locally
60	- Feedback loop is too slow to support continuous delivery
61
62	Fix: Identify what each e2e test is actually verifying. Push that verification down to the lowest possible level. Most business logic can be tested at the unit level.
63
64	## Test Design Principles
65
66	### Arrange-Act-Assert (AAA)
67
68	Every test should follow three distinct phases:
69
70	1. Arrange — set up the preconditions and inputs
71	2. Act — execute the behavior under test
72	3. Assert — verify the expected outcome
73
74	Keep each phase clearly separated. If Arrange dominates the test, extract a builder or factory. If Act requires multiple steps, you may be testing too much at once.
75
76	### One Assertion per Concept
77
78	A test should verify one logical concept. This does not mean literally one `assert` call — asserting multiple properties of a single result is fine. What matters is that the test fails for exactly one reason.
79
80	```
81	// Good: one concept — "completed order has correct totals"
82	assert order.subtotal == 100
83	assert order.tax == 21
84	assert order.total == 121
85
86	// Bad: two unrelated concepts in one test
87	assert order.total == 121
88	assert emailService.wasCalled()
89	```
90
91	### Test Naming
92
93	Test names should describe the behavior, not the implementation. A good test name answers: "What scenario is being tested, and what is the expected outcome?"
94
95	Patterns that work across languages:
96	- `should_return_zero_when_cart_is_empty`
97	- `rejects_negative_quantities`
98	- `applies_discount_for_premium_customers`
99
100	Avoid names like `testCalculate`, `test1`, or `testGetterSetter`.
101
102	### Test Independence and Isolation
103
104	Each test must be completely independent of every other test:
105
106	- No shared mutable state between tests
107	- No required execution order
108	- Each test sets up its own preconditions and cleans up after itself
109	- A single failing test should not cascade into other failures
110
111	### Deterministic Tests
112
113	A test must produce the same result every time it runs, regardless of:
114
115	- The current time or date
116	- The order of test execution
117	- The machine it runs on
118	- Network availability
119	- Other tests running in parallel
120
121	Non-deterministic tests (flaky tests) destroy trust in the test suite and are worse than no tests at all.
122
123	### FIRST Principles
124
125	\| Principle \| Meaning \|
126	\|---\|---\|
127	\| *

People who liked this also viewed

6 picks

Type