Unit-Tests: Das Sicherheitsnetz, auch bekannt als „Wie man nachts schläft“.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Die Vertrauenskrise

Sie müssen eine Kernfunktion umgestalten. Möglicherweise liegt es an der Funktion „calculateTax()“ im Checkout. Es ist chaotisch. Es verfügt über verschachtelte „if“-Anweisungen. Es verwendet alte Syntax. Du willst es aufräumen. Aber du hast Angst. Sie fragen sich: „Wenn ich das berühre und gegen eine bestimmte Steuerregel für deutsche Großhandelskunden verstoße, werde ich es dann erfahren?“ Wenn die Antwort „Nein“ lautet, sind Sie gelähmt. Also lässt du es. Der „Legacy Code“ bleibt bestehen. Es verrottet. Es wird zum „Gruselordner“, den niemand berührt. Unit-Tests sind das Heilmittel für diese Lähmung. Sie frieren das Verhalten des Codes zeitlich ein. Sie garantieren: „Diese Funktion MUSS bei gegebener Eingabe „2“ „4“ zurückgeben.“ Wenn dieser Vertrag gilt, können Sie die interne Implementierung nach Ihren Wünschen umschreiben. Tests erleichtern Aggressives Refactoring. Ohne Tests ist Refactoring nur „Vermutung“.

Warum Maison Code Unit-Tests diskutiert

Bei Maison Code führen wir häufig „Rettungsmissionen“ auf älteren Plattformen durch. Wir finden Codebasen, vor deren Bereitstellung sich Entwickler fürchten. „Fassen Sie das UserSync-Modul nicht an, es geht kaputt, wenn Sie es falsch betrachten.“ Diese Angst lähmt das Geschäft. Neue Funktionen benötigen Monate, da 80 % der Zeit für manuelle Regressionstests aufgewendet werden. Wir glauben, dass testbarer Code sauberer Code ist. Wir implementieren robuste Unit-Testing-Suiten mit Jest/Vitest, um dem Team sein Selbstvertrauen zurückzugeben. Wenn die Tests grün sind, erfolgt die Bereitstellung. So einfach ist das. Wir verwandeln den „Deployment Friday“ von einem Albtraum in ein Nicht-Ereignis.

Das Tool: Jest / Vitest

• Scherz: Der Amtsinhaber. Verwaltet von Meta. Standard in Create React App / Next.js. Kraftvoll, aber schwer.
• Vitest: Der Herausforderer. Unterstützt von Vite. Es ist funktional identisch mit Jest (kompatible API), aber 10x schneller, da es ES-Module nativ verwendet. Wir werden hier die Jest-Syntax verwenden, da sie für beide gilt. Die Konzepte sind universell.

Die Strategie: Was testen?

Hier scheitern Teams. Die Falle der „100 %-Abdeckung“. Manager sehnen sich nach „100 % Code-Abdeckung“. Sie haben es in die OKRs geschrieben. Dies führt zu nutzlosen Tests.

Schlechter Test (Testen des Frameworks): „Javascript const Button = ({ label }) => {label};

test(‘Button rendert’, () => { render(); erwarten(screen.getByText(‘Go’)).toBeInTheDocument(); }); „ Dieser Test hat einen niedrigen Wert. Es testet React. Wir wissen, dass React funktioniert. Es verfügt über einen hohen Wartungsaufwand. Wenn wir „label“ in „text“ umbenennen, bricht der Test ab, obwohl die App funktioniert. Dies ist ein „falsches Negativ“.

Gute Teststrategie: Konzentrieren Sie sich auf Geschäftslogik und Edge Cases.

1. Reine Funktionen (höchster ROI)

Eine reine Funktion hängt nur von Argumenten ab und gibt einen Wert zurück. Keine Nebenwirkungen. Keine API-Aufrufe. Es ist eine Freude, diese zu testen. Sie laufen in Millisekunden.

„Javascript // logik.ts /**

