Wie TDD mit MSTest/VS2008 zu erleichtern

Question

Ich habe immer wieder gelesen, dass TDD/Test zuerst schwieriger ist mit MSTest als es mit anderen Test-Frameworks wie nUnit, MBUnit, etc ... Was sind einige vorgeschlagen manuelle Problemumgehungen und/oder 3rd-Party-Bits, die Sie vorschlagen, wenn MSTest die einzige Option aufgrund der Infrastrukturrichtlinie ist? Ich wundere mich hauptsächlich über die VS 2008 Team Suite, aber ich denke, Tipps für VS 2008 Pro on up wären auch geeignet, da einige MSTest-Funktionen jetzt auch in diesen Versionen enthalten sind.

Answer 1

MSTest sicherlich nicht so effizient oder erweiterbar, da einige der Open-Source-Frameworks ist, aber es ist machbar.Da die Frage danach besteht, das Leben mit MSTest einfacher zu machen und nicht über Alternativen, hier sind meine MSTest-Tipps.

• Shortcuts. Wie Haacked sagte, nimm dir ein paar Sekunden Zeit, um die Abkürzungen zu lernen.
• Aktueller Kontext. Da MSTest so langsam ist, führen Sie Tests nur im aktuellen Kontext durch, wenn Sie können. (CTRL + R, CTRL + T). Wenn sich Ihr Cursor in einer Testmethode befindet, wird nur die Methode ausgeführt. Wenn sich der Cursor außerhalb einer Methode, aber in einer Testklasse befindet, wird nur der Test ausgeführt. Und mit Namespace, etc usw.
• Effiziente Tests und Organisation. Es ist Hund langsam. 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 DEBUG-Tests statt RUN-Tests durchführen, damit Visual Studio die ASP.NET-Entwicklungswebserver starten kann. Nachdem diese oben sind, kannst du zurück zu RUN gehen, aber es kann einfacher sein, einfach immer DEBUG zu machen, also musst du nicht darüber nachdenken.
• Konfigurationsdateien. Bearbeiten Sie Ihre Testlaufkonfiguration, um .config-Dateien in den Testausführungsordner zu verschieben.
• Integration mit Source Safe. Sie müssen wissen, dass MSTest SourceSafe hasst und das Gefühl ist gegenseitig. Da MSTest Testdateien der Quellcodeverwaltung unterziehen und sie zur Lösung hinzufügen möchte, muss sie die Lösung jedes Mal überprüfen, wenn Sie Tests ausführen. Daher muss SourceSafe im Multi-Check-Out-Modus ausgeführt werden, um zu verhindern, dass andere Entwickler umgebracht werden.
• Ignorieren Sie den Flaum Mit MSTest erhalten Sie ein Dutzend verschiedene Fenster und Ansichten. Testläufe, Testansicht, Testlisten ... sie sind alle weniger als hilfreich. Bleiben Sie bei den Testergebnissen und Sie werden viel glücklicher sein.
• Stick mit "Unit Tests". Wenn Sie einen neuen Test hinzufügen, können Sie einen geordneten Test, einen Komponententest oder einen Assistenten hinzufügen. Bleiben Sie bei einfachen einfachen Komponententests.

Answer 2

Ich habe keine ernsthaften Probleme mit MSTest gesehen. Worüber sprechen Sie gerade? Wir bewegen uns tatsächlich von NUnit zu MSTest. Ich kenne unsere Gründe dafür nicht.

Answer 3

Es gibt viele Konfigurationsdateien mit MSTest, wodurch es weniger günstig ist.
Ein weiterer Grund, warum ich mbunit gewählt habe, ist die "Rollback" -Funktion von mbunit. Dies ermöglicht es Ihnen, alle in diesem Test durchgeführten Datenbank-Vorgänge rückgängig zu machen, so dass Sie tatsächlich vollständige Schaltungstests durchführen können und sich nicht darum kümmern müssen, dass der Teich nach dem Test verunreinigt wird.
Auch fehlende RowTest-Einrichtungen in MSTest.

Ich schlage vor, nur MbUnit als Abhängigkeit innerhalb des Build-Prozesses, ist es einfach genug, um es einfach zu schwimmen mit Ihrem ist, und das Bezug, keine Installation erforderlich.

Answer 4

Wenn Sie keine andere Wahl haben, als MSTest zu verwenden, lernen Sie die Tastaturkürzel. Sie werden dir das Leben ein wenig erleichtern.

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

Debug-Tests im aktuellen Kontext: CTRL + R, CTRL + T
Debug Alle Tests in Lösung: CTRL + R, CTRL + A

Answer 5

eine nicht-spitze Frage zu beantworten, wäre meine Antwort „wahrscheinlich NUnit bleibt gerade aus dein Gesicht."

Haftungsausschluss: Ich habe keine tatsächliche Erfahrung mit MS-Version von xUnit, aber ich höre Probleme wie "Sie müssen die gigantische Idee nur installieren, um Ihre Tests auf einer separaten Maschine zu laufen" - das ist eine vollständige No- Nein. Anders als das MS hat MS diese Art, den richtigen Weg für einen Neuling über eine Art IDE-Glocke/Pfeife zu verdrehen, die der ganzen Idee widerspricht. Wie Generieren von Tests aus Klassen war eine, ich erinnere mich an ein Jahr oder so zurück, dass besiegt den ganzen Punkt test-fahren - Ihr Design soll aus winzigen Schritten von RGR entstehen: Schreiben Sie einen Test-machen es Pass-Refactor . Wenn Sie dieses Werkzeug verwenden - es beraubt Sie von der gesamten Erfahrung.

