Smoke Tests und warum Agenten sie ständig schreiben

Ein Smoke Test ist eine kleine Menge von Prüfungen, die feststellen, ob ein deploytes System grundsätzlich lebt: Der Prozess ist gestartet, die Hauptseite liefert 200, ein Benutzer kann sich anmelden, und die Datenbank beantwortet eine Query. Er beurteilt nicht, ob die Software korrekt ist; er entscheidet, ob es die Zeit wert ist, die restliche Test-Suite laufen zu lassen.

Wenn Sie jahrelang in CI ausgeliefert haben, ohne diese Definition je zu benötigen, sind Sie damit nicht allein. Der Begriff taucht meist ohne Vorwarnung auf, und in letzter Zeit taucht er in Pull Requests auf: eine smoke.sh oder smoke.spec.ts, die ein Coding Agent nebenbei hinzugefügt hat, während er etwas anderes fertigstellte.

Dieser Artikel behandelt, was in einen Smoke Test gehört, wo er läuft, wie ein minimaler Smoke Test im Code aussieht, nach welchem Filter man Dinge daraus fernhält, und warum Agenten sie so zuverlässig produzieren.

Was ist ein Smoke Test?

Ein Smoke Test beantwortet eine einzige Frage — „Lebt dieser Build genug, um ihn weiter zu testen?” — und sein Name wird üblicherweise darauf zurückgeführt, neue Hardware unter Strom zu setzen und zu schauen, ob Rauch aufsteigt. In der Software ist die Form dieselbe: ein schneller, flacher Durchlauf über die Pfade, von denen jeder Benutzer abhängt, mit binärem Ergebnis und ohne Meinung zur Korrektheit.

Er steht außerhalb der üblichen Testpyramide, statt auf einer ihrer Ebenen zu sitzen; die Ebenen selbst werden in Integration Tests vs End-to-End Tests und Unit vs Integration Testing in JavaScript: What to Use When behandelt. Ein Smoke Test ist ein Gate vor diesen Suites, kein Teil von ihnen.

Wo läuft Smoke Testing?

Smoke Tests laufen an zwei Stellen: als erstes Gate in CI, bevor längere Suites starten, und unmittelbar nach einem Deployment, gegen die Umgebung, in die tatsächlich deployt wurde. Die zweite Platzierung ist diejenige, die sich wirklich auszahlt — und die am häufigsten übersprungen wird.

Einen Smoke Test gegen localhost laufen zu lassen, verfehlt seinen Zweck, denn die Fehler, für deren Aufdeckung er existiert, treten nur beim Deployment auf: eine fehlende Umgebungsvariable, eine Migration, die nie gelaufen ist, ein Asset-Bundle, das nie ausgeliefert wurde. Ein Prozess, der auf dem CI-Runner mit APP_URL=localhost und einer frischen In-Memory-Datenbank hochgefahren wurde, kann keinen dieser Fehlermodi aufweisen. So ein Lauf ist ein Boot-Check, und Boot-Checks sind nützlich, aber sie sind etwas anderes und Schwächeres. Ein lokaler Lauf gegen gemockte Services kann aus keinem der Gründe fehlschlagen, aus denen ein Deployment fehlschlägt — also sollte er den Namen auch nicht tragen.

Der Post-Deploy-Lauf ist außerdem der natürliche Auslöser für ein Rollback: AWS CodeDeploy führt Ihre Validierungsfunktion aus, sobald die neue Version Testverkehr bedient, und ein fehlgeschlagenes Ergebnis löst ein Rollback aus. Behalten Sie aber die Grenzen dieses Signals im Blick. Ein grüner Post-Deploy-Smoke-Test beweist, dass das System geantwortet hat, nicht dass die User Journey funktioniert; Session Replays der ersten echten Sessions nach einem Release anzuschauen, ist die Technik, die beides voneinander trennt, denn ein Checkout-Button, der wegen eines geänderten Chunk-Hashes eine Exception wirft, taucht in keinem Statuscode auf.

Wie sieht ein Smoke Test aus?

Eine vollständige Smoke-Suite kann ein einziges kurzes Skript sein, das ohne Mocks das echte deployte Ziel anspricht: ein begrenztes Warten auf den Health-Endpoint, ein authentifizierter Request und ein Read, der durch die Anwendung bis zur Datenbank geht.

#!/usr/bin/env bash
# smoke.sh: runs against the deployed target in $APP_URL, never localhost
set -euo pipefail

: "${APP_URL:?set APP_URL to the deployed base URL}"
: "${SMOKE_USER:?}" "${SMOKE_PASS:?}"

status() { curl --silent --output /dev/null --write-out '%{http_code}' "$@"; }

# 1. Wait for the process to come up. This absorbs container start-up, nothing else.
for _ in $(seq 1 "${SMOKE_RETRIES:-10}"); do
  [ "$(status "$APP_URL/health")" = "200" ] && break
  sleep 3
