tdd-strict

Name: tdd-strict
Author: Svenja-dev

61installs5forks

How to install tdd-strict?

svenja-dev/claude-code-skills/tdd-strict

$npx -y skills add Svenja-dev/claude-code-skills --skill tdd-strict

Installs into the current project.

Summary

Erzwingt striktes Test-Driven Development mit Red-Green-Refactor Zyklus. Blockiert Code-Generierung ohne vorherige Tests. Dokumentiert 13 ungueltige Rationalisierungen. Aktivieren bei neuen Features, Bug Fixes, Refactoring.

Files · 1

View on GitHub

SKILL.md

1	# Striktes Test-Driven Development
2
3	Dieser Skill erzwingt TDD-Praktiken basierend auf dem Kernprinzip:
4
5	> "If you didn't watch the test fail, you don't know if it tests the right thing."
6
7	## Wann aktivieren
8
9	- Bei jeder neuen Feature-Implementierung
10	- Bei Bug Fixes (erst Test der Bug reproduziert, dann Fix)
11	- Bei Refactoring (Tests muessen vor UND nach Aenderung bestehen)
12	- Bei API-Erweiterungen
13	- Bei jeder exportierten Funktion
14
15	## Der Red-Green-Refactor Zyklus
16
17	### 1. RED: Test schreiben der fehlschlaegt
18
19	```typescript
20	// ZUERST: Test schreiben
21	describe('calculateOEE', () => {
22	it('should return 0 when availability is 0', () => {
23	const result = calculateOEE({ availability: 0, performance: 100, quality: 100 });
24	expect(result).toBe(0);
25	});
26	});
27
28	// Test MUSS fehlschlagen:
29	// Error: calculateOEE is not defined
30	// ODER
31	// Error: Expected 0 but received undefined
32	```
33
34	Wichtig: Der Test MUSS aus dem richtigen Grund fehlschlagen:
35	- Funktion existiert nicht
36	- Funktion gibt falsches Ergebnis zurueck
37	- NICHT: Syntaxfehler im Test selbst
38
39	### 2. GREEN: Minimaler Code der Test besteht
40
41	```typescript
42	// DANACH: Minimaler Code
43	export function calculateOEE(params: OEEParams): number {
44	if (params.availability === 0) return 0;
45	// Weitere Logik kommt spaeter durch weitere Tests
46	return 0;
47	}
48	```
49
50	Regel: Schreibe den EINFACHSTEN Code der den Test besteht.
51	- Keine Optimierungen
52	- Keine zusaetzlichen Features
53	- Keine "offensichtlichen" Erweiterungen
54
55	### 3. REFACTOR: Bereinigen ohne neues Verhalten
56
57	```typescript
58	// Nach mehreren gruenen Tests: Refactoring erlaubt
59	export function calculateOEE({ availability, performance, quality }: OEEParams): number {
60	return (availability * performance * quality) / 10000;
61	}
62	```
63
64	Regeln fuer Refactoring:
65	- Alle bestehenden Tests MUESSEN bestehen bleiben
66	- KEIN neues Verhalten hinzufuegen
67	- Nur Code-Struktur verbessern
68	- Nach jedem Refactoring-Schritt: Tests laufen lassen
69
70	## Die 13 ungueltigen Rationalisierungen
71
72	Diese Ausreden sind NIEMALS akzeptabel:
73
74	### 1. "Zu einfach zum Testen"
75	Realitaet: Einfacher Code braucht einfache Tests. 1 Zeile Test ist okay.
76	```typescript
77	it('should add two numbers', () => {
78	expect(add(2, 3)).toBe(5);
79	});
80	```
81
82	### 2. "Ich teste spaeter"
83	Realitaet: "Spaeter" bedeutet "nie". TDD bedeutet Test ZUERST.
84
85	### 3. "Bereits manuell getestet"
86	Realitaet: Manuelle Tests sind nicht reproduzierbar und skalieren nicht.
87
88	### 4. "Zeitdruck erlaubt keine Tests"
89	Realitaet: Tests sparen Zeit bei Debugging und verhindern Regressionen.
90
91	### 5. "Private Methoden muss man nicht testen"
92	Realitaet: Teste das Verhalten durch Public APIs. Wenn nicht testbar: Refactor.
93
94	### 6. "UI-Code kann man nicht testen"
95	Realitaet: React Testing Library, Playwright, Storybook existieren genau dafuer.
96
97	### 7. "Die Logik ist trivial"
98	Realitaet: Triviale Logik aendert sich. Tests dokumentieren erwartetes Verhalten.
99
100	### 8. "Wir haben einen QA-Prozess"
101	Realitaet: QA findet Bugs spaeter und teurer. TDD verhindert Bugs von Anfang an.
102
103	### 9. "Der Code ist nur temporaer"
104	Realitaet: Temporaerer Code lebt oft Jahre. Tests sichern auch temporaeren Code ab.
105
106	### 10. "Tests verlangsamen die Entwicklung"
107	Realitaet: TDD beschleunigt langfristig durch weniger Debugging und Regressionen.
108
109	### 11. "Legacy Code hat keine Tests"
110	Realitaet: Charakterisierungstests vor Aenderungen schreiben. Schrittweise verbessern.
111
112	### 12. "Das Framework/die Library testet das schon"
113	Realitaet: Teste DEINE Nutzung des Frameworks, nicht das Framework selbst.
114
115	### 13. "Mocking ist zu aufwaendig"
116	Realitaet: Wenn Mocking zu komplex ist, ist das Design zu komplex. Refactor.
117
118	## Verification Checklist
119
120	Vor jedem Commit MUSS gelten:
121
122	- [ ] Jede exportierte Funktion hat mindestens einen Test
123	- [ ] Jeder Test ist VOR der Implementation fehlgeschlagen (RED beobachtet)
124	- [ ] Jeder Test prueft genau EINE Sache (Single Assertion Principle)
125	- [ ] Minimaler Code pro Test (kein Over-Engineering)
126	- [ ] Edge Cases abgedeckt:
127	- [ ] Null/Undefined Inputs
128	- [ ] Leere Arrays/Strings
129	- [ ] Grenzwerte (0, MAX_INT, negative Zahlen)
130	- [ ] Fehlerhafte Inputs (TypeError erwartet)
131	- [ ] Test-Namen beschreiben Verhalten: `should [erwartetes Ergebnis] when [Bedingung]`
132	- [ ] Keine `skip` oder `only` Tests im Commit
133	- [ ] Coverage mindestens 80% fuer neuen Code
134
135	## TDD-Workflow in der Praxis
136
137	### Schritt 1: Test-Datei erstellen
138
139	```bash
140	# Fuer neue Funktion in src/utils/oee.ts
141	touch src/utils/oee.test.ts
142	```
143
144	### Schritt 2: Minimaler fehlschlagender Test
145
146	```typescript
147	// src/utils/oee.test.ts
148	import { describe, it, expect } from 'vitest';
149	import { calculateOEE } from './oee';
150
151	describe('calculateOEE', () => {
152	it('sho

People who liked this also viewed

6 picks

Type

tdd-strict

61installs5forks

View on GitHub

How to install tdd-strict?

svenja-dev/claude-code-skills/tdd-strict

$npx -y skills add Svenja-dev/claude-code-skills --skill tdd-strict

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Striktes Test-Driven Development
2
3	Dieser Skill erzwingt TDD-Praktiken basierend auf dem Kernprinzip:
4
5	> "If you didn't watch the test fail, you don't know if it tests the right thing."
6
7	## Wann aktivieren
8
9	- Bei jeder neuen Feature-Implementierung
10	- Bei Bug Fixes (erst Test der Bug reproduziert, dann Fix)
11	- Bei Refactoring (Tests muessen vor UND nach Aenderung bestehen)
12	- Bei API-Erweiterungen
13	- Bei jeder exportierten Funktion
14
15	## Der Red-Green-Refactor Zyklus
16
17	### 1. RED: Test schreiben der fehlschlaegt
18
19	```typescript
20	// ZUERST: Test schreiben
21	describe('calculateOEE', () => {
22	it('should return 0 when availability is 0', () => {
23	const result = calculateOEE({ availability: 0, performance: 100, quality: 100 });
24	expect(result).toBe(0);
25	});
26	});
27
28	// Test MUSS fehlschlagen:
29	// Error: calculateOEE is not defined
30	// ODER
31	// Error: Expected 0 but received undefined
32	```
33
34	Wichtig: Der Test MUSS aus dem richtigen Grund fehlschlagen:
35	- Funktion existiert nicht
36	- Funktion gibt falsches Ergebnis zurueck
37	- NICHT: Syntaxfehler im Test selbst
38
39	### 2. GREEN: Minimaler Code der Test besteht
40
41	```typescript
42	// DANACH: Minimaler Code
43	export function calculateOEE(params: OEEParams): number {
44	if (params.availability === 0) return 0;
45	// Weitere Logik kommt spaeter durch weitere Tests
46	return 0;
47	}
48	```
49
50	Regel: Schreibe den EINFACHSTEN Code der den Test besteht.
51	- Keine Optimierungen
52	- Keine zusaetzlichen Features
53	- Keine "offensichtlichen" Erweiterungen
54
55	### 3. REFACTOR: Bereinigen ohne neues Verhalten
56
57	```typescript
58	// Nach mehreren gruenen Tests: Refactoring erlaubt
59	export function calculateOEE({ availability, performance, quality }: OEEParams): number {
60	return (availability * performance * quality) / 10000;
61	}
62	```
63
64	Regeln fuer Refactoring:
65	- Alle bestehenden Tests MUESSEN bestehen bleiben
66	- KEIN neues Verhalten hinzufuegen
67	- Nur Code-Struktur verbessern
68	- Nach jedem Refactoring-Schritt: Tests laufen lassen
69
70	## Die 13 ungueltigen Rationalisierungen
71
72	Diese Ausreden sind NIEMALS akzeptabel:
73
74	### 1. "Zu einfach zum Testen"
75	Realitaet: Einfacher Code braucht einfache Tests. 1 Zeile Test ist okay.
76	```typescript
77	it('should add two numbers', () => {
78	expect(add(2, 3)).toBe(5);
79	});
80	```
81
82	### 2. "Ich teste spaeter"
83	Realitaet: "Spaeter" bedeutet "nie". TDD bedeutet Test ZUERST.
84
85	### 3. "Bereits manuell getestet"
86	Realitaet: Manuelle Tests sind nicht reproduzierbar und skalieren nicht.
87
88	### 4. "Zeitdruck erlaubt keine Tests"
89	Realitaet: Tests sparen Zeit bei Debugging und verhindern Regressionen.
90
91	### 5. "Private Methoden muss man nicht testen"
92	Realitaet: Teste das Verhalten durch Public APIs. Wenn nicht testbar: Refactor.
93
94	### 6. "UI-Code kann man nicht testen"
95	Realitaet: React Testing Library, Playwright, Storybook existieren genau dafuer.
96
97	### 7. "Die Logik ist trivial"
98	Realitaet: Triviale Logik aendert sich. Tests dokumentieren erwartetes Verhalten.
99
100	### 8. "Wir haben einen QA-Prozess"
101	Realitaet: QA findet Bugs spaeter und teurer. TDD verhindert Bugs von Anfang an.
102
103	### 9. "Der Code ist nur temporaer"
104	Realitaet: Temporaerer Code lebt oft Jahre. Tests sichern auch temporaeren Code ab.
105
106	### 10. "Tests verlangsamen die Entwicklung"
107	Realitaet: TDD beschleunigt langfristig durch weniger Debugging und Regressionen.
108
109	### 11. "Legacy Code hat keine Tests"
110	Realitaet: Charakterisierungstests vor Aenderungen schreiben. Schrittweise verbessern.
111
112	### 12. "Das Framework/die Library testet das schon"
113	Realitaet: Teste DEINE Nutzung des Frameworks, nicht das Framework selbst.
114
115	### 13. "Mocking ist zu aufwaendig"
116	Realitaet: Wenn Mocking zu komplex ist, ist das Design zu komplex. Refactor.
117
118	## Verification Checklist
119
120	Vor jedem Commit MUSS gelten:
121
122	- [ ] Jede exportierte Funktion hat mindestens einen Test
123	- [ ] Jeder Test ist VOR der Implementation fehlgeschlagen (RED beobachtet)
124	- [ ] Jeder Test prueft genau EINE Sache (Single Assertion Principle)
125	- [ ] Minimaler Code pro Test (kein Over-Engineering)
126	- [ ] Edge Cases abgedeckt:
127	- [ ] Null/Undefined Inputs
128	- [ ] Leere Arrays/Strings
129	- [ ] Grenzwerte (0, MAX_INT, negative Zahlen)
130	- [ ] Fehlerhafte Inputs (TypeError erwartet)
131	- [ ] Test-Namen beschreiben Verhalten: `should [erwartetes Ergebnis] when [Bedingung]`
132	- [ ] Keine `skip` oder `only` Tests im Commit
133	- [ ] Coverage mindestens 80% fuer neuen Code
134
135	## TDD-Workflow in der Praxis
136
137	### Schritt 1: Test-Datei erstellen
138
139	```bash
140	# Fuer neue Funktion in src/utils/oee.ts
141	touch src/utils/oee.test.ts
142	```
143
144	### Schritt 2: Minimaler fehlschlagender Test
145
146	```typescript
147	// src/utils/oee.test.ts
148	import { describe, it, expect } from 'vitest';
149	import { calculateOEE } from './oee';
150
151	describe('calculateOEE', () => {
152	it('sho

People who liked this also viewed

6 picks

Type