Comment demandez-vous à NUnit de charger le fichier dll.config d'un assembly à partir d'un répertoire spécifique?

Si un ensemble contient une application.fichier de config, ConfigurationManager charge tant qu'il est dans le même répertoire que le NUnit projet qui est en cours d'exécution par le biais de NUnit-Gui. Pour illustrer considérer la structure de dossier suivante.

+ TestFolder
    testProject.nunit
  + AssemblyAFolder
      assemblyA.dll
      assemblyA.dll.config
  + AssemblyBFolder
      assemblyB.dll
      assemblyB.dll.config

Les deux AssemblyA et AssemblyB exercice de code qui appelle ConfigurationManager. Si j'exécute ces montages d'essai de façon indépendante dans NUnit-Gui, ConfigurationManager de résoudre correctement les fichiers de configuration locaux.

Cependant, si je charge testProject.nunit en NUnit-Gui (qui contient des références à la fois AssemblyA et AssemblyB), ConfigurationManager regarde le fichier de configuration dans TestFolder indépendamment du fait que l'assemblée est en cours d'exécution.

Est-il un moyen pour diriger NUnit pour recharger la configuration de l'application à celui présent dans l'actuelle assemblée du répertoire?

Voici le contenu de testProject.nunit:

<NUnitProject>
  <Settings activeconfig="Debug" />
  <Config name="Debug" binpathtype="Auto">
    <assembly path="AssemblyAFolder\assemblyA.dll" />
    <assembly path="AssemblyBFolder\assemblyB.dll" />
  </Config>
</NUnitProject>

source d'informationauteur Steve Guidi

2

La NUnit blog a expliqué pourquoi les fichiers de configuration de la charge de la façon dont ils le font. Fondamentalement, ce qu'ils ont dit que NUnit permet au cadre de manipuler les fichiers de configuration et de ne pas faire de la gestion.

Vous pouvez également utiliser le testProject.config fichier qui est chargé dans votre cas, pour faire référence à des fichiers de configuration pour chacune des assemblées. À l'aide de la appSettings attribut de fichier pour ajouter les touches.

Une dernière solution consiste à utiliser la configSource attribut d'élément l'utilisation de la section dans l'une des assemblées des fichiers de configuration.

Espère que cette aide.
5

Nunit est incapable de retrouver le chemin de l'Application.Fichier de config dans notre projet. Donc nous avons besoin d'informer manuellement le Nunit où l'Application.Fichier de config est placé dans notre projet (évidemment sur le dossier racine).

Dans mon cas , la structure du projet est le suivant
```
     +ProjectWEBApp//web pages
       +Modules
         +aspx pages
       +web.Config

    +projectBusinesslogic //business logic .cs files
       +Modules
         +.cs

      +ProjectTestName//a seperate Nunit test cases project
        +Modules
      +App.Config
```
la ProjectWebApp utilise les références de projectBusinesslogic qui contient la logique métier.
le +ProjectTestName utilise la référence de projectBusinesslogic d'effectuer des tests sur la logique métier.
Les problèmes commencent ici, Nunit projet de test nécessite sa propre application.fichier de configuration. ne pas utiliser le web.fichier de configuration comme dans le cas de projectBusinesslogic,de sorte que lorsque vous exécutez Nunit il vous invite une erreur

-Référence nulle exception.......objet instantanée n'est pas définie à ...........

Solution
Lorsque vous exécutez le Nunit GUI
1. Projet->Modifier un nouveau pop up va s'ouvrir
2. Propriétés -> Général>Nom du Fichier de Configuration-> ajouter votre app.config Nom de Fichier
3. Fichier->enregistrer et fermer la fenêtre pop-up
4. SUR Nunit Gui-Fichier-> Recharger Projet
et c'est la solution simple à votre problème
3

La configSource élément solution donnée par la MarkLawrence est ce que je cherchais, et fonctionne très bien. Le défi de la mise en œuvre de cette solution, cependant, est de permettre à l'assemblée de la configuration de la charge lors de l'exécution de tests à partir de deux explicite NUnit projet (comme dans mon cas), ET lors de l'exécution de tests unitaires pour une assemblée à l'isolement (l'absence explicite de projet). Pour ce faire, les modifications suivantes à mon fichier de mise en page ont été nécessaires.
```
+ TestFolder
    testProject.nunit
    testProject.config
  + AssemblyAFolder
      assemblyA.dll
      assemblyA.dll.config
      assemblyA.dll.configfragment
  + AssemblyBFolder
      assemblyB.dll
      assemblyB.dll.config
      assemblyB.dll.configfragment
```
La configfragment fichiers sont créés pour contenir la configuration de montage qui a été une fois dans le config fichiers. Par la suite, le config fichiers sont modifiés pour contenir seulement un configSource élément avec un chemin relatif vers le correspondant configfragment fichier. Notez que la seule fois que cette approche ne fonctionne pas, c'est quand assemblyA.dll et assemblyB.dll à la fois besoin de la même section de configuration, comme un conflit de survenir lors de la création de testproject.config.

Après avoir expérimenté cette approche, j'ai décidé de compter sur la génération de la configuration de montage au moment de l'exécution, et de supprimer les fichiers de configuration statique tous ensemble. Voici un code qui montre comment générer la configuration, et de le rendre accessible indépendamment de la façon dont l'assemblée-sous-essai est chargé.
```
void WithConfigurationFile(Action method)
{
    //Create the assembly configuration.
    string settingsSection = "myConfigSectionName";
    Configuration config =
        ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
    config.Sections.Add(
        settingsSection,
        new ConfigSectionType(/*config element values*/);
    config.Save();

    try
    {
        //Invoke the method with the new configuration.
        ConfigurationManager.RefreshSection(settingsSection);
        method();
    }
    finally
    {
        //Revert the assembly configuration.
        File.Delete(config.FilePath);
        ConfigurationManager.RefreshSection(settingsSection);
    }
}
```
À l'aide de la ConfigurationManager.OpenExeConfiguration() surcharge qui n'accepte pas un chemin, nous charger la configuration de l'application hôte du répertoire de travail, qui varie en fonction de la façon dont vous exécutez vos tests NUnit. Aussi, le try/finally bloc garantit que votre configuration de montage ne sera pas interférer avec d'autres tests, ce qui peut ou ne peut pas exiger une telle configuration.

Enfin, pour l'utilisation dans un test unitaire:
```
[Test]
void VerifyFunctionality
{
    WithConfigurationFile(delegate
    {
        //implement unit test and assertions here
    });
}
```
J'espère que cela aide d'autres personnes qui ont rencontré des problèmes similaires!
2

Utiliser le configfile attribut dans le fichier de configuration de niveau dans votre .nunit fichier:
```
<Config name="Debug" configfile="myconfigfilenamegoeshere.config />
 
```
0

En fait, si vous utilisez NUnit et un coureur au sein de Visual Studio, vous pouvez coller votre valeur dans une Application.config dans votre projet de test. Ensuite, ajoutez cette ligne à votre événement Post-build:

copier /Y“, $(ProjectDir)App.config” “$(TargetDir)$(TargetFileName).config”

Lorsque vous accédez à la ConfigurationManager dans vos tests, NUnit permettra de transmettre les valeurs de votre application.config .Net dans la méthode initialize.

Vous devez vous connecter pour publier un commentaire.