WebSocket-Verbindungen automatisiert testen

1. Warum WebSocket-Testing sich fundamental von HTTP-Request-Testing unterscheidet

Ein klassischer HTTP-Test folgt einem einfachen, linearen Muster: Eine Anfrage wird gesendet, der Test wartet auf genau eine Antwort, und diese Antwort wird gegen die erwarteten Werte geprüft, ein Ablauf, für den nahezu jedes Testframework von Grund auf ausgelegt ist. Eine WebSocket-Verbindung hingegen bleibt nach dem initialen Handshake dauerhaft geöffnet, und Nachrichten können von beiden Seiten zu beliebigen, nicht vorhersehbaren Zeitpunkten gesendet werden, ohne dass eine Nachricht zwingend eine direkte Antwort auf eine vorherige darstellt.

Diese Asymmetrie zwischen Anfrage und Antwort bedeutet, dass ein Test nicht einfach synchron auf eine Rücksendung warten kann, sondern einen Nachrichtenstrom aktiv beobachten und darin gezielt nach der für den Test relevanten Nachricht suchen muss, wobei zusätzliche, für den konkreten Testfall irrelevante Nachrichten, etwa Heartbeat-Pings, während dieser Beobachtung durchaus mit auftauchen können und nicht als Fehler gewertet werden dürfen.

Ein weiterer protokollspezifischer Aspekt sind Ping-Pong-Frames, die viele WebSocket-Implementierungen automatisch im Hintergrund austauschen, um eine Verbindung als aktiv zu markieren und stille, aber tote Verbindungen frühzeitig zu erkennen, wobei ein Test, der versehentlich auf ein solches Ping-Pong-Frame als vermeintliche fachliche Nachricht wartet, fälschlicherweise fehlschlagen oder hängen bleiben kann, wenn der Nachrichtenfilter diese Protokoll-Frames nicht explizit ausschliesst.

2. Grundlegender Testaufbau mit einer WebSocket-Client-Bibliothek

Ein grundlegender WebSocket-Test benötigt eine Client-Bibliothek, die eine Verbindung zum WebSocket-Endpunkt aufbaut, eingehende Nachrichten über Event-Listener empfangbar macht und das Senden eigener Nachrichten erlaubt, wobei sich diese Grundstruktur unabhängig davon, ob der Test in Node.js mit der ws-Bibliothek oder direkt über die browsereigene WebSocket-API läuft, kaum unterscheidet.

import { test, expect } from '@playwright/test';
import WebSocket from 'ws';

test('WebSocket-Verbindung wird erfolgreich aufgebaut', async () => {
  const ws = new WebSocket('wss://shop.example.test/ws/stock-updates');

  await new Promise((resolve, reject) => {
    ws.on('open', resolve);
    ws.on('error', reject);
  });

  expect(ws.readyState).toBe(WebSocket.OPEN);
  ws.close();
});

3. Verbindungsaufbau und Authentifizierung gezielt testen

Über den blossen Nachweis eines erfolgreichen Handshakes hinaus lohnt sich ein gezielter Test des Authentifizierungsverhaltens, etwa ob eine Verbindung ohne gültiges Token korrekt mit einem Fehlercode abgelehnt wird, oder ob eine Verbindung mit einem abgelaufenen Token nach dem Handshake sofort wieder geschlossen wird, statt stillschweigend offen zu bleiben und erst bei der ersten Nachricht zu scheitern.

Ein häufig übersehener Testfall ist der Verbindungsversuch mit einer falschen oder fehlenden Ursprungs-Domain, sofern der Server eine Origin-Prüfung implementiert, da eine fehlerhaft konfigurierte oder versehentlich zu großzügige Origin-Prüfung ein reales Sicherheitsrisiko darstellt, das sich mit einem gezielten, automatisierten Testfall zuverlässig überwachen lässt.

