Wie mit langer Laufzeit Unit Tests umgehen?

https://stackoverflow.com/questions/368622

21-08-2019
|

Frage

Ich habe über 100 Unit-Tests und mit einer Abdeckung von 20% erhält, die ich die Abdeckung zu erhöhen ich versuche, und auch dies ist ein Projekt in der Entwicklung so immer wieder neue Tests hinzugefügt wird.

Zur Zeit läuft meine Tests nach jedem Build nicht möglich ist, sie etwa 2 Minuten dauern.

Test beinhaltet:

Datei lesen aus den Testordner (data-driven Stil einige HTTP Sachen zu simulieren)
Doing tatsächliche HTTP-Anfragen an einem lokalen Web-Server (dies ist ein großer Schmerz zu verspotten, so werde ich nicht)
Nicht alle von ihnen Komponententests aber es gibt auch ziemlich kompliziert Multithreaded-Klassen, die getestet werden müssen, und ich teste das Gesamtverhalten des Tests. Die als Funktionsprüfung in Betracht gezogen werden können, sondern müssen auch jedes Mal ausgeführt werden.

Die meisten Funktionen erfordert HTTP Lesen, TCP usw. tun kann ich sie nicht ändern, weil das die ganze Idee des Projekts ist, wenn ich diese Tests ändern wird es sinnlos sein Zeug zu testen.

Auch glaube ich nicht, dass ich die schnellsten Tools haben Unit-Tests laufen. Meine aktuelle Setup verwendet VS TS mit Gallio und nUnit als Rahmen. Ich denke, VS TS + Gallio ein bisschen langsamer als andere auch.

Was würden Sie mir empfehlen, dieses Problem zu beheben? Ich möchte Komponententests auszuführen, nachdem jedes Bisschen btu ändert sich zur Zeit dieses Problem meine Fluss unterbrochen wird.

Weitere Klärung Edit:

-Code ist sehr verbunden! Leider ändern kann, wie ein riesiger refatoring Prozess. Und es gibt ein Hühnerei Syndrom darin, wo ich Unit-Tests benötigen einen großen Code Refactoring so, aber ich kann nicht mehr Unit-Tests haben, wenn ich es nicht Refactoring:)

Sehr gekoppelt Code erlaubt mir nicht, Tests in kleinere Stücke aufzuteilen. Ich teste nicht auch private Sachen, es ist persönliche Entscheidung, die mir erlauben, so viel schneller zu entwickeln und immer noch eine große Menge an Nutzen zu gewinnen.

Und ich kann bestätigen, dass alle Unit-Tests (mit entsprechender Isolierung) recht schnell tatsächlich, und ich weiß nicht ein Performance-Problem mit ihnen haben.

Weitere Klarstellung:

Und ich kann bestätigen, dass alle Unit-Tests (mit entsprechender Isolierung) recht schnell tatsächlich, und ich weiß nicht ein Performance-Problem mit ihnen haben.

Lösung

klingen, da sie nicht wie Unit-Tests zu mir, sondern eher wie Funktionstests. Das ist in Ordnung, Funktionsprüfung zu automatisieren ist gut, aber es ist ziemlich üblich für Funktionstests langsam. Sie testen das ganze System (oder Teile davon).

Unit-Tests sind in der Regel schnell sein, weil sie eine Sache von allem anderen isoliert zu testen sind. Wenn Sie die Dinge nicht losgelöst von allem anderen testen, sollten Sie bedenken, dass ein Warnzeichen, dass Sie Code ist auch fest gekoppelt .

Können Sie sagen, welche Tests Sie haben die Unit-Tests sind (Prüfung 1, was nur) vs. Funktionstests (Prüfung 2 oder mehr Dinge zur gleichen Zeit)? Welche sind schnell und welche sind langsam?

Andere Tipps

Sie können Ihre Tests in zwei Gruppen, eine für kurze Tests und eine für lang laufende Tests aufgeteilt, und führen Sie die lang laufende Tests seltener, während die kurzen Tests nach jeder Änderung ausgeführt wird. Other than that, spöttisch die Antworten von den Web-Server und anderen Anforderungen Ihrer Anwendung macht auf einen kürzeren Testlauf führen würde.