done
[ "$(status "$APP_URL/health")" = "200" ] || { echo "health: not 200"; exit 1; }

# 2. Login. Assert the one status your app returns (200 for a JSON API, 302 for a form post).
code=$(status --data-urlencode "email=$SMOKE_USER" \
              --data-urlencode "password=$SMOKE_PASS" "$APP_URL/login")
[ "$code" = "200" ] || { echo "login: got $code, expected 200"; exit 1; }

# 3. A real read through the app, with the credentials the app was deployed with.
body=$(curl --silent --fail "$APP_URL/api/products?limit=1") || { echo "query: request failed"; exit 1; }
[ -n "$body" ] || { echo "query: empty body"; exit 1; }

echo "smoke: ok"

Der status-Helper nutzt curls --write-out '%{http_code}', um den Response-Code zu erfassen, während --output /dev/null den Body verwirft. set -euo pipefail sorgt dafür, dass das Skript beim ersten Fehler abbricht. Die Retry-Schleife existiert nur, um die Startzeit nach einem Deployment abzufedern; sie ist kein Mittel, um über eine instabile Prüfung hinwegzutäuschen.

Jede Assertion benennt genau einen exakten Status. Jeder Code in RFC 9110 trägt eine Bedeutung, daher ist eine Prüfung, die „irgendeine Antwort” akzeptiert, keine Prüfung: Ein 404 von einer Route, die existieren sollte, ist ein Deployment-Fehler, und ein 302 ist nur dort akzeptabel, wo der Vertrag einen Redirect vorsieht. Die dritte Prüfung ist wichtiger, als sie aussieht. Den Datenbankserver mit einem Tool wie pg_isready anzupingen bestätigt, dass der Server Verbindungen annimmt; ein Read durch die Anwendung bestätigt, dass die App die Datenbank mit dem Connection String, den Credentials und dem Schema erreichen kann, mit denen sie deployt wurde — und genau das ist die Fehlerklasse, für die Smoke Tests existieren.

Was nicht in einen Smoke Test gehört

Edge Cases, Geschäftslogik, alles Langsame und alles Instabile gehören nicht in einen Smoke Test. Eine Prüfung gehört nur dann in die Smoke-Suite, wenn alle drei Bedingungen erfüllt sind: Ihr Fehlschlagen hindert jeden Benutzer daran, überhaupt etwas zu tun, jeder Benutzer durchläuft sie, und sie kann während eines Deployments brechen. Eine Prüfung, die weniger als drei erfüllt, gehört in die Regressions-Suite. Diese Drei-Fragen-Systematik findet sich in der Guidance mindestens eines CI-Testing-Anbieters, und sie ist eine Heuristik, kein Standard.

Instabilität ist für sich genommen ein Ausschlusskriterium. Eine Smoke-Prüfung, die zufällig fehlschlägt, bringt dem Team bei, rote Gates einfach neu zu starten — und ein Gate, das man so lange neu startet, bis es grün wird, ist kein Gate mehr.

Warum schreiben Coding Agents ständig Smoke Tests?

Coding Agents schreiben Smoke Tests, weil ein Agent, der eine Aufgabe abschließt, ein günstiges, schnelles, eindeutiges Signal braucht, dass er nicht das gesamte System kaputtgemacht hat — und genau dieses Signal liefert ein Smoke Test. Ein Agent, der gerade Code bearbeitet hat, kann sich die vollständige Suite nicht bei jeder Iteration leisten und kann Korrektheit nicht durch bloßes Hinsehen beurteilen. Also greift er zu der Prüfung, die in Sekunden beantwortet „lebt es noch” und einen sauberen Exit Code zurückgibt.

Das ist kein Zufall. Anthropics Claude-Code-Dokumentation empfiehlt Entwicklern, dem Agenten etwas an die Hand zu geben, womit er seine eigene Arbeit überprüfen kann — sei es eine Test-Suite, ein Build, ein Linter oder ein kleines Skript. Mit einem Signal, das er selbst auslesen kann, arbeitet der Agent weiter und prüft nach, ohne darauf zu warten, dass ein Mensch den Fehler bemerkt. Ein Smoke-Skript passt genau auf diese Beschreibung, weshalb von Agenten geschriebene Repositories dazu neigen, eines hervorzubringen, selbst wenn das Team den Begriff nie verwendet hat. Das ist der Grund, warum Entwickler jetzt auf „Smoke Test” stoßen — oft, indem sie einen in einem Diff finden, den sie nicht selbst geschrieben haben.

