Best Practices zum Einrichten eines Visual Studio-Projekts für nUnit-Tests

Question

Wie richten Benutzer ihre Projekte für Visual Studio ein und wie verweisen Sie auf die testbare Anwendung?

Im Moment habe ich ein separates Projekt hinzugefügt, das eine .dll zu meiner Lösung erstellt, die alle Testfälle und Verweise auf nit.framework enthält, und verweist auch auf die EXE-Hauptdatei direkt aus dem Debug/Ordner, den VS erzeugt die Ausgabe.

Aber ich habe keine Ahnung, ob das eine gute Idee ist - oder was die besten Praktiken sind, jemand möchte ihre Praktiken teilen?

Answer 1

Das klingt ziemlich gut für mich - Sie können Ihre Anwendung ohne die Test Assembly und NUnit verteilen oder bereitstellen, aber immer noch alles testen. So ziemlich Standardpraxis.

Answer 2

Ich habe einen separaten Ordner für alle meine Tests verwendet, wenn Sie sie in einem Projekt verwenden. Dann können Sie den Ordner leicht entfernen, wenn Sie einen tatsächlichen Build erstellen, wenn Sie möchten.

Ich habe auch getan, was Sie mit einem separaten Projekt sagen. Ich denke, das ist in Ordnung.

Answer 3

Normalerweise habe ich eine Lösung, die eine Reihe von Projekten ohne Unit-Tests in dieser Hauptlösung enthält - das ist die Lösung, die im Release-Modus für einen echten Build erstellt wird.

Für ein bestimmtes Projekt habe ich eine separate Lösung, die das Projekt enthält, das ich testen möchte (und alle abhängigen) und ein MyProjectName.UnitTests-Projekt, das alle Komponententests für dieses Projekt enthält. Diese Komponententestprojekte werden dann in einer Continuous Integration-Maschine konfiguriert, um im Debug-Modus erstellt zu werden, und dann werden die Tests ausgeführt.

Funktioniert gut für mich.

Answer 4

Unter der Annahme, dass das Testprojekt in der gleichen Lösung wie das/die getestete (n) Projekt (e) ist, könnte eine kleine Verbesserung darin bestehen, einen Verweis auf das zu prüfende Projekt und nicht auf die Binärdatei im Debug-Ordner hinzuzufügen.

Zusätzlich zu dem, was hier erwähnt wurde, benutze ich oft auch das Assemblierungsattribut InternalsVisibleTo, um die internen Klassen der Baugruppe, die ich teste, für die Testbaugruppe sichtbar zu machen, d. H. Damit sie auch direkt getestet werden können.

Je nachdem, welches Isolationsframework Ihrer Wahl ist, müssen Sie möglicherweise auch die Interna Ihrer getesteten Assembly für Isolierungs-Framework-Komponenten sichtbar machen, um bestimmte interne Verhaltensweisen nachzuahmen/stubeln zu können.

Answer 5

Ich glaube nicht, dass es etwas falsch ist, dlls mit Code zu liefern, der beweist, dass selbst die DLL in einer Produktionsumgebung noch innerhalb festgelegter Parameter funktioniert :). Im Falle von seltsamen Fehlern können Sie die Komponententests immer noch mit der Release-DLL ausführen und sehen, ob etwas auf eine seltsame Art und Weise kaputt gegangen ist. Aus diesem Grund und weil ich nicht gerne die doppelte Anzahl an Projekten in einer Lösung habe, bevorzuge ich das Hinzufügen eines Tests-Ordners in jedem Projekt, wo der gesamte Unit-Test-Code läuft. Einfach und effektiv.

Grüße,

Sebastiaan