Besoin d'aide pour déplacer les tests nUnit dans un projet séparé

Question

Tout fonctionne bien lorsque la classe de tests unitaires fait partie du projet principal (TestAccount).

Chaque article que j'ai lu sur les tests unitaires recommande de placer les tests dans un projet séparé, pour que je ...

• a ajouté un autre projet (TestAccount.UnitTests) à la solution
• a déplacé la classe de tests unitaires (AccountTests.vb) vers TestAccount.UnitTests
• et ajouté une référence à TestAccount dans TestAccount.UnitTests (copie locale = true)

La solution est compilée sans aucun avertissement. Cependant, nUnit ne peut pas accéder au projet principal et génère l'erreur suivante pour chaque test:

  

System.IO.FileNotFoundException: impossible de charger le fichier ou l'assembly 'TestAccount, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null' ou l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.

Qu'est-ce que je fais de travers?

(J'avais un problème similaire avec nunit.framework.dll jusqu'à ce que je l'ajoute au GAC)

capture d'écran de l'explorateur de solutions http://img440.imageshack.us/img440/4862 /nunitsolutionexploreree3.jpg

Visual Studio 2005
.NET 2.0
nUnit 2.4.8 (version .NET 2.0)

[Modifier] Ce problème ne concerne que l'exécution de nUnit à partir de Visual Studio (en tant que commande externe). Si je charge la console nUnit indépendamment, cela fonctionne bien.

[Modifier] Omar: oui, j'ai la référence à l'autre projet. Voici une capture d'écran de l'explorateur de solutions

.

Je pense que je devrais peut-être simplement exécuter la console nUnit séparément (au lieu d'utiliser les outils externes de VS).

Answer 1

J'ai trouvé un rapport de bogue . qui dit que Visual Studio ne développe pas correctement les macros TargetPath et TargetDir. Ils se développent dans le répertoire obj \, pas bin \

[Mise à jour] Le problème / la solution est en fait décrit dans le prise en charge de Visual Studio. section de la documentation. Étant donné que les macros "Cible" pointent sur obj \, vous ne pouvez pas les utiliser telles quelles. J'ai fini par utiliser l'expression suivante dans le champ Arguments:

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

Answer 2

Cela peut paraître idiot, mais je vais passer à l’évidence. Avez-vous donné à votre projet test une référence à l’autre projet?

L’utilisation de classes internes impossibles à accéder depuis un autre projet / espace de nom est un autre problème commun à ce type de problème.

Answer 3

Assurez-vous également que votre chemin de sortie d'assemblage correspond à ce qui est configuré dans votre configuration NUnit. J'ai la même configuration mais je n'ai pas à définir 'copy local = true'

Answer 4

Le problème est-il que l'application ne trouve pas l'application elle-même ou l'une de ses dépendances? Vous pouvez essayer d’utiliser FileMon ou Fusion View Viewer pour voir ce qui ne fonctionne pas. Il est possible que le problème ne réside pas dans la recherche de l'application elle-même, mais dans la localisation d'une autre dépendance. Assurez-vous que les dépendances ont la valeur Copie locale définie sur Vrai.

Comment démarrez-vous exactement l'interface graphique NUnit dans VisualStudio? Si vous définissez l'option "Démarrer le programme externe" sous les propriétés du projet, vous avez la possibilité de spécifier le répertoire de travail. Vous devrez peut-être changer ceci pour l’emplacement de compilation de votre DLL de test.