The Chromium Chronicle #2: Der Kampf gegen fehleranfällige Tests

Folge 2: von Vasilii in München (Mai 2019)
Vorherige Folgen

Instabile Tests sind ein häufiges Problem in Chrome. Sie die Produktivität anderer Entwickler beeinträchtigen und mit der Zeit deaktiviert werden. Deaktivierte Tests führen zu einer geringeren Testabdeckung.

Triagephase

Die INHABER von Verzeichnissen sind für die Behebung der instabilen Tests verantwortlich. Wenn Sie einen Fehler zu einem instabilen Test erhalten, nehmen Sie sich ein paar Minuten Zeit, kommentieren Sie den Fehler. Wenn Sie einen alten instabilen Test haben und Wenn unklar ist, was schiefgelaufen ist, aktivieren Sie den Test einfach wieder. Weisen Sie den Fehler so bald wie möglich neu zu, wenn es sich eindeutig um ein Problem in einer anderen Komponente handelt. Die Verantwortlichen dieser Komponente sollten das Scheitern besser einschätzen können,

Debugging-Phase

Eine Reihe von Befehlszeilen-Flags eignen sich für instabilen Tests zu beheben. Beispiel: --enable-pixel-output-in-tests die Benutzeroberfläche des Browsers.

Nutzen Sie Fallback-Tools, wenn durch den Debugger unzuverlässige Seiten verschwinden. Es ist dass der Test unter Debugger nie instabil ist. Protokollieren Sie in diesem Fall Anweisungen oder base::debug::StackTrace können praktisch sein.

Don'ts

Beachte neben Fehlern in der Produktion häufige Gründe für EXPECT__*-Fehler Code:

  • Falsche Erwartungen (z.B. bedeutet eine sichere Seite HTTPS; es kann sich stattdessen auch um einen lokalen Host handeln).
  • Race-Bedingungen aufgrund von Tests, die nicht auf das richtige Ereignis warten.

[Testen Sie nicht die Implementierung][nicht die Implementierung], sondern das Verhalten.

// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();

Die beiden Umläufe können sich in Zukunft in drei ändern, wodurch der Test instabil wird. Allerdings ist nur der Status des Geschäfts relevant. Verwenden Sie stattdessen einen Beobachter für die speichern.

Don'ts

Achten Sie auf häufige Muster wie die folgenden:

Submit TestPasswordForm();
// Wait until things settle down.
RunLoop().RunUntilIdle();
CheckCredentialPromptVisible();

Ein Snippet wie oben aus einem Browsertest ist mit ziemlicher Sicherheit falsch. Es gibt viele Ereignisse, die in verschiedenen Prozessen stattfinden sollten. bevor eine UI angezeigt wird.

Do

Das Problem wurde wie folgt behoben:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

Die obige Korrektur ist unter der Annahme richtig, WaitUntilCredentialPromptVisible() prüft die UI nicht. Die Browsertests sollten nicht von externen UI-Ereignissen wie „Focus Losts“ abhängig sein. oder „Fenster wurde in den Vordergrund“. Stellen Sie sich eine Implementierung vor, bei der die Aufforderung wird nur angezeigt, wenn das Browserfenster aktiv ist. Eine solche Implementierung wäre richtig: Die Überprüfung des tatsächlichen Fensters macht den Test jedoch instabil.

Nach der Korrektur

Sobald der Test behoben ist, führen Sie ihn hunderte Male lokal aus. Behalten Sie die Flakiness-Portal: