So vereinfachen Sie TDD mit MSTest / VS2008

Question

Ich habe immer wieder gelesen, dass TDD/test first bei MSTest schwieriger ist als bei anderen Test-Frameworks wie nUnit, MBUnit usw.Welche empfohlenen manuellen Problemumgehungen und/oder Bits von Drittanbietern schlagen Sie vor, wenn MSTest aufgrund von Infrastrukturrichtlinien die einzige Option ist?Ich frage mich hauptsächlich, was VS 2008 Team Suite betrifft, aber ich denke, dass auch Tipps für VS 2008 Pro und höher geeignet wären, da einige MSTest-Funktionen jetzt auch in diesen Versionen enthalten sind.

Answer 1

MSTest ist sicherlich nicht so effizient oder erweiterbar wie einige der Open-Source-Frameworks, aber es ist praktikabel.Da es bei der Frage darum geht, mit MSTest das Leben einfacher zu machen und nicht um Alternativen, hier meine MSTest-Tipps.

• Verknüpfungen.Nehmen Sie sich, wie Haacked sagte, ein paar Sekunden Zeit, um die Tastenkombinationen zu lernen.
• Aktueller Kontext.Da MSTest so langsam ist, führen Sie Tests nach Möglichkeit nur im aktuellen Kontext aus.(STRG+R, STRG+T).Wenn sich Ihr Cursor in einer Testmethode befindet, wird die Methode nur ausgeführt.Befindet sich Ihr Cursor außerhalb einer Methode, aber in einer Testklasse, wird nur der Test ausgeführt.Und mit Namespace usw. usw
• Effiziente Tests und Organisation.Es ist hundelangsam.Machen Sie die Dinge so gut wie möglich, indem Sie effiziente Tests schreiben.Verschieben Sie langsame Tests in andere Testklassen oder Projekte, damit Sie die schnellen Tests häufiger ausführen können.
• Testen mit WCF.Wenn Sie Dienste testen, stellen Sie sicher, dass Sie Tests DEBUGIEREN und nicht Tests ausführen, damit Visual Studio die ASP.NET-Entwicklungswebserver starten kann.Nachdem diese ausgeführt wurden, können Sie zu RUN zurückkehren. Es kann jedoch einfacher sein, immer DEBUG zu verwenden, damit Sie nicht darüber nachdenken müssen.
• Konfigurationsdateien.Bearbeiten Sie Ihre Testlaufkonfiguration, um .config-Dateien in den Testausführungsordner zu verschieben.
• Integration mit Source Safe.Sie müssen sich darüber im Klaren sein, dass MSTest SourceSafe hasst und das Gefühl auf Gegenseitigkeit beruht.Da MSTest Testdateien unter Quellcodeverwaltung stellen und zur Lösung hinzufügen möchte, muss es die Lösung jedes Mal auschecken, wenn Sie Tests ausführen.Daher muss SourceSafe im Multi-Checkout-Modus ausgeführt werden, um zu vermeiden, dass Ihre Mitentwickler getötet werden.
• Ignorieren Sie den Flaum Mit MSTest erhalten Sie ein Dutzend verschiedene Fenster und Ansichten.Testläufe, Testansicht, Testlisten ...Sie sind alle wenig hilfreich.Bleiben Sie bei den Testergebnissen und Sie werden viel zufriedener sein.
• Bleiben Sie bei „Unit-Tests“.Wenn Sie einen neuen Test hinzufügen, können Sie einen bestellten Test oder einen Komponententest hinzufügen oder einen Assistenten ausführen.Bleiben Sie bei einfachen Unit-Tests.

Answer 2

Wenn Sie keine andere Wahl haben, als MSTest zu verwenden, lernen Sie die Tastaturkürzel kennen.Sie werden Ihr Leben ein wenig einfacher machen.

Test im aktuellen Kontext: STRG+R, T
Alle Tests in Lösung: STRG+R, A

Debug-Tests im aktuellen Kontext: STRG+R, STRG+T
Debuggen Sie alle Tests in der Lösung: STRG+R, STRG+A

Answer 3

Ich bin hier neugierig.Was ich nicht verstehe, ist, dass die Leute anfangen, alle verfügbaren Open-Source-Tools mit MSTest zu vergleichen und es zu verunglimpfen.Kommentieren Sie, wie unhandlich es ist, wie unintuitiv usw.Meiner Meinung nach liegt es daran, dass es sich grundlegend von xUnit-Frameworks unterscheidet.Es ist für die parallele Ausführung optimiert.

Sogar das Problem, statische ClassInitialze und Cleanup zu haben und einen einzigartigen TestContext für jeden der Tests zu haben, alles aufgrund der parallelen Programmierkonzepte der nächsten Generation – zumindest für Windows-Business-Programmierer in MS-Sprachen.

Ich hatte das Pech, in einem Projekt mit Zehntausenden Unit-Tests zu arbeiten.Früher dauerte der Bau praktisch die meiste Zeit!Mit MSTest haben wir das auf sehr überschaubare Zeitpläne reduziert.

Answer 4

Mein Kollege Mike Hadlow hat eine ziemlich gute Zusammenfassung, warum wir MSTest so sehr verabscheuen Hier.

Es ist ihm gelungen, es aus seinem Projekt zu entfernen, aber ich arbeite derzeit an einem größeren Projekt, bei dem mehr Politik im Spiel ist, also verwenden wir es immer noch.

Das Ergebnis ist, dass derjenige, der MSTest implementiert hat, TDD nicht versteht.Es tut mir leid, wie ein M$-Basher zu klingen – das bin ich wirklich nicht.Aber es ärgert mich, dass ich mich mit einem sehr schlechten Werkzeug abfinden muss.

Answer 5

