TDD mit VS2010, UnitTests MSTest?
Hallo
Die Entwicklungsumgebung ist VS2010 Beta 1 mit Resharper5 (nightly built). Beide Unterstützen MSTest, mit VS2010 lassen sich auch private Methoden testen (MSDN bezeichnet dies als "accessor", Unit Tests for Private, Internal, and Friend Methods).
Die Hauptgründe, warum wir uns für MSTest entschieden haben (noch nicht zu 100%, aber ...) waren, dass das ganze Testing schon in VS2010 implementiert ist, Resharper MSTest auch unterstützt und man keine eigenen Klassen schreiben muss, um auf private Methoden zugreifen zu können.
Gleich mal vorweg:
Was spricht gegen den Entscheid, MSTest in Verbindung mit VS2010 zu verwenden?
Was gilt zu beachten?
Sucht man hier im Forum nach MSTest erscheinen 6 Resultate, bei NUnit 164. Was könnte der Grund für diese Verteilung sein?
Merci für die Antworten
Ein TDD-Neuling
hier gibt es ne flotte übersicht:
NUnit vs. MsTest: NUnit wins for Unit Testing.
ich persönlich bin nUnit gewöhnt. Aber jetzt beschäftige ich mich mit VS2010 und dem flott integrierten MSTest. Dies ist auch gut mit TeamFoundation verknüpft (laut diversen web-Quellen) und genügt aktuell meinen Ansprüchen.
Aber nUnit hat wohl mehr "erfahrung" und ist halt auch openSource...
Viele Grössere Projekte gibt es schon länger als MSTest oder den CI Server von MS.
Die setzen dann auf z.b. TeamCity und CO auf.
Und dort für die automatischen Tests MSTest zu installieren ( ohne eine eigene VS.NET installation ) ist recht aufwendig.
Mit NUnit, MBUnit oder XUnit ist das viel leichter.
Auch kenne ich nicht viele Unternehmen, die wirklich den TFS einsetzen.
Stellt sich halt die Grundfrage aus welchem "Guss" man seine Developerwerkzeuge bezieht...
Die Microsoft Ableger hatten in der Vergangenheit mit vielen Problemen zu tun (SourceSafe usw...) und hinken daher den kontrahenden hinterher.
Ich selber kenn (für die groben Sachen) leider nur die M$ welt mit MSTest, TFS, CI usw... mit der Konkurenz hab ich mich bisher (zu)wenig befasst. Einzig nUnit kenn ich.
Generell ist die Entscheidung für ein Testframework auch nicht ganz so kritisch: Quick&Dirty kann man jedes einigermaßen gut nachbauen, falls es tatsächlich mal zu Problemen kommen sollte.
Die meisten unterscheiden sich ja sowieso nur in den Namen der Attribute / Asserttmethoden.