Ausführungsgeschwindigkeit von Unit-Tests (wie viele Tests pro Sekunde?)

https://stackoverflow.com/questions/10486

08-06-2019
|

Frage

Welche Ausführungsrate streben Sie mit Ihren Unit-Tests an (# Test pro Sekunde)?Wie lange ist zu lang für einen einzelnen Unit-Test?

Mich würde interessieren, ob die Leute bestimmte Schwellenwerte haben, um festzustellen, ob ihre Tests zu langsam sind, oder liegt das nur daran, dass die Reibung einer lang laufenden Testsuite Sie überwältigt?

Wenn Sie schließlich entscheiden, dass die Tests schneller ausgeführt werden müssen, welche Techniken verwenden Sie, um Ihre Tests zu beschleunigen?

Notiz:Integrationstests sind natürlich wieder eine andere Sache.Es handelt sich ausschließlich um Unit-Tests, die so oft wie möglich ausgeführt werden müssen.

Zusammenfassung der Antworten: Vielen Dank für die tollen Antworten bisher.Die meisten Ratschläge scheinen zu lauten, machen Sie sich keine Sorgen um die Geschwindigkeit – konzentrieren Sie sich auf die Qualität und führen Sie sie nur selektiv aus, wenn sie zu langsam sind.Zu den Antworten mit spezifischen Zahlen gehörte das Anstreben von <10 ms bis zu 0,5 und 1 Sekunde pro Test oder einfach die Einhaltung der gesamten Reihe häufig durchgeführter Tests unter 10 Sekunden.

Ich bin mir nicht sicher, ob es richtig ist, eine davon als „akzeptierte Antwort“ zu markieren, wenn sie alle hilfreich sind :)

Lösung

Alle Unit-Tests sollten in weniger als einer Sekunde ausgeführt werden (das heißt, alle Unit-Tests zusammen sollten in 1 Sekunde ausgeführt werden).Ich bin mir sicher, dass dies praktische Grenzen hat, aber ich hatte ein Projekt mit 1000 Tests, die auf einem Laptop so schnell ausgeführt wurden.Sie werden diese Geschwindigkeit wirklich wollen, damit Ihre Entwickler keine Angst davor haben, einen Kernteil des Modells umzugestalten (d. h. ich gehe mir einen Kaffee holen, während ich diese Tests durchführe ... 10 Minuten später kommt er zurück).

Diese Anforderung zwingt Sie auch dazu, Ihre Anwendung korrekt zu gestalten.Dies bedeutet, dass Ihr Domänenmodell rein ist und keine Verweise auf irgendeine Art von Persistenz (Datei-E/A, Datenbank usw.) enthält.Bei Unit-Tests geht es darum, diese Geschäftsbeziehungen zu testen.

Das bedeutet nicht, dass Sie das Testen Ihrer Datenbank oder Persistenz ignorieren.Aber diese Probleme sind jetzt isoliert hinter Repositorys, die separat mit Integrationstests getestet werden können, die sich in einem separaten Projekt befinden.Sie führen Ihre Komponententests ständig durch, wenn Sie Domänencode schreiben, und führen Ihre Integrationstests dann einmal beim Einchecken aus.

Andere Tipps

Wenn es sich ausschließlich um Unit-Tests handelt, würde ich mehr auf Vollständigkeit als auf Geschwindigkeit abzielen.Wenn die Laufzeit Probleme verursacht, teilen Sie den Test in verschiedene Projekte/Klassen usw. auf und führen Sie nur die Tests aus, die sich auf das beziehen, woran Sie gerade arbeiten.Lassen Sie den Integrationsserver beim Einchecken alle Tests ausführen.

Das Ziel sind Hunderte von Tests pro Sekunde.Der Weg dorthin führt über die Anleitung von Michael Feather Regeln für Unit-Tests.

Ein wichtiger Punkt, der in der Vergangenheit zur Sprache kam CITCON Die Diskussion ist, dass Sie, wenn Ihre Tests nicht so schnell sind, höchstwahrscheinlich nicht die Designvorteile von Unit-Tests nutzen können.

Ich konzentriere mich eher auf die Lesbarkeit meiner Tests als auf die Geschwindigkeit.Ich versuche jedoch immer noch, sie einigermaßen schnell zu machen.Ich denke, wenn sie in der Größenordnung von Millisekunden laufen, ist alles in Ordnung.Wenn sie pro Test eine Sekunde oder länger laufen ...Dann tun Sie möglicherweise etwas, das optimiert werden sollte.

Langsame Tests werden erst dann zu einem Problem, wenn das System ausgereift ist und der Build mehrere Stunden in Anspruch nimmt. Dann ist es wahrscheinlicher, dass Sie auf das Problem vieler langsamer Tests stoßen, statt auf ein oder zwei Tests, die Sie leicht optimieren können. .Daher sollten Sie wahrscheinlich SOFORT aufpassen, wenn Sie viele Tests sehen, die jeweils Hunderte von Millisekunden (oder schlimmer noch Sekunden) laufen, anstatt zu warten, bis die Hunderte von Tests diesen langen Punkt erreichen (an welchem Punkt das auch der Fall sein wird). wird es wirklich schwierig sein, das Problem zu lösen).

Dennoch verkürzt sich dadurch nur die Zeitspanne, bis Ihr automatisierter Build Fehler ausgibt ...Das ist in Ordnung, wenn es eine Stunde später (oder sogar ein paar Stunden später) ist, denke ich.Das Problem besteht darin, sie vor dem Einchecken auszuführen. Dies kann jedoch vermieden werden, indem Sie eine kleine Teilmenge der auszuführenden Tests auswählen, die sich auf das beziehen, woran Sie gerade arbeiten.Stellen Sie einfach sicher, dass Sie den Build reparieren, wenn Sie Code einchecken, der Tests unterbricht, die Sie nicht ausgeführt haben!

Wir sind derzeit bei 270 Tests in etwa 3 Sekunden.Es gibt wahrscheinlich etwa 8 Tests, die Datei-E/A durchführen.

Diese werden automatisch ausgeführt, wenn unsere Bibliotheken erfolgreich auf dem Computer jedes Ingenieurs erstellt wurden.Wir führen umfangreichere (und zeitaufwändigere) Rauchtests durch, die jede Nacht von der Baumaschine durchgeführt werden oder manuell auf der Maschine eines Ingenieurs gestartet werden können.

Wie Sie sehen, haben wir das Problem, dass Tests zu zeitaufwändig sind, noch nicht erreicht.10 Sekunden sind für mich der Punkt, an dem es anfängt, aufdringlich zu werden, wenn wir anfangen, uns zu nähern, dass es etwas ist, das wir uns ansehen werden.Wir werden wahrscheinlich die Bibliotheken der unteren Ebene, die robuster sind, da sie sich selten ändern und wenige Abhängigkeiten haben, in die nächtlichen Builds oder eine Konfiguration verschieben, in der sie nur von der Build-Maschine ausgeführt werden.

Wenn Sie feststellen, dass die Durchführung von etwa hundert Tests mehr als ein paar Sekunden dauert, müssen Sie möglicherweise prüfen, was Sie als Komponententest klassifizieren und ob es besser als Rauchtest behandelt werden sollte.

Ihre Laufleistung wird natürlich je nach Entwicklungsbereich sehr unterschiedlich sein.

Datenpunkt – Python-Regressionstests

Hier sind die Zahlen auf meinem Laptop zum Ausführen von „make test“ für Python 2.5.2:

Anzahl der Tests:3851 (ungefähr)
Ausführungszeit:9 Min., 6 Sek
Ausführungsrate:7 Tests/Sek

Ich beurteile meine Unit-Tests pro Test, nicht anhand der Anzahl der Tests pro Sekunde.Die von mir angestrebte Rate beträgt 500 ms oder weniger.Wenn es darüber liegt, werde ich mir den Test ansehen, um herauszufinden, warum es so lange dauert.

