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 Angst vor dem Einsatz

Jeder Softwareentwickler kennt das Gefühl. Es ist Freitag, 16:00 Uhr. Sie haben gerade einen Pull Request zusammengeführt. Die Bereitstellungspipeline wird grün. Du solltest glücklich sein. Aber du schwitzt. „Habe ich den Checkout-Ablauf unterbrochen?“ „Habe ich das Zurücksetzen des Passworts unterbrochen?“ „Habe ich das mobile Menü in Safari getestet?“ Wenn Sie sich auf manuelle Tests verlassen (indem Sie sich selbst auf der Website umsehen), leben Sie in einem ständigen Zustand der Angst. Menschen sind bei Regressionstests schrecklich. Wir langweilen uns. Wir vermissen Dinge. Wir testen den „Happy Path“ und vergessen die Randfälle. Wenn die Codebasis wächst, wächst die Zeit, die zum manuellen Testen erforderlich ist, linear. Irgendwann hört man mit dem Testen auf. Dann dringen die Fehler in die Produktion ein. Und wenn Fehler bekannt werden, entgehen Ihnen Einnahmen. Du verlierst das Vertrauen. Automatisierte Tests sind das Heilmittel gegen diese Angst. Dadurch wird der Einsatz von einem „Hochrisiko-Ereignis“ zu einem „Nicht-Ereignis“.

Warum Maison Code automatisierte Tests diskutiert

Bei Maison Code arbeiten wir mit hochkarätigen Luxusmarken und stark frequentierten E-Commerce-Plattformen zusammen. Unsere Kunden erwirtschaften in Spitzenverkäufen (Black Friday, Weihnachten) Tausende von Euro pro Minute. Ein „kleinerer“ Fehler im Checkout-Ablauf stellt keine Unannehmlichkeiten dar; Es ist eine finanzielle Katastrophe. Wir haben gesehen, dass Marken innerhalb einer Stunde 50.000 US-Dollar verloren haben, weil eine „AddToCart“-Schaltfläche durch einen Z-Index-Fehler auf dem iPhone 12 verdeckt wurde. Wir sprechen über automatisierte Tests, weil Stabilität gleich Umsatz ist. Wir verkaufen keinen „Code“. Wir verkaufen „Zuverlässigkeit“. Die Implementierung einer robusten E2E-Suite ist oft das erste, was wir tun, wenn wir die Legacy-Codebasis eines Kunden prüfen. Es stoppt das Bluten und ermöglicht uns ein sicheres Refactoring.

1. Die Testpyramide: Ein strategischer Rahmen

Mike Cohn hat das Konzept der „Testpyramide“ populär gemacht und es bleibt der Goldstandard für Teststrategien. Es definiert die ideale Verteilung der Tests in Ihrer Suite.

Einheitentests (70 %):
- Geltungsbereich: Einzelne Funktionen oder Klassen.
- Geschwindigkeit: Millisekunden.
- Kosten: Günstig.
- Werkzeug: Jest, Vitest.
- Beispiel: add(2, 2) === 4.
Integrationstests (20 %):
- Umfang: Interaktionen zwischen Komponenten (z. B. Übergabe von Requisiten durch das Elternteil an das Kind).
- Geschwindigkeit: Sekunden.
- Kosten: Mittel.
- Tool: React Testing Library.
End-to-End (E2E)-Tests (10 %):
- Umfang: Vollständige Benutzerflüsse in einem echten Browser.
- Geschwindigkeit: Minuten.
- Kosten: Teuer (rechenintensiv).
- Werkzeug: Dramatiker, Cypress.

In diesem Artikel konzentrieren wir uns auf die Spitze der Pyramide: E2E-Tests. Warum? Weil es den höchsten Konfidenzkoeffizienten bietet. Ein Komponententest kann auch dann bestanden werden, wenn die Schaltfläche „Senden“ durch einen CSS-„Z-Index“-Fehler ausgeblendet ist. Ein E2E-Test schlägt fehl, da versucht wird, auf die Schaltfläche zu klicken. Wenn ein E2E-Test „Benutzer hat Artikel gekauft“ lautet, können Sie zu 99,9 % sicher sein, dass Benutzer Artikel kaufen können.

2. Das Werkzeug der Wahl: Dramatiker