Ich habe keine ernsthaften Probleme mit MSTest gesehen.Worüber reden Sie konkret?Tatsächlich bewegen wir uns von NUnit zu MSTest.Allerdings kenne ich unsere Gründe dafür nicht.

Answer 6

Es gibt viele Konfigurationsdateien mit mstest, was es weniger aufwendig macht.
Ein weiterer Grund, warum ich mich für mbunit entschieden habe, ist die „Rollback“-Funktion von mbunit.Auf diese Weise können Sie alle in diesem Test durchgeführten Datenbankvorgänge rückgängig machen, sodass Sie tatsächlich vollständige Schaltungstests durchführen können und sich keine Sorgen machen müssen, dass der Teich nach dem Test verunreinigt wird.
Außerdem fehlen RowTest-Funktionen in mstest.

Ich schlage vor, mbunit einfach als Abhängigkeit innerhalb des Build-Prozesses auszuführen. Es ist einfach genug, es einfach in Ihrer Bin und Referenz zu platzieren, eine Installation ist nicht erforderlich.

Answer 7

• MSTest hat „hohe Reibung“:Ein Build -Skript mit Naant und Mbunit im Vergleich zu Mstest und MSBuild erhalten.Kein Vergleich.
• MStest ist langsam Mbunit und Nunit sind schneller in meinem Experiment (Gallio kann hier helfen)
• MStest fügt eine Reihe von Sachen hinzu, die ich nicht wie verdrahtete Konfigurationsdateien usw. brauche.
• MSTest verfügt nicht über den Funktionsumfang anderer Betriebssystem-Test-Frameworks.Schauen Sie sich xUnit und MbUnit an

Es ist einfach zu schwer zu bedienen und es gibt viele bessere Optionen.

Answer 8

Wie bereits erwähnt, müssen Sie die vollständige IDE installieren, um MSTest auf einem anderen Computer verwenden zu können, was ein bisschen Mist ist.Ich nehme an, das liegt daran, dass sie sicherstellen wollen, dass Unit-Tests nur in visuellen Studios der höheren Preisklasse funktionieren und Sie sie nicht auf andere Weise ausführen können.

Außerdem ist MSTest ziemlich langsam, weil es zwischen jedem Test den gesamten Kontext für jeden Test neu aufbaut. Dadurch wird sichergestellt, dass ein früherer Test fehlschlägt oder den aktuellen Test auf andere Weise nicht beeinflusst, sondern die Dinge verlangsamt.Sie können jedoch das Flag /noisolation verwenden, das alle Tests innerhalb des MSTest-Prozesses ausführt – was schneller ist.Zur Beschleunigung in der IDE:In der VS-Idee können Sie zu „Extras-Optionen“ gehen und dann „Testtools“ auswählen.Wählen Sie den Unterpunkt „Testausführung“ aus und stellen Sie im Dialog rechts sicher, dass das Kontrollkästchen „Testausführungs-Engine zwischen Testläufen laufen lassen“ aktiviert ist.

Answer 9

Um eine nicht punktierte Frage zu beantworten, lautet meine Antwort: "Wahrscheinlich bleibt NUNIT nur aus Ihrem Gesicht heraus."

Haftungsausschluss:Ich habe keine wirkliche Erfahrung mit der MS-Version von xUnit, höre jedoch Probleme wie „Sie müssen die gigantische Idee installieren, nur um Ihre Tests auf einem separaten Computer auszuführen“ – was ein absolutes Nein-Nein ist.Abgesehen davon hat MS diese Möglichkeit, einem Neuling über eine Art IDE-Schnickschnack den richtigen Weg zu verzerren, was der gesamten Idee zuwiderläuft.Das Generieren von Tests aus Klassen war etwas, an das ich mich noch vor etwa einem Jahr erinnere.Das macht den ganzen Sinn des Ganzen zunichte Probefahrt - Ihr Design soll aus winzigen RGR-Schritten entstehen:Schreiben eines Test-Make-It-Pass-Refactors.Wenn Sie dieses Tool verwenden, wird Ihnen das gesamte Erlebnis genommen.

Ich höre mit meiner Predigt auf.Jetzt :)

Answer 10

Ich habe mehrere Jahre lang TDD-Entwicklung mit NUnit durchgeführt und verwende MSTest aufgrund eines Rollenwechsels nun seit etwa vier Monaten.

Ich glaube nicht, dass MSTest jemanden davon abhält, TDD durchzuführen.Sie verfügen immer noch über alle Kernfunktionen, die Sie für TDD benötigen, z. B. grundlegende Asserts und Mocking-Frameworks (ich verwende Rhino Mocks).

MSTest lässt sich eng mit Visual Studio integrieren. Die beste Komponente dieser Integration ist das integrierte Code Coverage Tool.

Es gibt jedoch eine Reihe überzeugender Gründe nicht um MSTest zu verwenden.Die beiden größten Abschreckungen sind meiner Meinung nach:

1. Das Fehlen von Assert-Optionen (im Vergleich zu NUnit)
2. Der träge Testläufer (langsam im Vergleich zu NUnit)

Das bedeutet, dass das Schreiben von Assertions mehr Code erfordert. In Kombination mit einem langsamen Testläufer bedeutet dies, dass der gesamte Prozess langsamer ist als bei NUnit.Auch die Open-Source-Optionen finden in der Community deutlich mehr Unterstützung.

Wenn Sie TFS für CI verwenden, müssen Sie einige Hürden/Hacks überwinden, um NUnit dazu zu bringen, Testergebnisse zu veröffentlichen.Im Vergleich dazu ist das Ausführen von Tests auf TFS mit MSTest sehr einfach und unkompliziert.Wenn Sie TFS nicht anfassen, würde ich ganz auf NUnit umsteigen, es ist einfach schöner.