Wenn einer in einem PR auftaucht, prüfen Sie ihn anhand von vier Fragen. Liest er die Ziel-URL aus einer Umgebungsvariablen, statt localhost hart zu verdrahten? Prüft er auf einen konkreten Status statt auf „kein Fehler”? Ist er in Sekunden fertig? Besteht jede Prüfung den oben beschriebenen Drei-Fragen-Filter? Ein von einem Agenten geschriebener Smoke Test, der an einer dieser Fragen scheitert, ist entweder ein Boot-Check oder ein Regressionstest mit dem falschen Etikett.

Der Fehlermodus: Die Suite wächst

Eine Smoke-Suite hört in dem Moment auf, ein Gate zu sein, in dem sie über ein paar Sekunden hinauswächst. Das Muster ist vorhersehbar: Jedes Feature fügt eine Prüfung hinzu, „nur für den Fall”, ein Agent fügt nach jeder Aufgabe eine weitere hinzu, und eines Tages braucht das Gate zwölf Minuten und die Leute beginnen, es zu überspringen. Ab diesem Punkt ist es eine langsame Regressions-Suite unter falschem Namen.

Die Lösung ist eine harte Obergrenze, wobei alles darüber in die Regression verschoben wird. Unsere empfohlene Voreinstellung ist eine Handvoll Prüfungen, in der Größenordnung von fünf, die in Sekunden fertig sind; TestingXperts setzt die äußerste Grenze bei zehn Minuten — darüber hinaus beginnen Teams, das Gate zu überspringen. Die exakte Zahl ist weniger wichtig als die Tatsache, dass sie festgeschrieben und im Review durchgesetzt wird, einschließlich des Reviews von Ergänzungen, die Agenten beigesteuert haben.

Fazit

Ein Smoke Test ist der kleinstmögliche Nachweis, dass ein Deployment lebt: Health, Login, ein echter Read, ausgeführt gegen die Umgebung, in die Sie tatsächlich ausgeliefert haben, fertig in Sekunden. Alles andere ist Regression. Wenn Ihnen das nächste Mal ein Agent eine smoke.sh hinlegt, prüfen Sie, ob sie eine echte URL anspricht, exakte Statuscodes prüft und unter der Obergrenze bleibt — und verdrahten Sie sie dann so, dass sie nach jedem Deployment läuft.

FAQs

Was ist der Unterschied zwischen einem Smoke Test und einem Health Check?

Ein Health Check ist ein einzelner Endpoint, den ein Orchestrator oder Load Balancer pollt, um zu entscheiden, ob Traffic geroutet oder ein Container neu gestartet wird; Kubernetes nennt diese Liveness- und Readiness-Probes. Ein Smoke Test läuft einmal pro Deployment, ruft diesen Endpoint plus einen Login und einen Datenbank-Read auf und gibt einen Exit Code zurück, der die Pipeline gated. Der Health-Endpoint ist die erste Assertion des Smoke Tests, kein Ersatz dafür.

Was ist der Unterschied zwischen Smoke Testing und Sanity Testing?

Smoke Testing ist breit und flach: Es prüft, ob die Kernpfade eines Builds leben, bevor tiefergehendes Testen beginnt. Sanity Testing ist in der klassischen QA-Terminologie eng und tief: Es verifiziert, dass ein bestimmter Fix oder eine bestimmte Änderung auf einem Build funktioniert, der den Smoke Test bestanden hat, und gilt oft als Teilmenge des Regressionstestens. In einer CI-Pipeline ist die Smoke-Suite das Gate; Sanity Checks gehören zur Regression.

Sollten Smoke Tests gegen die Produktion laufen, und ist das sicher?

Ja. Der Post-Deploy-Lauf sollte auf die Umgebung zielen, die Benutzer tatsächlich erreichen, einschließlich der Produktion, denn Deployment-Fehler zeigen sich nur dort. Halten Sie ihn sicher, indem Sie ein dediziertes, vorbefülltes Testkonto verwenden, das über CI-Secrets bereitgestellt wird, die Prüfungen auf einen Login und lesende Requests beschränken und alles ausschließen, was Daten schreibt oder E-Mails versendet. Wenn ein Schreibvorgang unvermeidlich ist, beschränken Sie ihn auf einen Test-Tenant und räumen Sie ihn im selben Skript wieder auf.

Kann ich einen Smoke Test in Playwright oder Cypress statt in einem Shell-Skript schreiben?

Ja, sofern er dieselben Regeln befolgt: die Basis-URL aus einer Umgebungsvariablen lesen, exakte Statuscodes oder sichtbare Elemente prüfen und in Sekunden fertig sein. Browser-Runner bringen pro Prüfung zusätzliche Start- und Seitenladezeit mit, halten Sie die Browser-Smoke-Suite also auf ein bis zwei Journeys beschränkt und belassen Sie HTTP-Prüfungen in curl. Legen Sie die Smoke-Spec in eine eigene Datei, damit CI sie ohne den Rest der Suite ausführen kann.