C # - Ohne Unit-Tests aus der Release-Version Ihres Projektes

Question

Wie gehen Sie in der Regel über Ihre Codebasis und die damit verbundene Komponententests zu trennen ? Ich kenne Leute, die ein separates Projekt für Unit-Tests erstellen, die ich persönlich verwirrend und schwer zu halten. Auf der anderen Seite, wenn Sie in einem einzigen Projekt up-Code und seine Tests mischen, beenden Sie mit Binärdateien bis zu Ihrem Unit-Test-Framework im Zusammenhang (sei es NUnit, MbUnit oder was auch immer) und Ihre eigenen Binaries nebeneinander.

Dies ist für das Debuggen in Ordnung, aber wenn ich eine Release-Version bauen, ich meinen Code nicht möchten, auf Referenz der Komponententestframework wirklich nicht mehr.

Eine Lösung, die ich gefunden ist alle Tests Ihr Gerät innerhalb #IF DEBUG umschließen - #endif., Wenn kein Code ein Unit-Test Assembly verweist, der Compiler ist klug genug, um die Referenz in der kompilierten Code wegzulassen

Gibt es andere (möglicherweise bequemer) -Optionen ein ähnliches Ziel zu erreichen?

Answer 1

ich auf jeden Fall befürwortet die Tests, um ein eigenes Projekt zu trennen. Es ist der einzige Weg, meiner Meinung nach gehen.

Ja, wie Gary sagt, es zwingt Dich auch eher Verhalten durch öffentliche Methoden zu testen, als das Spiel über mit die Innereien der Klassen

Answer 2

Wie die andere weisen darauf hin, ein separates Testprojekt (für jedes normales Projekt) ist ein guter Weg, es zu tun. Ich spiegeln in der Regel die Namensräume und eine Testklasse für jede normale Klasse erstellen mit ‚Test‘ an den Namen angehängt. Dies wird direkt in der IDE unterstützt, wenn Sie Visual Studio Team System haben, die automatisch Testklassen und Methoden in einem anderen Projekt generieren können.

Eine Sache zu erinnern, wenn Sie Klassen und Methoden mit der ‚internen‘ Accessor testen mögen, ist die folgende Zeile in die AssemblyInfo.cs-Datei für jedes Projekt hinzuzufügen getestet werden:

[assembly: InternalsVisibleTo("UnitTestProjectName")]

Answer 3

Das .NET-Framework nach v2 hat eine nützliche Funktion, wo Sie eine Assembly mit dem Attribut InternalsVisibleTo markieren können, die die Anordnung von einem anderen zugegriffen werden kann.
Eine Art von Montage-Tunneling-Funktion.

Answer 4

Ein weitere Alternative Compiler-Direktiven in einer Datei zu verwenden oder ein separates Projekt zu erstellen ist lediglich zusätzliche CS-Dateien in Ihrem Projekt zu erstellen.

Mit etwas Magie im Projekt-Datei selbst, können Sie, dass diktieren:

1. NUnit.Framework DLLs sind nur in einem Debug-Build Bezug genommen wird, und
2. Ihre Testdateien werden nur im Debug enthalten baut

Beispiel CSPROJ Auszug:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

   ...

   <Reference Include="nunit.framework" Condition=" '$(Configuration)'=='Debug' ">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\debug\nunit.framework.dll</HintPath>
   </Reference>

   ...

   <Compile Include="Test\ClassTest.cs" Condition=" '$(Configuration)'=='Debug' " />

   ...
</Project>

Answer 5

würde ich ein eigenes Projekt für Unit-Tests (und noch mehr Projekte für Integrationstests, Funktionstests etc.) empfehlen. Ich habe versucht, Code und Tests im selben Projekt Mischen und fand es viel weniger wartbar als sie in einzelne Projekte zu trennen.

Die Aufrechterhaltung parallel Namensräume und mit einer vernünftigen Namenskonvention für Tests (zB. MyClass und MyClassTest) helfen Ihnen, die Code-Basis wartbar zu halten.

Answer 6

