Hilfe nUnit Tests in separates Projekt benötigen Bewegen

Question

Alles funktioniert gut, wenn die Unit-Tests Klasse Teil des Hauptprojekts (Testaccount) ist.

Jeder Artikel, den ich über Unit-Tests gelesen habe empfiehlt die Tests in einem separaten Projekt setzen, so dass ich ...

• hinzugefügt ein anderes Projekt (TestAccount.UnitTests) zu der Lösung
• bewegt, um die Unit-Tests Klasse (AccountTests.vb) zu TestAccount.UnitTests
• und fügte einen Verweis in TestAccount.UnitTests zu Testaccount (kopieren local = true)

Die Lösung kompiliert ohne Warnungen. Allerdings nUnit kann nicht das Hauptprojekt zugreifen und gibt die folgenden Fehler für jeden Test:

  

System.IO.FileNotFoundException: Konnte nicht geladen werden Datei oder Assembly 'Testaccount, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' oder eine ihrer Abhängigkeiten. Die angegebene Datei wurde vom System nicht gefunden.

Was mache ich falsch?

(Ich habe ähnliche Probleme mit nunit.framework.dll bis ich es dem GAC hinzugefügt)

Screenshot Lösung Explorer http://img440.imageshack.us/img440/4862 /nunitsolutionexploreree3.jpg

Visual Studio 2005
.NET 2.0
nUnit 2.4.8 (.NET 2.0-Version)

[Bearbeiten] Ich habe nur dieses Problem haben, wenn nUnit von Visual Studio (als externen Befehl) ausgeführt wird. Wenn ich die nUnit Konsole unabhängig zu laden, es funktioniert gut.

[Bearbeiten] Omar: Ja, ich habe den Verweis auf das andere Projekt. Hier ist ein Screenshot von meiner Lösung Explorer

Ich glaube, ich könnte müssen nur separat die nUnit Konsole ausführen (statt durch VS External Tools).

Answer 1

fand ich einen Bugreport rel="nofollow das sagt Visual Studio falsch die TargetPath und TargetDir Makros erweitert. Sie erweitern mit dem Obj \ Verzeichnis, nicht bin \

[Update] Das Problem / Lösung ist eigentlich in der Visual Studio Unterstützung Abschnitt der Dokumentation. Da die 'Target' Makros Obj \ zeigen, können Sie sie nicht out-of-the-Box verwenden. Ich landete mit dem folgenden Ausdruck im Feld Argumente:

$(ProjectDir)bin/Debug/$(TargetName)$(TargetExt)

Answer 2

Das klingt vielleicht albern, aber ich werde für das Offensichtliche gehen haben Sie Ihr Testprojekt einen Verweis auf das andere Projekt gegeben?

Weitere Themen, die für diese Art von Problem üblich sind, ist die Verwendung von internen Klassen, die nicht aus einem anderen Projekt / Namensraum zugegriffen werden.

Answer 3

Auch stellen Sie sicher, dass die Assembly Ausgabepfad entspricht dem, was in Ihrer NUnit-Konfiguration eingerichtet ist. Ich habe das gleiche Setup, aber ich muss nicht gesetzt ‚Kopie local = true‘

Answer 4

Ist das Problem damit die Anwendung nicht finden, selbst oder einer der Abhängigkeiten der Anwendung? Sie könnten versuchen, entweder FileMon oder die Fusion Log Viewer, um zu sehen, was genau mit versagt. Es ist möglich, das Problem ist nicht bei der Suche nach der App selbst, sondern in einer anderen Abhängigkeit zu lokalisieren. Stellen Sie sicher, dass alle Abhängigkeiten Kopieren Lokale Satz auf True.

Wie genau beginnen Sie die NUnit GUI in Visual Studio? Wenn Sie den „Start externes Programm“ setzen unter den Eigenschaften des Projekts, gibt es Ihnen die Möglichkeit, das Arbeitsverzeichnis angeben. Möglicherweise müssen Sie dies Ihr Test dll auf die Build-Position ändern.