Ich arbeite an einer großen Lösung mit derzeit 60 Baugruppen. Es gibt viele Assemblys, die gemeinsame Teile für die Lösung definieren, und dann einige Eingangspunkt-Assemblies für das System.
TDD ist im Moment praktisch unmöglich, da eine Änderung einer einzelnen Zeile in der untersten Domänenschicht eine Wiederherstellung fast der gesamten Lösung erzwingt, da die Testbaugruppe auf verschiedene Schichten der Lösung verweist.
Was ist Best Practice, um die Build-Zeit von derzeit 75 Sekunden auf mehr zu reduzieren akzeptabel 5 Sekunden oder so? Dies wird TDD wieder möglich machen.
Beim Ausführen von Komponententests benötigen einige Klassen Mocks, die von Schnittstellen anderer Assemblys definiert sind und daher in der Testassembly referenziert werden müssen. Es ist also nicht immer möglich, einen einzigen Verweis auf die anderen Assemblies zu erhalten, außer auf der untersten Ebene der Lösung.
IMHO das Problem liegt hier: "Da die Testbaugruppe auf verschiedene Schichten der Lösung verweist."
Sie sollten eine Testbaugruppe pro Baugruppe haben, die Sie testen möchten.
Wenn Sie weiterhin auf viele Assemblys in jeder Ihrer Testassemblys verweisen, haben Sie ein anderes Problem: Sie erstellen Integrationstests. Das ist nicht das, was du in TDD machen willst.
Zusätzlich zu dem Update auf Ihre Frage:
Normalerweise würden Sie die Schnittstellen in einer anderen Assembly als die Implementierung definieren. Eine Änderung der Implementierung einer Klasse auf niedrigerer Ebene sollte also keine Auswirkungen auf die Klassen höherer Ebenen haben, die diese Schnittstellen verwenden ...
Andere Leute haben dir gesagt, du sollst umgestalten, toll, wenn du dazu in der Lage bist ...
Es gibt ein paar andere Dinge, die einfacher zu tun sind:
Kombinieren Sie kleine Projekte zu größeren Projekten, da beim Erstellen einer Lösung ein großer Aufwand pro Projekt entsteht. (Verwenden Sie nDepend falls erforderlich, um den Aufruf von Layern zu steuern, können Regeln in " Codeabfrage Sprache " und dann als Teil Ihres Builds überprüft)
Lassen Sie alle Projekte in einem bestimmten Ausgabeverzeichnis erstellen und setzen Sie dann "copy local" bei allen Projektreferenzen auf "false". Dies kann zu einer hohen Geschwindigkeit aufgrund reduzierter IO führen.
Schalten Sie Ihren Virenprüfer um, um zu sehen, ob er einen großen Unterschied macht; wenn ja, finde einen schnelleren Viruschecker , oder schließen Sie die "Hot" -Ordner von der Virenprüfung aus
Verwenden Sie den perforce monitor und das interne sys-Tool, um zu sehen, wie lange Ihre Kompilierungen dauern.
Betrachten Sie eine RAM-Disk, um das Ausgabeverzeichnis zu aktivieren.
Erwägen Sie die Verwendung einer SSD, das ist ein großer Gewinn und sie werden billiger.
Mehr Speicher kann manchmal eine große Wirkung haben - (reduziere den Widder in der Maschine, wenn du eine große Verlangsamung durch Entfernen eines kleinen Widders bekommst, kannst du eine große Geschwindigkeit durch Hinzufügen von mehr bekommen)
Entfernen Sie nicht benötigte Projektreferenzen (Sie müssen möglicherweise zuerst nicht benötigte "usings" entfernen)
(Ein schnellerer Build beschleunigt auch das Refactoring!)
Teilen Sie die gesamte Lösung in kleinere Lösungen auf, die schichtbasiert (oder sogar spezifischer) sind, und lassen Sie jeweils einen spezifischen Satz von Komponententests erstellen. Sie können wirklich nicht ernsthaft mit dieser Frage 60 Projekte in einer Lösung, warum jemand damit arbeiten möchte? Ist es eine häufige Aufgabe für Sie, innerhalb von einer Stunde etwa 10 davon zu ändern?
Bei TDD und großen Projekten ist in der Regel ein langsames Testen der Fehler das Problem, nicht die Kompilierzeit. Lassen Sie den gesamten Build-Prozess von einer speziellen Build-Maschine verarbeitet werden und führen Sie das gesamte Build & amp; Test der gesamten Einheit nur beim Einchecken.
Dies bringt Ihre Entwicklung zurück zu normalen TDD.
Tags und Links compilation c# performance tdd