würde ich einen kombinierten Ansatz, um Ihr Problem empfehlen:

Häufig eine Teilmenge der Tests durchgeführt, die mit dem Code der Nähe sind Sie Änderungen (zB Tests aus dem gleichen Paket, Modul oder ähnlichem) zu machen. Seltene Tests ausführen, die aus dem Code entfernt werden weiter Sie gerade arbeiten.
Teilen Sie Ihre Suite in mindestens zwei: schnelles Laufen und langsam laufende Tests. Führen Sie die schnell laufenden Tests häufiger.
Betrachten wir einige der weniger wahrscheinlich mit Tests scheitern nur durch eine automatisierte Kontinuierliche Integration Server ausgeführt werden.
Techniken Lernen Sie die Leistung Ihrer Tests zu verbessern. Am wichtigsten ist durch durch schnellere Fakes Zugang zu langsamen Systemressourcen zu ersetzen. Zum Beispiel Strom Verwendung im Speicher anstelle von Dateien. Stub / verspotten den http-Zugang. etc.
Erfahren Sie, wie geringes Risiko Abhängigkeit verwenden Techniken zu brechen, wie jene, die in dem (sehr zu empfehlen) Buch „Effektives Arbeiten mit Legacy-Code“. Diese ermöglichen es Ihnen, effektiv Ihren Code mehr prüfbar ohne Anwendung hohe Risiko Refactorings zu machen (oft durch vorübergehend die tatsächliche Gestaltung noch schlimmer, wie Verkapselung zu brechen, bis Sie zu einem besseren Design mit dem Sicherheitsnetz von Tests Refactoring können).

Eines der wichtigsten Dinge, die ich aus dem Buch oben erwähnt gelernt: Es gibt keine Magie, die Arbeit mit Legacy-Code ist Schmerz und wird es immer sein Schmerz. Alles, was Sie tun können, ist diese Tatsache akzeptieren, und tun Sie am besten langsam aus dem Schlamassel dem Weg zur Arbeit.

Zuerst die sind nicht Unit-Tests.

Es gibt nicht viel von einem Punkt läuft Funktionstests wie die nach jeder kleinen Änderung. Nach einer beträchtlichen Änderung werden Sie Ihre Funktionstests ausgeführt werden.

Zweitens haben Sie keine Angst, den Http Teil der Anwendung zu verspotten. Wenn Sie wirklich Unit-Test sollen die Anwendung seines ein Muss. Wenn Ihr nicht bereit, das zu tun, Sie werden viel mehr Zeit zu verschwenden, Ihre eigentliche Logik zu testen, warten auf HTTP-Anfragen zu kommen und zu versuchen, die Daten einzurichten.

würde ich Ihre Integrationsebene Tests halten, aber danach streben, echte Unit-Tests zu erstellen. Dies wird Ihre Geschwindigkeit Probleme lösen. Real Unit-Tests haben keine DB-Interaktion, oder HTTP-Interaktion.

ich immer eine Kategorie für „LongTest“ verwenden. Diejenigen Tests werden jede Nacht und während des Tages nicht ausgeführt. So können Sie Ihre Wartezeit durch eine Menge schneiden kann. Versuchen Sie es:. Kategorie Ihre Unit-Tests

Es klingt wie Sie als auch die Erwartungen unter dem Entwicklungsteam verwalten müssen können.

Ich gehe davon aus, dass die Menschen mehr tun pro Tag erstellt und sind epxected Tests nach jedem Build ausgeführt werden. Sie könnten wir servieren auch Ihren Testplan wechseln einen Build mit Tests während des Mittagessen und dann noch über Nacht laufen zu lassen.

ich mit Brad darüber einig, dass diese wie funktionalen Tests klingen. Wenn Sie den Code ziehen können voneinander entfernt sein, dass wäre toll, aber bis dahin würde ich auf weniger häufiges Testen wechseln.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow