2009-09-11 11 views
12

Se un assembly contiene un file app.config, ConfigurationManager lo caricherà fino a quando si trova nella stessa directory del progetto NUnit in esecuzione tramite NUnit-Gui. Per illustrare considerare la seguente struttura di cartelle.Come si ordina a NUnit di caricare il file dll.config di un assieme da una directory specifica?

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

Sia AssemblyA e AssemblyB codice di esercizio che mette in ConfigurationManager. Se eseguo questi assembly di test in modo indipendente in NUnit-Gui, ConfigurationManager risolverà correttamente i file di configurazione locali.

Tuttavia, se carico testProject.nunit in NUnit-Gui (che contiene i riferimenti a entrambi AssemblyA e AssemblyB), ConfigurationManager cerca il file di configurazione in TestFolder indipendentemente da quale di montaggio è attualmente in esecuzione.

C'è un modo per indirizzare NUnit per ricaricare la configurazione dell'applicazione su quella presente nella directory dell'assembly corrente?

Ecco il contenuto della testProject.nunit:

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

Non è una risposta esatta, ma è possibile unire i due file di configurazione e crearne uno per l'intero progetto di test? – TrueWill

+0

Fortunatamente, questo dovrebbe funzionare nel mio caso poiché sto leggendo sezioni di configurazione distinte in ogni assembly.Sono curioso di sapere se esiste un approccio migliore o più generale. –

risposta

1

Il blog NUnit spiegato del perché i file di configurazione caricano il loro modo di fare. Fondamentalmente ciò che hanno detto è che NUnit consente al framework di gestire i file di configurazione e non esegue alcuna gestione.

È inoltre possibile utilizzare il file testProject.config che verrebbe caricato nel proprio caso, per fare riferimento ai file di configurazione per ciascuno degli assiemi. Utilizzando l'attributo file appSettings per aggiungere chiavi.

Un'alternativa finale è utilizzare configSource element attribute per utilizzare la sezione in uno dei file di configurazione degli assiemi.

Spero che questo aiuti.

3

L'elemento configSourcesolution given by MarkLawrence è quello che stavo cercando, e funziona bene. Tuttavia, la sfida nell'implementazione di questa soluzione consiste nel caricare la configurazione dell'assieme durante l'esecuzione di test da un progetto NUnit esplicito (come in my case), AND durante l'esecuzione dei test dell'unità per un assieme in isolamento (nessun progetto esplicito). Per fare ciò, erano necessarie le seguenti modifiche al mio layout di file.

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

I file configfragment sono creati per contenere la configurazione di montaggio che era una volta nelle corrispondenti config file. Successivamente, i file config vengono modificati per contenere solo un elemento configSource con un percorso relativo al file configfragment corrispondente. Si noti che l'unica volta in cui questo approccio non funziona è quando assemblyA.dll e assemblyB.dll richiedono entrambi la stessa sezione di configurazione, poiché si verificherà un conflitto durante la creazione di testproject.config.

Dopo aver sperimentato questo approccio, ho deciso di affidarmi alla generazione della configurazione dell'assembly in fase di esecuzione e rimuovere tutti i file di configurazione statici. Ecco un codice che mostra come generare la configurazione e renderla accessibile indipendentemente da come viene caricato l'assembly-under-test.

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); 
    } 
} 

Usando il ConfigurationManager.OpenExeConfiguration() di sovraccarico che non accetta un percorso, si carica la configurazione dalla directory di lavoro dell'applicazione host, che cambia a seconda di come si esegue i test NUnit. Inoltre, il blocco try/finally garantisce che la configurazione dell'assembly non interferisca con altri test, che potrebbero richiedere o meno tale configurazione.

Infine, da utilizzare all'interno di una prova di unità:

[Test] 
void VerifyFunctionality 
{ 
    WithConfigurationFile(delegate 
    { 
     // implement unit test and assertions here 
    }); 
} 

Spero che questo aiuta gli altri che possono aver incontrato problemi simili!

2

utilizzare l'attributo configfile nel livello di configurazione nel file .nunit:

 

<Config name="Debug" configfile="myconfigfilenamegoeshere.config /> 
 
5

Nunit è in grado di individuare il percorso del file App.config nel nostro progetto. Quindi dobbiamo dire manualmente a Nunit dove il file App.config è inserito nel nostro progetto (ovviamente nella cartella root).

Nel mio caso, la struttura del progetto è la seguente

 +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 

il ProjectWebApp utilizza i riferimenti di projectBusinesslogic che contiene la logica di business. il + ProjectTestName utilizza il riferimento di projectBusinesslogic per eseguire test sulla business logic. I problemi iniziano qui, il progetto di test di Nunit ha bisogno del proprio file app.config. non utilizzerà il file web.config come nel caso di projectBusinesslogic, quindi quando si esegue Nunit verrà visualizzato un errore

-Null eccezione di riferimento ....... oggetto istantaneo non impostato su ... ........

cura- Quando si esegue la GUI Nunit

  1. Progetto-> Modifica di un nuovo pop-up si aprirà
  2. Proprietà -> Generale-> File di configurazione Nome-> aggiungi il tuo app.config Nome file
  3. File-> salvare e chiudere la finestra pop-up
  4. ON Nunit Gui-File-> Ricarica Progetto

e che è la soluzione più semplice per il vostro problema

+1

È incredibile il mio problema in tutto questo tempo non stava facendo il passaggio 4! Grazie!!! – craastad

+0

Grazie, i tuoi passaggi 1 - 4 sono bastati! – Flea

0

In realtà, se si utilizza NUnit e un corridore in Visual Studio, è possibile mantenere il valore in App.config nel progetto di test. Quindi aggiungere questa riga al vostro evento post-generazione:

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

Quando si accede al ConfigurationManager nella vostra test, NUnit passerà i valori nel tuo app.config a .Net nel metodo di inizializzazione.

Problemi correlati