• Berechnet den Rabatt basierend auf der Kundenstufe.
• Regeln:
• • VIP erhält 20 % Rabatt.
• – Negativer Preis löst Fehler aus.
• • Mitarbeiter erhält 50 % Rabatt. */ Exportfunktion berechneDiscount(Preis: Zahl, Typ: ‘VIP’ | ‘Regulär’ | ‘Mitarbeiter’): Zahl { if (price < 0) throw new Error(‘Negativer Preis ist unmöglich’); if (type === ‘Employee’) return price * 0.5; if (type === ‘VIP’) Rückgabepreis * 0,8; Rückgabepreis; }

// logik.test.ts beschreiben(‘calculateDiscount’, () => { test(‘gibt 20 % Rabatt an VIP’, () => { // Ordnen konstanter Preis = 100; const type = ‘VIP’; // Akt const result = berechneDiscount(Preis, Typ); // Behaupten erwarten(Ergebnis).toBe(80); });

test(‘gibt 50 % Rabatt an den Mitarbeiter’, () => { Expect(calculateDiscount(100, ‘Employee’)).toBe(50); });

test(‘gibt 0 % Rabatt auf Regular’, () => { Expect(calculateDiscount(100, ‘Regular’)).toBe(100); // 100 * 1 = 100 });

test(‘wirft einen negativen Preis aus’, () => { // Hinweis: Wir verpacken den aufrufenden Code in eine Funktion, damit Jest den Fehler abfangen kann erwarten(() => berechneDiscount(-10, ‘Regular’)).toThrow(‘Negativer Preis’); }); }); „ Das ist robust. Es dokumentiert die Geschäftsregeln besser als Kommentare.

2. Spott (Das notwendige Übel)

Der meiste Code interagiert mit der Welt (Datenbank, API, LocalStorage). Sie können in einem Komponententest keinen echten API-Aufruf ausführen. Es ist langsam, unzuverlässig und erfordert Anmeldeinformationen. Sie verspotten die Abhängigkeit.

„Javascript // userProfile.ts import { fetchUserFromStripe } from ’./api’;

Asynchrone Funktion exportieren getUserStatus(id: string) { const user = waiting fetchUserFromStripe(id); // Externe Abhängigkeit if (user.delinquent) return ‘Blocked’; return ‘Aktiv’; }

// userProfile.test.ts import { fetchUserFromStripe } from ’./api’; jest.mock(’./api’); // Modul automatisch verspotten. Ersetzt echte Funktionen durch jest.fn()

test(‘gibt Blockiert zurück, wenn der Benutzer säumig ist’, async () => { // Richten Sie die Scheinantwort ein (fetchUserFromStripe as jest.Mock).mockResolvedValue({ id: ‘1’, delinquent: true });

const status = Warten auf getUserStatus(‘1’);

erwarten(status).toBe(‘Blockiert’); // Überprüfen Sie, ob die API korrekt aufgerufen wurde, um sicherzustellen, dass wir die ID übergeben erwarten(fetchUserFromStripe).toHaveBeenCalledWith(‘1’); }); „

Warnung vor Spott: Spott lügt. Wenn der echte „fetchUserFromStripe“ sein Rückgabeformat ändert (z. B. „delinquent“ wird zu „isDelinquent“), wird Ihr Test trotzdem bestanden (weil Sie das alte Format verspottet haben), aber Ihre App wird abstürzen. Verwenden Sie TypeScript, um Mocks mit echten Typen synchron zu halten.

Snapshot-Testen: Feature oder Bug?

Jest führte „Snapshots“ ein. expect(component).toMatchSnapshot(). Es serialisiert die gerenderte Komponente in eine Textdatei („snapshots/comp.test.js.snap“). Wenn Sie H1 in H2 ändern, schlägt der Test fehl. Das Problem: Entwickler betrachten dies als störend. Sie führen den Test durch. Es scheitert. Sie geben „jest -u“ (Update) ein, ohne hinzusehen. Snapshot-Tests sind brüchig. Best Practice: Verwenden Sie Snapshots für sehr kleine, stabile Komponenten (Symbole, Design-Tokens), bei denen jede Änderung verdächtig ist. Verwenden Sie sie nicht für komplexe Seiten.

Async-Code testen (Die Async/Await-Falle)

Das Testen von Versprechen ist schwierig. Häufiger Fehler: „await“ oder „params“ vergessen.

„Javascript // SCHLECHT: Der Test wird beendet, bevor das Versprechen aufgelöst wird test(‘schlechter asynchroner Test’, () => { fetchData().then(data => { erwarten(Daten).toBe(‘Erdnussbutter’); }); }); „ Wenn „fetchData“ fehlschlägt, ist der Test möglicherweise trotzdem erfolgreich (falsch positiv) oder es kommt zu einer Zeitüberschreitung.

Gut: „Javascript test(‘guter asynchroner Test’, async () => { const data = Warten auf fetchData(); erwarten(Daten).toBe(‘Erdnussbutter’); }); „

Verwenden Sie für Timer (z. B. „setTimeout“) Fake Timer: jest.useFakeTimers(). jest.advanceTimersByTime(1000). Dadurch können Sie eine Verzögerung von 10 Sekunden in 1 Millisekunde testen.

Die TDD-Debatte (Test Driven Development).

„Schreiben Sie zuerst den Test.“ Vorteile: Zwingt Sie dazu, die API vor der Implementierung zu entwerfen. Ergibt sehr sauberen, entkoppelten Code. Nachteile: Langsamere Anfangsgeschwindigkeit. Schwierig, wenn Sie „erkunden“ (Prototyping) und die endgültige Struktur nicht kennen. Urteil: Verwenden Sie TDD für komplexe algorithmische Logik (z. B. Parsen einer CSV, Berechnen von Steuern, String-Manipulation). Verwenden Sie es nicht für einfache UI-Komponenten, bei denen Sie auf Pixeln iterieren.

Integration vs. Einheit: Die Trophäenform

Kent C. Dodds formalisierte die „Testing Trophy“.

1. Statische Analyse (ESLint, TypeScript): Erkennt Tippfehler. (Am schnellsten/Günstigsten).
2. Unit-Tests: Testen Sie reine Funktionen. (Schnell).
3. Integrationstests: Testen Sie die Verbindung zwischen Komponenten. (Der Sweet Spot).
4. E2E-Tests: Testen Sie den vollständigen Browser. (Langsam/teuer).

Empfehlung: Schreiben Sie hauptsächlich Integrationstests. Testen Sie „LoginForm“ + „SubmitButton“ + „ApiMock“. Testen Sie „SubmitButton“ nicht isoliert. Testen Sie, ob durch Klicken auf „Senden“ die Anmelde-API aufgerufen wird.

FAQ

F: Wie teste ich private Funktionen? A: Nicht. Testen Sie die öffentliche API. Die private Funktion ist ein Implementierungsdetail. Wenn Sie private Funktionen testen, binden Sie sich an diese Implementierung. Sie verlieren die Fähigkeit zur Umgestaltung.

F: CI/CD-Integration? A: Tests müssen bei jedem Pull Request ausgeführt werden. Wenn der „npm-Test“ fehlschlägt, sollte die Schaltfläche „Zusammenführen“ deaktiviert werden. Dadurch bleibt die „Green Master“-Politik erhalten.

Fazit

Tests sind eine Investition. Sie zahlen im Voraus (Zeit). Sie erhalten für immer Dividenden (Stabilität, Geschwindigkeit des Refactorings, Dokumentation). Eine Codebasis ohne Tests ist vom ersten Tag an eine „Legacy Codebase“. Eine Codebasis mit Tests ist ein „Asset“. Es gewinnt an Wert.

Umsetzung gelähmt?

Wenn Ihr Team aus Angst davor, alten Code zu knacken, gelähmt ist, ist Maison Code die Lösung. Wir führen „Refactoring Raids“ durch, bei denen wir Ihre Codebasis prüfen, Testabdeckung hinzufügen und die technischen Schulden beseitigen, die Sie ausbremsen. Wir schulen Ihr Team darin, Tests zu schreiben, die nicht scheiße sind.

---

Beauftragen Sie unsere Architekten.