Solange die Tests in einem separaten Projekt sind, können die Tests, um die Code-Basis verweisen, aber die Code-Basis hat nie die Tests zu verweisen. Ich habe zu fragen, was die Aufrechterhaltung zwei Projekte ist verwirrend? Sie können sie in der gleichen Lösung für die Organisation halten.

Der komplizierteste Teil, ist natürlich, wenn das Unternehmen 55 Projekte in der Lösung hat und 60% von ihnen sind Tests. Sich glücklich schätzen.

Answer 7

Ich habe die Tests in einem separaten Projekt, aber in der gleichen Lösung. Zugegeben, in den großen Lösungen könnte es eine ganze Reihe von Projekten, aber die Lösung Explorer ist gut genug, um auf ihnen zu trennen und wenn man alles vernünftige Namen gebe ich nicht wirklich glaube, es ist ein Problem.

Answer 8

Für jedes Projekt gibt es eine entsprechende .Test Projekt, das Tests auf die er enthält.

z. für die Montage genannt, sagen Sie „Acme.BillingSystem.Utils“, gäbe es eine Testanordnung namens „Acme.BillingSystem.Utils.Test“.

Ausschließen es aus dem Versand Version Ihres Produkts durch nicht, dass die dll Versand.

Answer 9

Ich habe immer meine Unit-Tests in einem separaten Projekt halten, so dass es auf seine eigene Montage kompiliert wird.

Answer 10

Eine Sache noch sind Versionen von Visual Studio vor 2005 in Betracht gezogen wird nicht erlauben EXE Montageprojekte aus anderen Projekten zu referenzieren. Also, wenn Sie auf einem Legacy-Projekt in VS.NET Ihre Möglichkeiten arbeiten würden:

• Legen Sie Unit-Tests im selben Projekt und verwenden bedingte Kompilierung, sie auszuschließen von Release-Builds.
• Bewegen Sie alles zu dll Baugruppen so Ihre exe nur ein Einstiegspunkt ist.
• Umgehen des IDE durch die Projektdatei in einem Texteditor Hacking.

Von der drei bedingten Kompilierung ist die am wenigsten fehleranfällig.

Answer 11

ich auf jeden Fall mit jeder zustimmen anderes, dass Sie die Tests von Ihrem Produktionscode trennen sollte. Wenn Sie nicht darauf bestehen, sollten Sie jedoch eine bedingte comiplation Konstante definieren TEST genannt, und wickeln Sie alle Ihre Einheit Testklassen mit einem

#if TEST
#endif

zuerst, um sicherzustellen, dass der Testcode nicht in einem Produktionsszenario nicht kompiliert. Sobald dies geschehen ist, sollten Sie entweder in der Lage sein, den Test-DLLs von Ihrer Produktionsumgebung auszuschließen, oder noch besser (aber höhere Wartung), ein NAnt oder MSBuild für die Produktion erstellen, ohne die Verweise auf den Test-DLLs kompiliert wird.

Answer 12

Ich erzeuge immer ein separates Acme.Stuff.Test Projekt, das separat kompiliert wird.

Das Gegenteil Argument ist: Warum wollen Sie die Tests herausnehmen wollen? Warum nicht den Test liefern? Wenn Sie die Tests zusammen mit einem Testläufer liefern haben Sie ein gewisses Maß an Akzeptanz-Test und Selbsttest mit dem Produkt geliefert wird.

Ich habe dieses Argument ein paar Mal gehört und dachte darüber nach, aber ich persönlich noch Tests halten in einem separaten Projekt.

Answer 13

Wenn Sie die # if (debug) Tag für eine saubere "Release" Version ermöglicht es, warum sollten Sie benötigen ein eigenes Projekt für Tests. Das nunit LibarryA / B Beispiel (ja, ich weiß, es ist ein Beispiel) tut dies. Derzeit ringen mit dem Szenario. Hat ein separates Projekt wurde verwenden, aber dies scheint möglicherweise für einige Produktivitätsverbesserungen zu ermöglichen. Noch hummin und Hawin.