My CI/CD-Pipeline lief 3 Monate lang durch – dann habe ich die Logs gelesen

Grüne Häkchen fühlen sich gut an. Jeder Pull Request war erfolgreich. Jedes Deployment hat funktioniert.

Dann meldete ein Nutzer eine defekte Funktion. Sie war bereits seit Wochen kaputt.

Ich öffnete die Pipeline-Logs. Unsere erfolgreichen Builds haben uns angelogen.

Unser Prozess sah perfekt aus:

  • Linting
  • Unit-Tests
  • Integrationstests
  • Build
  • Deployment

Jeder Schritt hatte monatelang eine Erfolgsquote von 100 %.

Der Export-Button tat beim Klicken nichts. Es erschien kein Fehler. Ich konnte die Ursache auf eine Änderung vor 11 Wochen zurückführen. Die Pipeline lief durch. Das Code-Review wurde genehmigt. Die Funktion war von Anfang an defekt.

Das Problem war nicht unser Code. Es war unser Testcode.

Unsere Integrationstests verwendeten für alles Mocks. Wir haben den gesamten Export-Service gemockt. Der Test prüfte den Mock anstatt des echten Codes. Der Mock gab immer einen Erfolgsstatus zurück.

Wir sind in die Over-Mocking-Falle getappt:

  • Unit-Tests: Alles gemockt, um die Einheit zu isolieren. Das ist okay.
  • Integrationstests: Alles gemockt, um Geschwindigkeit zu gewinnen. Das ist ein Fehler.
  • E2E-Tests: Diesen spezifischen Flow nicht abgedeckt.

Unsere Integrationstests waren lediglich teure Unit-Tests. Sie verifizierten, dass unsere Mocks funktionierten. Sie verifizierten nicht, dass unser Code funktionierte.

Ich habe drei Änderungen vorgenommen, um das zu beheben:

  1. Mocks auf Unit-Tests beschränken. Integrationstests müssen echte Datenbanken, APIs und Dateisysteme ansprechen. Wenn ein Test langsam ist, verstecke ihn nicht mit einem Mock. Nutze die Geschwindigkeit als Signal zur Optimierung.

  2. Contract Tests hinzufügen. Diese stellen sicher, dass deine Mocks dem Verhalten des echten Services entsprechen. Wenn ein Mock Daten zurückgibt, die ein echter Service nicht liefern würde, schlägt der Contract Test fehl.

  3. Echte Testabdeckung (Coverage) tracken. Wir haben aufgehört, nur auf einfache Erfolgsquoten zu schauen. Wir haben darauf geachtet, was die Tests tatsächlich prüfen. Unsere Coverage-Werte sanken von 94 % auf 67 %. Das war die ehrlichste Metrik, die wir hatten.

Eine grüne Pipeline bedeutet nicht, dass dein Code funktioniert. Sie bedeutet, dass deine Tests bestanden wurden. Das sind zwei verschiedene Dinge.

Die gefährlichsten Bugs sind diejenigen, bei denen deine Pipeline sagt, dass alles in Ordnung ist.

Stelle dir diese Fragen:

  • Fangen meine Tests Bugs ab oder bestätigen sie nur Mocks?
  • Integrieren meine Integrationstests tatsächlich?
  • Wenn ich alle Mocks entferne, wie viele Tests bestehen dann noch?
  • Messe ich Testabdeckung oder Vertrauen?

Eine Pipeline, die niemals fehlschlägt, ist nicht zuverlässig. Sie ist ungetestet.

Source: https://dev.to/kollittle/my-cicd-pipeline-passed-for-3-months-then-i-read-the-logs-4mbj