Ebenfalls sinnvoll ist ein gezielter Test des Verhaltens bei einer während einer laufenden Sitzung ablaufenden Sitzungsgültigkeit, etwa wenn ein zunächst gültiges Token nach einer bestimmten Zeitspanne seine Gültigkeit verliert, während die WebSocket-Verbindung selbst weiterhin geöffnet bleibt, da ein sauber implementierter Server die Verbindung in diesem Fall aktiv schließen sollte, statt sie stillschweigend mit einem längst ungültigen Token weiterlaufen zu lassen, und der Client daraufhin selbstständig eine neue, gültige Sitzung anfordern muss.

4. Nachrichtenaustausch prüfen: Senden, Empfangen und Assertions

Beim Testen des eigentlichen Nachrichtenaustauschs sendet der Test eine Nachricht über die geöffnete Verbindung und wartet anschliessend gezielt auf eine passende Antwort, wobei die Wartefunktion nicht einfach die nächste eintreffende Nachricht akzeptieren sollte, sondern aktiv anhand eines Nachrichtentyps oder einer Kennung prüfen muss, ob es sich tatsächlich um die erwartete Antwort und nicht um eine zufällig dazwischen eingetroffene, andere Nachricht handelt.

Bei Anwendungen, die auf eine garantierte Reihenfolge der empfangenen Nachrichten angewiesen sind, etwa eine fortlaufend aktualisierte Aktivitätsliste, lohnt sich zusätzlich ein gezielter Test, der mehrere Nachrichten kurz hintereinander sendet und anschliessend prüft, dass sie tatsächlich in der gesendeten Reihenfolge und nicht vertauscht beim Client ankommen, da eine asynchrone Verarbeitung auf Serverseite unter bestimmten Umständen zu einer vertauschten Zustellreihenfolge führen kann.

function waitForMessage(ws, predicate, timeoutMs = 5000) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => reject(new Error('Timeout beim Warten auf Nachricht')), timeoutMs);
    ws.on('message', (raw) => {
      const data = JSON.parse(raw.toString());
      if (predicate(data)) {
        clearTimeout(timer);
        resolve(data);
      }
    });
  });
}

test('Lagerbestand-Update wird nach Änderung gesendet', async () => {
  const ws = new WebSocket('wss://shop.example.test/ws/stock-updates');
  await new Promise((resolve) => ws.on('open', resolve));

  ws.send(JSON.stringify({ type: 'subscribe', sku: 'TEST-001' }));
  const update = await waitForMessage(ws, (m) => m.type === 'stock_update' && m.sku === 'TEST-001');

  expect(update.quantity).toBeGreaterThanOrEqual(0);
  ws.close();
});

5. Reconnect-Verhalten nach einem unerwarteten Verbindungsabbruch testen

Ein realistisches WebSocket-Frontend implementiert in aller Regel eine automatische Wiederverbindung nach einem unerwarteten Verbindungsabbruch, weshalb ein gezielter Test genau dieses Verhaltens genauso wichtig ist wie der Test des normalen Nachrichtenflusses: Der Test erzwingt einen Verbindungsabbruch durch aktives Schließen der Verbindung von Serverseite, misst anschliessend, ob und nach welcher Zeitspanne der Client tatsächlich eine neue Verbindung aufbaut, und prüft, ob nach dem Reconnect verpasste Nachrichten nachgeliefert oder zumindest der aktuelle Zustand erneut synchronisiert wird.

Besonders wichtig ist die Prüfung eines exponentiellen Backoffs bei wiederholt fehlschlagenden Reconnect-Versuchen, da ein Client, der bei einem länger andaürnden Serverausfall in kurzen, festen Intervallen unbegrenzt weiterversucht, den ohnehin bereits gestörten Server zusätzlich mit Reconnect-Anfragen belasten würde, statt sich mit wachsenden Wartezeiten zurückzunehmen.

6. Timing-Probleme und Race Conditions bei asynchronen Nachrichten vermeiden

