Testprojekte von NUnit vs Visual Studio 2008 für Unit-Tests? [geschlossen]

Ich werde ein neues Projekt bei der Arbeit starten und möchte mit Unit-Tests beginnen. Wir werden VS 2008, C # und das ASP.NET MVC-Zeug verwenden. Ich möchte entweder NUnit oder die integrierten Testprojekte von VS2008 verwenden, bin aber offen für weitere Vorschläge. Ist ein System besser als das andere oder vielleicht einfacher zu bedienen / zu verstehen als das andere? Ich möchte dieses Projekt als eine Art "Best Practice" für unsere zukünftigen Entwicklungsbemühungen einrichten.

Vielen Dank für jede Hilfe und Anregungen!

Daok nannte alle Profis von VS2008-Testprojekten, hier sind die Profis von NUnit.

• NUnit hat ein spöttisches Framework.
• NUnit kann außerhalb der IDE ausgeführt werden. Dies kann hilfreich sein, wenn Sie Tests auf einem Nicht-MS-Build-Server wie CC.Net ausführen möchten
• NUnit hat mehr Versionen als Visual Studio. Sie müssen nicht Jahre auf eine neue Version warten und müssen keine neue Version der IDE installieren, um neue Funktionen zu erhalten.
• Für NUnit werden Erweiterungen wie Zeilentests usw. entwickelt.
• Der Start von Visual Studio-Tests dauert aus irgendeinem Grund sehr lange. Das ist 2008 besser, aber für meinen Geschmack immer noch zu langsam. Das schnelle Ausführen eines Tests, um festzustellen, ob Sie etwas nicht kaputt gemacht haben, kann zu lange dauern. NUnit mit so etwas wie Testdriven.Net zum Ausführen von Tests über die IDE ist tatsächlich viel schneller. vor allem bei einzelnen Tests.
  Laut Kjetil Klaussen wird dies durch den Visual Studio-Testrunner verursacht, der MSTest-Tests in TestDriven.Net ausführt, wodurch die MSTest-Leistung mit NUnit vergleichbar wird.

Das Unit-Testing-Framework spielt eigentlich keine große Rolle, da Sie Testklassen mit separaten Projektdateien und bedingter Kompilierung konvertieren können (z. B. VS-> NUnit):

 #if! NUNIT
  Verwenden von Microsoft.VisualStudio.TestTools.UnitTesting;
 #sonst
  using NUnit.Framework;
  using TestClass = NUnit.Framework.TestFixtureAttribute;
  using TestMethod = NUnit.Framework.TestAttribute;
  using TestInitialize = NUnit.Framework.SetUpAttribute;
  using TestCleanup = NUnit.Framework.TearDownAttribute;
  using TestContext = System.String;
  using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 #endif

Das TestDriven.Net-Plugin ist nett und nicht sehr teuer ... Mit nur VS2008 müssen Sie den Test aus Ihrer Testklasse oder Testliste finden. Mit TestDriven.Net können Sie Ihren Test direkt in der Klasse ausführen, die Sie testen. Schließlich sollte der Unit-Test leicht zu warten sein und sich in der Nähe des Entwicklers befinden.

Vorteile / Änderungen des in VS2008 integrierten Unit Testing Framework

1. Die Version 2008 ist jetzt in professionellen Editionen verfügbar (bevor teure Versionen von VS erforderlich waren, dient dies nur zum Testen von Entwicklereinheiten), sodass vielen Entwicklern nur noch offene / externe Test-Frameworks zur Auswahl standen.
2. Eingebaute API, die von einem einzelnen Unternehmen unterstützt wird.
3. Verwenden Sie dieselben Tools zum Ausführen und Erstellen von Tests (Sie können sie auch über die Befehlszeile MSTest ausführen).
4. Einfaches Design (ohne Mock-Framework, aber dies ist ein guter Ausgangspunkt für viele Programmierer)
5. Langfristige Unterstützung gewährt (Ich erinnere mich noch daran, was mit nDoc passiert ist. Ich möchte mich nicht auf ein Testframework festlegen, das in 5 Jahren möglicherweise nicht mehr unterstützt wird, aber ich halte nUnit dennoch für ein großartiges Framework.)
6. Wenn Sie den Team Foundation Server als Backend verwenden, können Sie auf einfache Weise Arbeitselemente oder Fehler mit den fehlgeschlagenen Testdaten erstellen.