Ich werde mit meiner Predigt stoppen .. jetzt :)

Answer 6

Mein Kollege Mike Hadlow hat ziemlich gute Zusammenfassung, warum wir absolut MSTest here verabscheuen.

Er hat es geschafft, es aus seinem Projekt zu entfernen, aber ich arbeite derzeit an einem größeren Projekt mit mehr Politik beteiligt, so dass wir es immer noch verwenden.

Das Ergebnis davon ist, dass wer MSTest implementiert, TDD nicht versteht. Es tut mir leid, dass ich mich wie ein M $ Basher anhört - ich bin es wirklich nicht. Aber ich ärgere mich, dass ich ein sehr schlechtes Werkzeug ertragen muss.

Answer 7

• MSTest hat "hohe Reibung": Erste einen Build-Skript mit NAant und MbUnit im Vergleich zu MSTest und MSBuild. Nein Vergleich.
• MSTest Langsam MbUnit ist und NUnit sind in meiner experince schneller (gallio kann hier helfen)
• MSTest fügt ein Haufen Zeug i wie verdrahteten Konfigurationsdateien nicht brauchen, usw.
• MSTest doesnt haben die fetaure Set von anderen Betriebssystem-Test-Frameworks. check out xUnit und MbUnit

Es ist einfach zu schwer zu benutzen und es gibt viele bessere Möglichkeiten.

Answer 8

Ich bin neugierig hier. Was ich nicht verstehe, ist, dass Leute anfangen, alle verfügbaren Open-Source-Tools mit MSTest zu vergleichen und mit dem Bashing zu beginnen. Kommentieren, wie unhandlich es ist, wie unintuitiv usw. IMHO, weil es sich grundlegend von xUnit-Frameworks unterscheidet. Es ist für die parallele Ausführung optimiert.

Sogar die Qurik der statischen ClassInitialze und Cleanup und einzigartige TestContext für jeden der Tests alle wegen der nextgen - zumindest für Windows-Business-Programmierer in MS-Sprachen - parallel Progarmming-Konzepte.

Ich hatte das Pech, in einem Projekt mit Zehntausenden von Komponententests zu arbeiten. Früher brauchten sie fast die meiste Zeit für den Bau! Mit MSTest haben wir das auf sehr überschaubare Zeitpläne reduziert.

Answer 9

wie erwähnt oyu müssen die volle IDE installieren, um MSTest auf einer anderen Maschine zu verwenden, die ein bisschen Mist ist. Ich nehme an, das liegt daran, dass sie sicherstellen wollen, dass Komponententests nur in den höheren visuellen Studios funktionieren, und dass Sie sie auf keine andere Weise ausführen können.

Auch MSTest ist ziemlich langsam, dies ist weil zwischen jedem Test es den gesamten Kontext für jeden Test neu erstellt, das macht sicher, dass ein früherer Test - fehlgeschlagen oder sonst keinen Einfluss auf den aktuellen Test, aber verlangsamt Dinge . Sie können jedoch das Flag/noisolation verwenden, das alle Tests innerhalb des MSTest-Prozesses ausführt - was schneller ist. Um in der IDE zu beschleunigen: In der VS-IDE können Sie zu Tools-Optionen gehen und dann Test Tools auswählen. Wählen Sie den Unterpunkt "Testausführung" und stellen Sie in Dialouge auf der rechten Seite sicher, dass das Kontrollkästchen "Testausführungsmodul läuft zwischen Testläufen" aktiviert ist.

Answer 10

Ich habe TDD Entwicklung mit NUnit für eine Reihe von Jahren gemacht und benutze MSTest seit etwa 4 Monaten jetzt aufgrund einer Rollenänderung.

Ich glaube nicht, dass MSTest jemanden davon abhält, TDD zu tun. Sie haben immer noch alle wichtigen Dinge, die Sie für TDD benötigen, wie grundlegende Behauptungen und Mock-Frameworks (ich benutze Rhino Mocks).

MSTest integrieren ist eng mit Visual Studio, die beste Komponente dieser Integration ist das Code-Coverage-Tool, das eingebaut ist.

ABER Es gibt eine Reihe von zwingenden Gründen nicht MSTest zu verwenden. Die beiden größten Abzweigungen meiner Meinung nach sind:

1. Der Mangel an assert Optionen (im Vergleich zu NUnit)
2. Der träge Test Runner (langsam im Vergleich zu NUnit)

Dies bedeutet, dass das Schreiben behauptet Wenn mehr Code in Kombination mit einem langsamen Testlauf verwendet wird, bedeutet dies, dass der gesamte Prozess langsamer als NUnit ist. Die Open-Source-Optionen haben auch viel mehr Unterstützung in der Community.

Wenn Sie TFS für CI verwenden, müssen Sie ein paar Schleifen/Hacks durchgehen, damit NUnit die Testergebnisse veröffentlichen kann. Das Ausführen von TFS-Tests mit MSTest im Vergleich ist sehr einfach und unkompliziert. Wenn Sie TFS nicht berühren, als wenn ich NUnit den ganzen Weg gehen würde, ist es einfach schöner.