Ein häufiger Fehler bei WebSocket-Tests ist eine feste, geschätzte Wartezeit zwischen dem Senden einer Nachricht und der Prüfung des erwarteten Ergebnisses, ein Muster, das unter günstigen Bedingungen funktioniert, aber bei erhöhter Systemlast oder Netzwerklatenz gelegentlich fehlschlägt, weil die Antwort noch nicht eingetroffen ist, wenn die Assertion bereits ausgeführt wird.

Statt fester Wartezeiten sollte jeder WebSocket-Test aktiv auf ein konkretes Ereignis warten, sei es eine bestimmte Nachricht mit passendem Inhalt oder ein definierter Verbindungszustand, kombiniert mit einem großzügigen, aber endlichen Timeout, der den Test nur im tatsächlichen Fehlerfall verzögert und im Normalfall sofort nach Eintreffen des erwarteten Ereignisses fortfährt, wodurch die durchschnittliche Testlaufzeit trotz der zusätzlichen Sicherheit gegenüber einer festen, pauschalen Wartezeit sogar sinkt statt zu steigen.

7. WebSockets in Playwright-Browsertests direkt abfangen

Für Tests, die den kompletten Frontend-Fluss inklusive der WebSocket-Kommunikation im Browserkontext abbilden, bietet Playwright ein eigenes WebSocket-Event auf Seitenebene, über das jede vom Browser aufgebaute WebSocket-Verbindung sowie alle darüber gesendeten und empfangenen Nachrichten beobachtet werden können, ohne eine zweite, separate Verbindung von außen aufbauen zu müssen.

Dieser Ansatz eignet sich besonders gut, um zu verifizieren, dass eine im Browser sichtbare UI-Aktualisierung, etwa eine live aktualisierte Lagerbestandsanzeige im Hyvä-Frontend, tatsächlich auf einer im Browser empfangenen WebSocket-Nachricht beruht, statt allein die resultierende DOM-Änderung zu prüfen und dabei die zugrunde liegende WebSocket-Kommunikation unbeachtet zu lassen.

test('Live-Lagerbestand aktualisiert die UI über WebSocket', async ({ page }) => {
  const wsMessages = [];
  page.on('websocket', (ws) => {
    ws.on('framereceived', (frame) => wsMessages.push(JSON.parse(frame.payload)));
  });

  await page.goto('/catalog/product/view/id/123');
  await page.waitForFunction(() => wsMessages?.length > 0).catch(() => {});

  await expect(page.locator('[data-testid="stock-badge"]')).toBeVisible();
});

8. Mehrere gleichzeitige Verbindungen und Skalierungsverhalten testen

Ein Webshop mit Live-Lagerbestandsanzeige oder einem Chat-Feature muss typischerweise nicht nur eine einzelne, sondern gleichzeitig hunderte oder tausende WebSocket-Verbindungen zuverlässig bedienen können, weshalb ein gezielter Lasttest mehrere parallele Client-Verbindungen im selben Testlauf öffnet und prüft, ob eine per Broadcast versendete Nachricht tatsächlich bei jeder einzelnen Verbindung korrekt und ohne spürbare Verzögerung ankommt, statt sich auf einen Test mit nur einer einzigen Verbindung zu verlassen, der ein unter Last auftretendes Skalierungsproblem gar nicht aufdecken könnte.

Ebenso wichtig wie das Verhalten unter Last ist die Prüfung, dass der Server geschlossene Verbindungen tatsächlich vollständig bereinigt, statt sie als sogenannte Zombie-Verbindungen im Speicher zu behalten, was sich durch einen Test nachweisen lässt, der eine definierte Anzahl an Verbindungen öffnet, sie anschliessend wieder schließt und über eine Server-Metrik oder eine interne Health-Check-Route verifiziert, dass die aktive Verbindungsanzahl danach wieder auf den ursprünglichen Ausgangswert zurückgeht.

9. WebSocket-Testebenen im Überblick

Die folgende Tabelle vergleicht die vorgestellten Testebenen für WebSocket-Kommunikation.

10. Zusammenfassung

11. FAQ: WebSocket-Testing: Das Wichtigste auf einen Blick