webentwicklung-frage-antwort-db.com.de

NUnit im Vergleich zu Visual Studio 2008-Testprojekten für Komponententests?

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

Vielen Dank für jede Hilfe und Anregungen!

252
Ryan Skarin

Daok nannte alle Pro's von VS2008 Testprojekten, hier sind die Pro's von NUnit.

  • NUnit hat einen spöttischen Rahmen.
  • 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 bringt mehr Versionen heraus als Visual Studio. Sie müssen nicht jahrelang auf eine neue Version warten. Außerdem müssen Sie keine neue Version von IDE) installieren, um neue Funktionen zu erhalten.
  • Es werden Erweiterungen für NUnit wie Zeilentests usw. entwickelt.
  • Das Starten von Visual Studio-Tests dauert aus irgendeinem Grund sehr lange. Dies ist besser in 2008, aber immer noch zu langsam für meinen Geschmack. 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 aus der IDE ist eigentlich viel schneller. Insbesondere beim Ausführen einzelner Tests.
    Kjetil Klaussen zufolge wird dies durch den Visual Studio-Testrunner verursacht. Durch das Ausführen von MSTest-Tests in TestDriven.Net wird die MSTest-Leistung mit NUnit vergleichbar.
98
Mendelt

Das Unit-Testing-Framework spielt eigentlich keine Rolle, da Sie Testklassen mit separaten Projektdateien und bedingter Kompilierung (wie folgt, VS-> NUnit) konvertieren können:

 #if! NUNIT 
 using Microsoft.VisualStudio.TestTools.UnitTesting; 
 #else 
 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 normalem VS2008 müssen Sie den Test aus Ihrer Testklasse oder Testliste herausfinden. Mit TestDriven.Net können Sie Ihren Test direkt in der Klasse ausführen, die Sie testen. Der Komponententest sollte einfach zu warten sein und sich in der Nähe des Entwicklers befinden.

64
Tuomas Hietanen

Vorteile/Änderungen des VS2008 Built-in Unit Testing Framework

  1. Die Version 2008 ist jetzt in professionellen Editionen erhältlich (bevor teure Versionen von VS benötigt wurden, ist dies nur für Entwickler-Unit-Tests gedacht), sodass viele Entwickler nur noch über offene/externe Test-Frameworks verfügen.
  2. Eingebaute API, die von einer einzelnen Firma 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 (kein Mock-Framework gewährt, aber dies ist ein guter Ausgangspunkt für viele Programmierer)
  5. Langzeitunterstützung gewährt (Ich erinnere mich noch, was mit nDoc passiert ist. Ich möchte mich nicht auf ein Testframework festlegen, das in 5 Jahren möglicherweise nicht unterstützt wird, halte nUnit jedoch für ein großartiges Framework.)
  6. Wenn Sie Team Foundation Server als Backend verwenden, können Sie auf einfache Weise Arbeitsaufgaben oder Fehler mit den fehlgeschlagenen Testdaten erstellen.
34
Simara

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

33

Etwas abseits des Themas, aber wenn Sie mit NUnit arbeiten, 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 Rezension ist etwas veraltet, erklärt dies jedoch genauer:

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

14
Richard Everett

Ein kleines Ärgernis des Visual Studio-Testframeworks 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.

14
Tarsier

Mein Hauptproblem bei VS-Komponententests über NUnit ist, dass die Erstellung von VS-Tests dazu tendiert, eine Menge generierten Codes für den privaten Mitgliederzugriff einzufügen.

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

Wenn ich Unit-Tests schreibe, ist es mein Anliegen, dass sie extrem kontrolliert sind, damit ich genau weiß, was ich teste und wie ich es teste. Wenn es automatisch generierten Code gibt, verliere ich einen Teil dieses Eigentums.

11
Ian Suttle

Ich habe mit beidem TDD 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 einer - 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 Ampeln. Sie wissen genau, was auf einen Blick passiert.

In VSTS ist die Testliste unten auf dem Bildschirm eingeklemmt. Sie ist klein und hässlich. Sie müssen zweimal hinsehen, 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 über 21 Blog-Posts gelesen, in denen es um das einfache TDD mit VSTS geht. Ich hätte mehr lesen sollen, du hast recht.

Für nUnit habe ich einen gelesen. Und ich habe am selben Tag TDD gemacht. Mit viel Spaß.

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

Alles Gute. Sylvain.

11

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

11
Ben Fulton

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 (wird sich wahrscheinlich ändern, wenn msTest populärer wird). In meinem aktuellen Projekt verwenden wir beide und der einzige große Unterschied ist, dass mstest immer als 32-Bit-Test ausgeführt wird, während NUnit als 32-Bit- oder 64-Bit-Test ausgeführt wird.

9
Dror Helper

Ich habe die Meldung "NUnit-Dateistruktur ist umfangreicher als VSTest" erhalten ... 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.

9
Tuomas Hietanen

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

Ich hasste die Idee, den gleichen Test mehrmals zu schreiben. Besonders bei einem großen Projekt, bei dem Testmethoden leicht auf Hunderte von Tests stoßen 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.

8
Th3Fix3r

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

  1. TestDriven.Net-Kompatibilität. TestDriven.Net.ReRunWithDebugger ist an keine Tastaturkombination gebunden.
  2. Das Gallio-Framework. Gallio ist ein Testläufer wie nUnits. Der einzige Unterschied ist, dass es Ihnen 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 dies ü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 alle Datenkombinationen testen könnten? Es ist in mbUnit.

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

7
AlSki
7
EfForEffort

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

6
Gene Mitelman

Soweit ich weiß, gibt es in diesen Tagen vier Frameworks für Unit-Tests mit .NET

  • NUnit
  • MbUnit
  • MSTest
  • xEinheit

NUnit war immer vorne mit dabei, aber die Lücke hat sich im letzten Jahr geschlossen. Ich bevorzuge immer noch NUnit selbst, zumal sie vor einiger Zeit eine flüssige Benutzeroberfläche hinzugefügt haben, die Tests sehr 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.

6
gilles27

Bei MSTest handelt es sich im Wesentlichen um NUnit, das leicht überarbeitet wurde, mit einigen neuen Funktionen (z. B. Einrichten und Herunterfahren von Baugruppen, nicht nur Geräte- und Testebene) und dem Fehlen einiger der besten Bits (z. B. der neuen 2.4-Einschränkungssyntax). NUnit ist ausgereifter und wird von anderen Anbietern stärker unterstützt. und da es immer kostenlos war (während MSTest es erst in die Professional-Version von 2008 schaffte, bevor es teurere SKUs gab), verwenden die meisten ALT.NET-Projekte es.

Allerdings gibt es einige Unternehmen, die es unglaublich ablehnen, etwas zu verwenden, auf dem nicht das Microsoft-Label steht, insbesondere OSS-Code. Ein offizielles MS-Test-Framework könnte die Motivation sein, die diese Unternehmen benötigen, um Tests durchzuführen. und seien wir ehrlich, es ist das Testen, das zählt, nicht das verwendete Tool (und mit Tuomas Hietanens Code oben können Sie Ihr Test-Framework fast austauschbar machen).

5
David Keaveny

Mit dem Release in .NET 4.0 des Code Contracts-Systems und der Verfügbarkeit eines statischen Prüfprogramms , müssten Sie theoretisch weniger Testfälle schreiben und ein Tool wie Pex wird Ihnen helfen, diese Fälle zu identifizieren. In Bezug auf die vorliegende Diskussion: Wenn Sie weniger Zeit mit Unit-Tests verbringen müssen, weil Ihre Verträge Ihren Schwanz bedecken, warum sollten Sie nicht einfach die eingebauten Komponenten verwenden, da dies eine geringere Abhängigkeit für die Verwaltung darstellt. In diesen Tagen dreht sich alles um Einfachheit. :-)

Siehe auch:

4
Norman H

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

  • Geteilte "Tests" -Datei (sinnlos), die beibehalten sein muss
  • Testlisten verursachen Konflikte mit mehreren Entwicklern/VCSs
  • Schlechte integrierte Benutzeroberfläche - verwirrendes Setup, lästige 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 begrenzte Fähigkeiten hätte und NUnit nicht konfigurieren könnte :)

Ich finde es viel einfacher, nur meine Tests zu schreiben und NUnitGUI oder eines der anderen Frontends zu starten (testDriven ist weit weit weit überteuert). Das Debuggen mit der Kommandozeilenversion einzurichten ist ebenfalls ziemlich einfach.

3
Andrew Backer