Ich benutze NUnit seit 2 Jahren. Alles ist in Ordnung, aber ich muss sagen, dass das Unit-System in VS ziemlich gut ist, weil es sich in der GUI befindet und einfacher Tests für private Funktionen durchführen kann, ohne herumspielen zu müssen. Mit dem Unit Testing von VS können Sie auch Covering und andere Dinge erledigen, die NUnit allein nicht kann.

Ein kleines Ärgernis des Testframeworks von Visual Studio ist, dass es viele Testlaufdateien erstellt, die dazu neigen, Ihr Projektverzeichnis zu überladen - obwohl dies keine große Sache ist.

Wenn Ihnen ein Plugin wie TestDriven.NET fehlt, können Sie Ihre NUnit- (oder MbUnit-, xUnit- usw.) Komponententests nicht in der Visual Studio-Umgebung debuggen, wie dies mit dem integrierten Microsoft VS-Testframework möglich ist.

Etwas abseits des Themas, aber wenn Sie sich für NUnit entscheiden, kann ich die Verwendung von ReSharper empfehlen - es fügt der VS-Benutzeroberfläche einige Schaltflächen hinzu, die das Ausführen und Debuggen von Tests in der IDE erheblich vereinfachen.

Diese Überprüfung ist etwas veraltet, erklärt dies jedoch ausführlicher:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

XUnit ist eine weitere Möglichkeit für ein Greenfield-Projekt. Es hat vielleicht eine intuitivere Syntax, ist aber nicht wirklich kompatibel mit den anderen Frameworks.

http://www.codeplex.com/xunit

Mein Hauptproblem bei VS-Komponententests über NUnit ist, dass die Erstellung von VS-Tests dazu neigt, eine Menge generierten Codes für den Zugriff privater Mitglieder einzufügen.

Einige möchten vielleicht ihre privaten Methoden testen, andere nicht, das ist ein anderes Thema.

Ich mache mir Sorgen, wenn ich Unit-Tests schreibe, sollten diese extrem kontrolliert werden, damit ich genau weiß, was ich teste und wie ich es teste. Wenn es automatisch generierten Code gibt, verliere ich einen Teil dieses Eigentums.

Ich habe TDD mit beiden gemacht und (vielleicht bin ich ein bisschen dumm) nUnit scheint für mich viel schneller und einfacher zu sein. Und wenn ich viel sage, meine ich viel.

In MS Test gibt es überall zu viele Attribute - der Code, der die eigentlichen Tests durchführt, sind die winzigen Zeilen, die Sie hier und da lesen können. Ein großes Durcheinander. In nUnit dominiert der Code, der den Test ausführt, nur die Attribute, wie es sein sollte.

Außerdem müssen Sie in nUnit nur auf die Tests klicken, die Sie ausführen möchten (nur einen - alle Tests, die eine Klasse abdecken - eine Assembly - die Lösung -). Ein Klick. Und das Fenster ist klar und groß. Sie erhalten klare grüne und rote Lichter. Sie wissen wirklich, was auf einen Blick passiert.

In VSTS ist die Testliste am unteren Bildschirmrand gestaut, sie ist klein und hässlich. Sie müssen zweimal schauen, um zu wissen, was passiert ist. Und Sie können nicht nur einen Test durchführen (nun, ich habe es noch nicht herausgefunden!).

Aber ich kann mich natürlich irren - ich habe gerade 21 Blog-Beiträge über "Wie man einfaches TDD mit VSTS macht" gelesen. Ich hätte mehr lesen sollen, du hast recht.

Für nUnit habe ich einen gelesen. Und ich war am selben Tag TDDing. Mit Spaß.

