Wie oft sollte die gesamte Suite der Komponententests eines Systems ausgeführt werden?

8

Im Allgemeinen bin ich immer noch sehr eine Einheit, die Neophyten testet.

Übrigens können Sie diese Frage auch in anderen Foren wie xUnit.net usw. sehen weil es eine wichtige Frage für mich ist. Ich entschuldige mich im Voraus für mein Foto Kreuz Buchung; Ihre Meinungen sind sehr wichtig für mich und nicht jeder in diesem Forum gehört auch zu den anderen Foren.

Ich habe mir ein großes, zehn Jahre altes Legacy-System angeschaut, das über mehr als 700 Unit-Tests verfügt kürzlich geschrieben (700 ist nur ein kleiner Anfang). Die Tests werden zufällig geschrieben in MSTest, aber diese Frage gilt für alle Test-Frameworks AFAIK.

Als ich lief, via vs2008 "ALLE TESTS", war die endgültige Zählung nur sieben Tests.
Das ist ungefähr 1% der gesamten Tests, die bisher geschrieben wurden.

Weitere Informationen: Der ASP.NET MVC 2 RTM-Quellcode einschließlich seiner Komponententests,
ist verfügbar auf CodePlex; Diese Komponententests werden auch in MSTest geschrieben obwohl (irrelevant) Brad Wilson später dem ASP.NET MVC Team beigetreten ist als Senior-Programmierer. Alle 2000 plus-Tests werden ausgeführt, nicht nur einige.

FRAGE: Angesichts der Tatsache, dass AFAIK der Zweck von Unit-Tests ist es, Brüche zu identifizieren in der SUT, bin ich richtig zu denken, dass die "beste Praxis" ist immer,
oder zumindest sehr häufig alle Tests durchführen?

aktualisiert 2010-05-22

Zuerst, danke an alle, die ausgezeichnete Antworten geliefert haben. Deine Antworten bestätige meine allgemeine Schlussfolgerung, dass alle Komponententests nach jeder lokalen Neuerstellung ausgeführt werden das beste Verfahren unabhängig davon, ob man TDD (Test vorher) oder klassisch praktiziert Unit-Test (Test nach).

imho, es gibt mehr als eine beste Antwort auf diese Frage, aber AFAIK SO lässt Ich wähle nur einen aus, also habe ich, um fair zu sein, das Häkchen gesetzt Pete Johns dafür, der Erste zu sein und die meisten Stimmen von der SO zu bekommen Gemeinschaft. Finnlands Esko Luontola gab ebenfalls eine gute Antwort (hoffe ich er wird nicht in Vulkanasche begraben) und zwei sehr gute Verbindungen, die sind deine Zeit wert imho; auf jeden Fall die Verbindung zu F.I.R.S.T. ist für mich inspirierend; AFAIK, nur xUnit.net in der .NET-Welt bietet das "Any Order, Anytime". Eskos zweiter Link ist ein wirklich exzellentes 92-minütiges Video "Integrationstests sind ein Betrug" präsentiert von J. B. (Joe) Rainsberger ( Ссылка ) wo es mehr Inhalt gibt meine Zeit wert). BTW, Eskos Weblog ist auch einen Besuch Ссылка wert.

    
gerryLowry 21.05.2010, 13:22
quelle

5 Antworten

12

Da Sie diese Frage 'TDD' getaggt haben, sollten alle Komponententests für das zu entwickelnde Modul mit jeder Kompilierung ausgeführt werden (und übergeben Sie das neueste, bis Sie es bestehen). Unit-Tests in anderen Modulen sollten nicht durch die Entwicklung im aktuellen Modul unterbrochen werden oder sie testen zu viel.

Es sollte auch eine kontinuierliche Integrationsschleife vorhanden sein, um sicherzustellen, dass alle der Tests bei jedem Einchecken in Ihr Versionskontrollsystem ausgeführt werden. Dies wird Brüche früh auffangen.

