2009-05-30 15 views
3

Hallo in meinem Projekt haben wir Hunderte von Testfällen.Diese Testfälle sind Teil des Build-Prozesses, der bei jedem Check-in ausgelöst wird und sendet Mail an unsere Entwickler-Gruppe.Dieses Projekt ist ziemlich groß und ist seit mehr als fünf Jahren.
Jetzt haben wir so viele Testfälle, dass Build dauert mehr als eine Stunde. Einige der Testfälle sind nicht richtig strukturiert und nach Refactoring konnte ich die Laufzeit wesentlich reduzieren, aber wir haben Hunderte von Testfällen und Refactoring sie eins nach dem anderen scheint etwas zu viel.
Jetzt starte ich einige der Testfälle (die wirklich lange dauern) nur als Teil der nächtlichen Build und nicht als Teil jedes Checkins.
Ich bin neugierig wie andere Jungs das schaffen.Wie man Build-Zeit in TDD verwaltet

Antwort

3

Ich glaube, es war in "Effektive Arbeit mit Legacy-Code", dass er sagte, wenn Ihre Test-Suite länger als ein paar Minuten dauert, wird Entwickler zu langsam verlangsamen und die Tests werden vernachlässigt werden. Klingt, als würdest du in diese Falle fallen.

Laufen Ihre Testfälle gegen eine Datenbank? Dann ist das wahrscheinlich die größte Quelle von Leistungsproblemen. In der Regel sollten Testfälle nach Möglichkeit keine E/A-Operationen durchführen. Mit Dependency Injection können Sie ein Datenbankobjekt durch Mock-Objekte ersetzen, die den Datenbankabschnitt Ihres Codes simulieren. Damit können Sie den Code testen, ohne sich Gedanken darüber machen zu müssen, ob die Datenbank korrekt eingerichtet ist.

Ich empfehle Working Effectively with Legacy Code von Michael Feathers. Er beschreibt, wie Sie mit vielen Kopfschmerzen umgehen, ohne dass Sie den Code auf einmal umgestalten müssen.

UPDATE:

Eine weitere mögliche Hilfe wäre so etwas wie NDbUnit sein. Ich habe es noch nicht ausgiebig verwendet, aber es sieht vielversprechend aus: http://code.google.com/p/ndbunit/

+0

Eine mögliche alternative Lösung für die db-gebundenen Tests ist die Verwendung einer In-Memory-Datenbank. Dies ist offensichtlich mit einer neuen Reihe von Problemen verbunden, ist aber eine Lösung, und der Erfolg hängt davon ab, wie viel Code von einer einzelnen RDBMS-Implementierung abhängt. –

+0

Nun, es scheint mir eine gute Idee zu sein und ich mache mir auch keine Gedanken über die Implementierung einzelner RDBMS, da wir nicht vorhaben, uns von Oracle zu entfernen.
Die einzige Sache, die sich Sorgen macht, ist, dass alle db-Constraints in meory Db und in Sync mit der tatsächlichen db gesetzt sind.
Hinweis: Können Sie auf etwas in Memeroy Db, die Oracle nah ist, zeigen, so dass mein Test env und tatsächliche Prod env synchron sind. – Khangharoth

0

Vielleicht könnten Sie in Betracht ziehen, Ihre Orakel-Datenbank zu behalten, aber sie von einem RAM-Laufwerk laufen zu lassen? Es müsste nicht groß sein, weil es nur Testdaten enthalten würde.

0

Wir haben etwa 1000 Tests, ein großer Prozentsatz von denen, die über REST kommunizieren und Datenbank schlagen. Die Gesamtlaufzeit beträgt ca. 8 Minuten. Eine Stunde scheint übertrieben, aber ich weiß nicht, was Sie tun und wie komplex Ihre Tests sind.

Aber ich denke, es gibt einen Weg, um Ihnen zu helfen. Wir verwenden TeamCity und es hat eine gute Fähigkeit, mehrere Build-Agenten zu haben. Was Sie tun könnten, ist Ihr Testprojekt in Teilprojekte aufzuteilen, wobei jedes Teilprojekt nur eine Anzahl von Tests enthält. Sie können JNunit/NUnit-Kategorien verwenden, um sie zu trennen. Dann würden Sie TeamCity so konfigurieren, dass jeder Agent nur eine Art von Teilprojekt erstellt. Auf diese Weise würden Sie parallele Tests durchführen. Mit wenigen Agenten (Sie erhalten 3 kostenlos) sollten Sie in der Lage sein, 20 Minuten zu erreichen, was sogar akzeptabel sein könnte. Wenn Sie jeden Agenten in die VM einbinden, benötigen Sie möglicherweise nicht einmal zusätzliche Maschinen, Sie benötigen nur viel RAM.

Verwandte Themen