Wenn ich denke, dass ein Test zu langsam ist, bedeutet das normalerweise, dass er zu viel leistet.Daher reicht es normalerweise aus, den Test einfach umzugestalten, indem man ihn in mehrere Tests aufteilt.Ein anderes Mal ist mir aufgefallen, dass meine Tests langsam laufen, wenn der Test einen Engpass in meinem Code zeigt und dann eine Umgestaltung des Codes angebracht ist.

Da war ein guter Artikel dazu von Power Of Two Games, den Autoren von UnitTest++.

Wie lange ist für einen einzelnen Einheiten -Test zu lang?

Ich würde sagen, es hängt von der Kompilierungsgeschwindigkeit ab.Normalerweise führt man die Tests bei jedem Kompilieren aus.Das Ziel des Unit-Tests besteht nicht darin, langsamer zu werden, sondern eine Botschaft zu vermitteln.nichts kaputt, weitermachen" (oder "etwas ist kaputt gegangen, STOP").

Ich kümmere mich nicht um die Geschwindigkeit der Testausführung, bis das etwas nervig wird.

Die Gefahr besteht darin, dass die Tests nicht mehr ausgeführt werden, weil sie zu langsam sind.

Wenn Sie entscheiden, dass die Tests schneller laufen müssen, welche Techniken verwenden Sie, um Ihre Tests zu beschleunigen?

Als Erstes gilt es herauszufinden, warum sie zu langsam sind Liegt das Problem in den Unit-Tests oder im zu testenden Code?

Ich würde versuchen, die Testsuite in mehrere logische Teile zu unterteilen und nur den Teil auszuführen, der vorhanden ist angeblich von dem Code betroffen, den ich bei jeder Kompilierung geändert habe.Ich würde die anderen Suiten seltener betreiben, vielleicht einmal am Tag, oder wenn ich Zweifel hatte, hätte ich etwas kaputt machen können, und zumindest vor der Integration.

Einige Frameworks bieten die automatische Ausführung spezifischer Komponententests basierend auf Heuristiken wie dem Zeitpunkt der letzten Änderung.Für Ruby und Rails bietet AutoTest eine viel schnellere und reaktionsschnellere Ausführung der Tests – wenn ich ein Rails-Modell speichere app/models/foo.rb, die entsprechenden Unit-Tests in test/unit/foo_test.rb geh los.

Ich weiß nicht, ob es etwas Ähnliches für andere Plattformen gibt, aber es würde Sinn machen.

Eine der wichtigsten Regeln für Unit-Tests ist, dass sie ausgeführt werden sollten schnell.

Wie lange ist zu lang für einen einzelnen Unit-Test?

Entwickler sollten in der Lage sein, die gesamte Suite von Unit-Tests in Sekunden und auf keinen Fall in Minuten und Minuten auszuführen.Entwickler sollten sie ohnehin schnell ausführen können, nachdem sie den Code geändert haben.Wenn es zu lange dauert, machen sie sich nicht die Mühe, sie durchzuführen, und Sie verlieren einen der Hauptvorteile der Tests.

Welche Ausführungsrate streben Sie mit Ihren Unit-Tests an (# Test pro Sekunde)?

Sie sollten darauf abzielen, dass jeder Test in der Größenordnung von Millisekunden ausgeführt wird. Alles über 1 Sekunde testet wahrscheinlich zu viel.

Wir haben derzeit etwa 800 Tests, die in weniger als 30 Sekunden laufen, also etwa 27 Tests pro Sekunde.Dazu gehört auch die Zeit, die zum Starten des mobilen Emulators benötigt wird, um sie auszuführen.Die meisten dauern jeweils 0-5 ms (wenn ich mich richtig erinnere).

Wir haben ein oder zwei, die etwa 3 Sekunden dauern, was wahrscheinlich Kandidaten für die Überprüfung sind, aber das Wichtigste ist, dass die gesamte Testsuite nicht so lange dauert, dass sie die Entwickler davon abhält, sie auszuführen, und unsere kontinuierliche Ausführung nicht wesentlich verlangsamt Integrationsaufbau.

Wir haben auch ein konfigurierbares Timeout-Limit von 5 Sekunden – alles, was länger dauert, schlägt fehl.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow