Dev Proxy vs Unit Tests

Dev Proxy- und Komponententests dienen verschiedenen Zwecken in Ihrer Teststrategie. Beide sind zwar wertvoll, aber sie testen Ihre Anwendung auf grundsätzlich unterschiedliche Weise. Durch die gemeinsame Verwendung erhalten Sie eine umfassende Abdeckung des Verhaltens Ihrer Anwendung.

Verschiedene Testansätze

Komponententests testen isolierte Codestücke mit simulierten Abhängigkeiten. Wenn Sie einen Komponententest für Code schreiben, der eine API aufruft, modellieren Sie in der Regel den HTTP-Client, um vordefinierte Antworten zurückzugeben. Mit diesem Ansatz können Sie überprüfen, ob Ihr Code bestimmte Szenarien ordnungsgemäß verarbeitet.

Dev Proxy testet Ihre ausgeführte Anwendung mit simuliertem API-Verhalten. Anstatt Code zu simulieren, fängt Dev Proxy tatsächliche HTTP-Anforderungen ab und simuliert reale Bedingungen wie Fehler, Drosselung und Latenz. Dieser Ansatz testet Ihre Anwendung als Ganzes, einschließlich aller Ebenen zwischen Ihrem Code und der API.

Einsatzgebiete der jeweiligen Varianten

Verwenden Sie Komponententests , wenn Sie Folgendes ausführen möchten:

  • Testen des spezifischen Funktionsverhaltens und der Randfälle
  • Überprüfen Sie die Geschäftslogik in Isolation
  • Schnelles Feedback während der Entwicklung
  • Hohe Codeabdeckung erzielen
  • Testen bestimmter Fehlerbehandlungspfade

Verwenden Sie Dev Proxy , wenn Sie Folgendes ausführen möchten:

  • Testen Sie Ihre laufende Anwendung end-to-end
  • Simulieren von Bedingungen, die schwer zu reproduzieren sind, z. B. Drosselung oder Netzwerkprobleme
  • Testen sie reale Wiederholungslogik und Fehlerbehandlung auf allen Ebenen
  • Führen Sie Ihre Anwendung unter Last mit zufälligen Fehlern aus.
  • Überprüfen der Resilienz, ohne den Code zu ändern

Vorteile von Dev Proxy

Dev Proxy bietet gegenüber herkömmlichen Mocking-Methoden mehrere Vorteile:

  • Es sind keine Codeänderungen erforderlich. Sie müssen Ihre Anwendung nicht ändern, um Dev Proxy zu verwenden. Sie funktioniert auf Netzwerkebene, wobei HTTP-Anforderungen transparent abgefangen werden.
  • Funktioniert mit einer beliebigen HTTP-Bibliothek. Einige HTTP-Bibliotheken sind berüchtigt schwer zu simulieren. Bei Dev Proxy spielt es keine Rolle, welche Bibliothek Sie verwenden – RestSharp, HttpClient, Axios oder eine andere. Der Dev-Proxy fängt unabhängig von der Bibliothek den gesamten HTTP-Datenverkehr ab.
  • Testet die eigentliche Anwendung. Komponententests mit simulierten HTTP-Clients testen nicht das tatsächliche Wiederholungslogik-, Verbindungsbehandlungs- oder Timeoutverhalten. Dev Proxy testet Ihre echte Anwendung mit allen Abhängigkeiten.
  • Einfacher zu verstehende Fehler. Wenn Sie Fehler bei Bedarf in einer ausgeführten Anwendung auslösen können, ist es einfacher zu verstehen und zu debuggen, wie ihre Anwendung sie behandelt.
  • Simuliert komplexe Bedingungen. Dev Proxy kann Bedingungen simulieren, die schwer nachzuvollziehen sind, wenn man sie mit Mocks reproduzieren will, wie z. B. zufällige Fehler unter Last, allmähliche Drosselung oder sporadische Netzwerkprobleme.

Eine ergänzende Teststrategie

Der effektivste Ansatz kombiniert beide Testmethoden:

  • Verwenden Sie Komponententests für Logik. Schreiben Sie Komponententests, um Ihre Geschäftslogik, Datentransformationen und spezifische Fehlerbehandlungscodepfade zu überprüfen.
  • Verwenden Sie Dev Proxy für Resilienz. Verwenden Sie Dev Proxy, um zu überprüfen, ob Ihre Anwendung echte API-Bedingungen richtig verarbeitet – Drosselung, Fehler und langsame Antworten.
  • Verwenden Sie beide in CI/CD. Führen Sie Komponententests aus, um schnelles Feedback zu jedem Commit zu geben. Verwenden Sie Dev Proxy in Integrationstests, um Resilienzprobleme vor der Bereitstellung abzufangen.

Komponententests informieren Sie, ob Ihr Code korrekt ist. Dev Proxy teilt Ihnen mit, ob Ihre Anwendung robust ist. Sie benötigen beide.

Nächste Schritte

Was ist Chaostests?

  • Last updated on