Ein Jahrzehnt lang war Selen der Standard. Es war langsam, Java-basiert und bekanntermaßen unzuverlässig. Dann kam Zypresse. Es war eine enorme Verbesserung mit einer großartigen Entwicklererfahrung, hatte aber architektonische Einschränkungen (Ausführung innerhalb der Browser-Sandbox, eingeschränkte Unterstützung für mehrere Registerkarten). Heute ist der Industriestandard Playwright (von Microsoft). Warum Dramatiker?

Geschwindigkeit: Es führt Tests parallel über mehrere Arbeitsprozesse hinweg aus.
Zuverlässigkeit: Es verfügt über „Auto-Waiting“. Es wartet darauf, dass Elemente umsetzbar sind, bevor es interagiert. Kein „Schlaf (1000)“ mehr.
Multi-Browser: Es testet nativ auf Chromium, Firefox und WebKit (Safari).
Tracing: Es zeichnet einen vollständigen Video- und DOM-Trace jedes Fehlers auf, was das Debuggen trivial macht.

3. Implementierung: Testen eines Checkout-Ablaufs

Schauen wir uns ein Beispiel aus der Praxis an. Wir möchten testen, ob ein Gastbenutzer ein Produkt kaufen kann.

„Typoskript //tests/checkout.spec.ts import { test, Expect } from ‘@playwright/test’;

test.describe(‘Checkout Flow’, () => {

// Isolieren Sie die Testumgebung test.beforeEach(async ({ page }) => { // Cookies/Speicher zurücksetzen Warten Sie auf page.context().clearCookies(); });

test(‘Gastbenutzer kann einen Artikel kaufen’, async ({ page }) => { // 1. Navigation console.log(‘Navigieren zur Produktseite…’); Warten Sie auf page.goto(‘/products/silk-shirt’); Warten Sie Expect(page).toHaveTitle(/Silk Shirt/);

// 2. In den Warenkorb legen
// Benutzerbezogene Locators verwenden (Rolle, Beschriftung, Text)
// Vermeiden Sie CSS-Selektoren wie „.btn-primary“ (fragil)
wait page.getByRole('button', { name: 'In den Warenkorb' }).click();

// 3. Warenkorbschublade überprüfen
const cartDrawer = page.getByTestId('cart-drawer');
Warten Sie Expect(cartDrawer).toBeVisible();
Warten Sie Expect(cartDrawer).toContainText('Seidenhemd');

// 4. Zur Kasse gehen
wait page.getByRole('link', { name: 'Checkout' }).click();
wait Expect(page).toHaveURL(/.*\/checkout/);

// 5. Formular ausfüllen (Spöttische Zahlung)
Warten Sie auf page.getByLabel('Email').fill('test-bot@maisoncode.paris');
Warten Sie auf page.getByLabel('First Name').fill('Test');
Warten Sie auf page.getByLabel('Last Name').fill('Bot');
wait page.getByLabel('Address').fill('123 Test St');

// 6. Zahlung (Stripe Mock)
// Im strengen E2E könnten wir eine Stripe-Testkarte verwenden.
Warten Sie auf page.getByLabel('Card number').fill('4242 4242 4242 4242');
Warten Sie auf page.getByLabel('Expiry').fill('12/30');
Warten Sie auf page.getByLabel('CVC').fill('123');

// 7. Senden
wait page.getByRole('button', { name: 'Jetzt bezahlen' }).click();

// 8. Erfolg behaupten
// Timeout erhöhen, da die Zahlungsabwicklung Zeit benötigt
wait Expect(page.getByText('Vielen Dank für Ihre Bestellung')).toBeVisible({ timeout: 15000 });

});

}); „

4. Umgang mit „Flakiness“ (The Silent Killer)

Ein Flockiger Test ist ein Test, der in 90 % der Fälle besteht und in 10 % der Fälle fehlschlägt, ohne dass Codeänderungen erforderlich sind. Schuppenbildung ist der Feind. Wenn Entwickler den Tests nicht mehr vertrauen („Oh, führen Sie es einfach noch einmal aus, es ist flockig“), wird die Testsuite unbrauchbar.

Häufige Ursachen:

Netzwerklatenz: Die API benötigt 5,1 Sekunden, wenn die Zeitüberschreitung 5 Sekunden beträgt.
Animation: Klicken auf eine Schaltfläche, während diese noch hineingleitet.
Datenkontamination: Test A löscht einen Benutzer, den Test B benötigt.