Zumindest sollte ein nächtlicher Build jeden Test laufen und jeder Bruch sollte als erstes eines Morgens behoben werden. Toleriere keine Komponententestfehler!

    
Johnsyweb 21.05.2010, 13:31
quelle
7

Es sollte möglich sein, die Komponententests schnell auszuführen, damit Sie sie nach jeder einfachen Änderung ausführen können. Wie gesagt bei Ссылка

  

Tests müssen schnell sein. Wenn Sie zögern, die Tests nach einem einfachen Einleiner-Wechsel durchzuführen, sind Ihre Tests viel zu langsam. Mach die Tests so schnell, dass du sie nicht berücksichtigen musst. [...] Ein Software-Projekt wird schließlich Zehntausende von Komponententests haben, und die Teammitglieder müssen sie jede Minute ohne Schuld ausführen. Sie machen die Mathematik.

Persönlich ist meine Schmerzgrenze ungefähr 5-10 Sekunden; Wenn es länger dauert, alle Komponententests zu kompilieren und auszuführen, wird es mich sehr nerven und verlangsamen.

Wenn es langsame Integrationstests gibt ( die vermieden werden sollten ), können sie auf jedem ausgeführt werden Check-In. Am besten vom Entwickler, bevor er eincheckt und dann noch einmal auf dem Continuous Integration Server.

    
Esko Luontola 21.05.2010 13:32
quelle
3

Die beste Vorgehensweise ist sicherlich, die Unit-Tests vor oder beim Check-in durchzuführen. Natürlich ist es möglich, dass die Unit-Tests vor dem Check-In bestanden haben, aber dann, wenn ein Teil der eigentlichen Code-Basis andere Updates zusammenbrachte Komponententest, also sollten sie wirklich auf dem vollständigen Code auch ausgeführt werden.

Es gibt Tools, die Ihnen dabei helfen, wie zB TeamCity, mit dem Sie eingecheckt werden können, wo es die Tests vor dem Einchecken ausführt und nach jeder Überprüfung einen Build ausführt, einschließlich Tests, falls dies so konfiguriert ist in. (Diese Praxis wird kontinuierliche Integration genannt).

Unabhängig von der Best Practice ist es in Wirklichkeit so, dass es viel schwieriger ist, die Ursache des Fehlers aufzuspüren, wenn Sie Ihre Tests zu spät durchführen. Im Laufe der Zeit werden ausfallende Tests entweder auskommentiert oder es werden sogar schlechtere Tests zugelassen zu bleiben, so dass neue versagende Tests unbemerkt bleiben.

    
Yishai 21.05.2010 13:39
quelle
2

Da Komponententests automatisiert werden können, würde ich vorschlagen, sie so häufig wie möglich auszuführen, besonders wenn Sie so viele haben.

Eine bewährte Methode besteht darin, Komponententests als Teil eines nächtlichen Build-Prozesses auszuführen.

    
Justin Ethier 21.05.2010 13:24
quelle
1

Idealerweise sollten die Komponententests als Teil jedes Builds und vor jedem Einchecken des geänderten Codes ausgeführt werden.

Bei einer großen Anzahl von Tests kann dies jedoch viel Zeit in Anspruch nehmen, also müssen Sie in der Lage sein, dies zu verwalten.

Nur eine Teilmenge von test kann ausreichen, wenn die Teilmenge gedreht wurde und die vollständige Menge einmal pro Woche ausgeführt wird, aber immer noch Zeit für eine brechende Änderung bleibt Codebasis für ein paar Tage.

Sie müssen alle Tests vor dem Einchecken ausführen, da Sie nicht anders wissen können, dass sich Ihre Änderung nicht nachteilig auf einen anderen Teil des Codes ausgewirkt hat. Ich habe das immer wieder gesehen und ohne Unit-Tests ist es schwer zu erkennen.

    
ChrisF 21.05.2010 13:25
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Wie wird der formatierte Kalendertyp in JSTL angezeigt?