Übrigens liebe ich normalerweise Microsoft-Produkte. Visual Studio ist wirklich das beste Tool, das ein Entwickler kaufen kann - aber die Verwaltung von TDD und Workitems in Visual Studio Team System ist wirklich zum Kotzen.

Alles Gute. Sylvain.

Ich habe die Meldung erhalten, dass "NUnit-Dateistruktur umfangreicher als VSTest ist" ... Wenn Sie die NUnit-Dateistruktur bevorzugen, können Sie diese Lösung natürlich auch anders verwenden (NUnit-> VS):

 #if !MSTEST
  using NUnit.Framework;
 #else
  using Microsoft.VisualStudio.TestTools.UnitTesting;
  using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
  using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
  using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
  using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

Oder irgendeine andere Konvertierung ... :-) Diese Verwendung hier ist nur ein Alias ​​für den Compiler.

Zuerst möchte ich eine falsche Aussage korrigieren: Sie können msTest außerhalb von Visual Studio über die Befehlszeile ausführen. Obwohl einige CI-Tools wie TeamCity NUnit besser unterstützen (würde sich wahrscheinlich ändern, wenn msTest populärer wird). In meinem aktuellen Projekt verwenden wir beide und der einzige große Unterschied, den wir festgestellt haben, ist, dass mstest immer als 32-Bit-Test ausgeführt wird, während NUnit entweder als 32-Bit- oder 64-Bit-Test ausgeführt wird. Dies ist nur wichtig, wenn Ihr Code nativen Code verwendet, der 32/64-abhängig ist.

Ich habe mit MSTest angefangen, aber aus einem einfachen Grund gewechselt. MSTest unterstützt nicht die Vererbung von Testmethoden von anderen Baugruppen.

Ich hasste die Idee, denselben Test mehrmals zu schreiben. Besonders bei einem großen Projekt, bei dem Testmethoden leicht zu Hunderten von Tests führen können.

NUnit macht genau das, was ich brauche. Das einzige, was bei NUnit fehlt, ist ein Visual Studio-Add-In, das den Rot / Grün-Status (wie VSTS) jedes Tests anzeigen kann.

.NET Testing Framework Advice und .NET Unit Testing-Pakete? .

Wenn Sie entweder MSTest oder nUnit in Betracht ziehen, empfehle ich Ihnen, sich mbUnit anzusehen. Meine Gründe sind

1. TestDriven.Net-Kompatibilität. Nichts ist besser als TestDriven.Net.ReRunWithDebugger an eine Tastaturkombination gebunden.
2. Das Gallio-Framework. Gallio ist ein Testläufer wie nUnits. Der einzige Unterschied ist, dass es egal ist, ob Sie Ihre Tests in nUnit, msTest, xUnit oder mbUnit geschrieben haben. Sie werden alle gerannt.
3. Kompatibilität mit nUnit. Alle Funktionen in nUnit werden von mbUnit unterstützt. Ich denke, Sie müssen nicht einmal Ihre Attribute ändern (müssen das überprüfen), sondern nur Ihre Referenz und Verwendung.
4. Sammlung behauptet. mbUnit verfügt über weitere Assert-Fälle, einschließlich der CollectionAssert-Klasse. Grundsätzlich müssen Sie keine eigenen Tests mehr schreiben, um festzustellen, ob zwei Sammlungen identisch sind.
5. Kombinatorische Tests. Wäre es nicht cool, wenn Sie zwei Datensätze bereitstellen und einen Test für alle Datenkombinationen erhalten könnten? Es ist in mbUnit.

Ich habe mbUnit ursprünglich aufgrund seiner [RowTest ....] - Funktionalität ausgewählt und keinen einzigen Grund gefunden, zurück zu gehen. Ich habe alle meine aktiven Testsuiten von nUnit verschoben und habe nie zurückgeschaut. Seitdem habe ich zwei verschiedene Entwicklungsteams auf die Vorteile umgestellt.

Soweit ich weiß, stehen derzeit vier Frameworks für Unit-Tests mit .NET zur Verfügung

• NUnit
• MbUnit
• MSTest
• xEinheit

NUnit war schon immer vorne mit dabei, aber die Lücke hat sich im letzten Jahr geschlossen. Ich bevorzuge NUnit immer noch selbst, zumal sie vor einiger Zeit eine fließende Benutzeroberfläche hinzugefügt haben, die Tests sehr gut lesbar macht.

Wenn Sie gerade erst mit dem Testen von Einheiten beginnen, macht es wahrscheinlich keinen großen Unterschied. Sobald Sie auf dem neuesten Stand sind, können Sie besser beurteilen, welches Framework für Ihre Anforderungen am besten geeignet ist.

Ich mag das in VS integrierte Testframework nicht, weil es Sie dazu zwingt, ein separates Projekt zu erstellen, anstatt Ihre Tests als Teil des zu testenden Projekts zu haben.

MSTest ist im Wesentlichen NUnit leicht überarbeitet, mit einigen neuen Funktionen (wie dem Einrichten und Herunterfahren von Baugruppen, nicht nur der Befestigungs- und Teststufe) und dem Fehlen einiger der besten Bits (wie der neuen 2.4-Einschränkungssyntax). NUnit ist ausgereifter und wird von anderen Anbietern stärker unterstützt. und natürlich, da es immer kostenlos war (während MSTest es nur in die Professional-Version von 2008 geschafft hat, bevor es viel teurere SKUs gab), verwenden es die meisten ALT.NET-Projekte.

Trotzdem gibt es einige Unternehmen, die unglaublich zögern, etwas zu verwenden, auf dem nicht das Microsoft-Label steht, insbesondere OSS-Code. Ein offizielles MS-Test-Framework kann daher die Motivation sein, die diese Unternehmen benötigen, um Tests durchzuführen. Und seien wir ehrlich, es kommt auf das Testen an, nicht darauf, welches Tool Sie verwenden (und mit dem obigen Code von Tuomas Hietanen können Sie Ihr Test-Framework fast austauschbar machen).

Mit der Veröffentlichung des Code Contracts-Systems in .NET 4.0 und der Verfügbarkeit eines statischen Prüfers müssten Sie theoretisch weniger Testfälle schreiben, und ein Tool wie Pex hilft bei der Identifizierung dieser Fälle. Wenn Sie in Bezug auf die vorliegende Diskussion weniger mit Ihren Komponententests zu tun haben, weil Ihre Verträge Ihren Schwanz bedecken, warum nicht einfach die integrierten Teile verwenden, da dies eine Abhängigkeit weniger für die Verwaltung darstellt. In diesen Tagen dreht sich alles um Einfachheit. :-)

Siehe auch:

• Microsoft Pex - Automatisierte Unit-Tests
• Unit-Test-Generierung mit Pex mit Visual Studio 2010 und C # 4.0

Ich würde es vorziehen, das kleine Test-Framework von MS zu verwenden, bleibe aber vorerst bei NUnit. Die Probleme mit MS sind im Allgemeinen (für mich)

• Freigegebene "Test" -Datei (sinnlos), die gepflegt werden muss
• Testlisten verursachen Konflikte mit mehreren Entwicklern / VCSs
• Schlechte integrierte Benutzeroberfläche - verwirrendes Setup, mühsame Testauswahl
• Kein guter externer Läufer

Vorsichtsmaßnahmen - Wenn ich eine Aspx-Site testen würde, würde ich definitiv MS verwenden. - Wenn ich Solo entwickeln würde, wäre auch MS in Ordnung. - Wenn ich nur begrenzte Fähigkeiten hätte und NUnit nicht konfigurieren könnte :)

Ich finde es viel einfacher, einfach meine Tests zu schreiben und NUnitGUI oder eines der anderen Frontends zu starten (testDriven ist weitaus weitaus teurer). Das Einrichten des Debuggens mit der Befehlszeilenversion ist ebenfalls recht einfach.