Lösungen:

Verspottung (Netzwerkabhörung): Anstatt die echte Contentful-API aufzurufen (was langsam sein könnte), fangen Sie die Anfrage ab und geben Sie ein statisches JSON zurück. „Typoskript wait page.route(’**/api/products’, route => { route.fulfill({ path: ‘mock-data/products.json’ }); }); „ Dadurch wird der Test 10x schneller und 100 % deterministisch.
Wiederholungsversuche: Konfigurieren Sie CI so, dass fehlgeschlagene Tests automatisch wiederholt werden. Wiederholungen: 2. Wenn ein erneuter Versuch nicht bestanden wird, ist es instabil, blockiert aber zumindest nicht die Bereitstellung.

5. Visuelle Regressionstests (Pixel Perfect)

Playwright prüft die Funktionalität („Ist der Button anklickbar?“). Es wird nicht auf die Ästhetik geprüft („Ist der Knopf rosa?“). Wenn Sie „main.css“ versehentlich löschen, passiert Playwright möglicherweise trotzdem (die Schaltfläche ist anklickbar, nur unsichtbar). Visuelle Regressionstests (Percy / Chromatic / Playwright Snapshots) behebt dieses Problem. await Expect(page).toHaveScreenshot();

Machen Sie einen Screenshot der Seite.
Vergleichen Sie es mit dem „Golden Image“ (Basislinie).
Wenn sich die Pixel um > 1 % unterscheiden, besteht der Test nicht. Dies fängt „CSS-Regressionen“ ab, die kein Funktionstest jemals könnte.

6. GitHub-Aktionen: Der automatisierte Gatekeeper

Sie führen keine Tests auf Ihrem Laptop durch. Sie führen sie auf CI (Continuous Integration) aus. Jedes Mal, wenn Sie auf GitHub pushen, wird ein Workflow ausgeführt.

„yaml

.github/workflows/e2e.yml

Name: Dramatiker E2E am: drücken: Zweige: [Haupt] pull_request: Zweige: [Haupt]

Jobs: Test: Timeout-Minuten: 60 läuft weiter: ubuntu-latest Schritte: - verwendet: actions/checkout@v3 - verwendet: actions/setup-node@v3 mit: Knotenversion: 18 - Name: Install Deps Lauf: npm ci - Name: Browser installieren Führen Sie Folgendes aus: npx playwright install —with-deps

  - Name: Playwright ausführen
    Ausführen: Npx-Dramatikertest
    Umgebung:
      CI: stimmt
      BASE_URL: €{{ github.event.deployment.payload.web_url }} // Testen Sie die Vercel-Vorschau-URL

  - Name: Bericht hochladen
    verwendet: actions/upload-artifact@v3
    if: immer()
    mit:
      Name: Dramatiker-Bericht
      Pfad: Dramatiker-Bericht/

„

7. Die Kosten von CI (Optimierung)

Das Ausführen von 500 E2E-Tests bei jedem Commit ist teuer (GitHub Actions-Minuten). Optimierungsstrategien:

Sharding: Teilen Sie Tests auf 10 Maschinen auf, wodurch diese 10x schneller laufen. npx playwright test --shard=1/10.
Nur betroffene Projekte: Verwenden Sie Nx oder Turbo, um nur Tests für Apps auszuführen, die sich geändert haben.
Rauchtests für PRs: Führen Sie eine kleine Teilmenge (kritischer Pfad) für PRs durch. Führen Sie die vollständige Suite auf Main aus.

8. Fazit

Automatisiertes Testen ist keine „zusätzliche Arbeit“. Es ist die Arbeit. Es ist der Unterschied zwischen einem Prototyp und einem Produkt. Es ist der Unterschied zwischen „Ich hoffe, es funktioniert“ und „Ich weiß, dass es funktioniert“. Beginnen Sie noch heute. Schreiben Sie EINEN Test. Der Login-Test. Dann der Checkout-Test. Bald werden Sie nachts besser schlafen.

Veröffentlichungen, die Panik auslösen?

Mit Playwright entwickeln wir automatisierte E2E-Testsuiten, die Fehler erkennen, bevor es Benutzer tun.

Meine Qualitätssicherung automatisieren. Beauftragen Sie unsere Architekten.