2011-10-17 11 views
9

Sto lavorando su un'applicazione e ho creato un numero di unit test per questo. Il progetto con la classe di test dipende da 3 DLL di terze parti. Quando vado nella cartella bin \ Debug per il progetto di test, le Dll ci sono. Ma quando eseguo il test, le DLL non vengono copiate nella cartella TestResult \\ Out.Come posso ottenere un test unitario per copiare le mie DLL e altri file quando eseguo un test?

C'è anche un file log4net.config da un altro progetto che vorrei copiare. Questo non viene visualizzato nella cartella bin \ Debug del progetto di test, quindi è un altro problema che devo risolvere.

Come posso copiare questi file quando eseguo il test dell'unità?

Tony

+1

Con quale unità test? NUnit? MSTest? – vcsjones

+0

MSTest, penso. Lo strumento che si trova in Visual Studio 2010. –

risposta

5

Abbiamo una cartella bin contenente 3rd-party DLL che devono essere parte delle generazioni. Sono contrassegnati con l'attributo 'copia locale' nel riferimento.

Come per i singoli file, è possibile fare lo stesso - Impostare "Copia nella directory di output" su true.

+0

Grazie! Quello ha riparato le DLL. Non capisco come risolvere il problema con il file log4net.config. Quello è in un altro progetto e ha la proprietà "Copia nella directory di output" impostata su "Copia se più recente" (sto usando VS 2010). Ma non viene copiato nella cartella bin \ Debug del progetto Test e il test dipende da quel progetto. –

0

La copia di tali dll (a parte il loro riferimento, dove si può dire Copy Local) e inserirli nella cartella esterna non dovrebbe essere parte dei test, ma parte del processo di creazione/confezionamento. Crea script che facciano la copia necessaria delle DLL.

+0

Le DLL sono referenziate ma non sono state copiate. Era perché la proprietà Copia locale per quelle DLL era falsa. Non fanno altrimenti parte del processo di test, tranne che sono utilizzati dal codice. –

9

È possibile utilizzare DeploymentItemAttribute per copiare i file nella directory bin (o altra).

[TestMethod()] 
[DeploymentItem("log4net.config")] 
public void SomeTest() 
{ 
    ... 
} 
+0

Darò una prova quando torno al lavoro al mattino. Sembra promettente! –

+0

Mi hai appena salvato la vita! Molte grazie. – RoadBump

0

Durante il debug dallo studio, utilizzare l'attributo di distribuzione sulla classe o TestMethod per copiare le DLL ei file necessari di configurazione nella cartella di partenza da dove vengono eseguiti MSTests. Se si esegue dalla riga di comando, utilizzare un file TestSettings e disabilitare l'opzione di distribuzione e impostare la cartella BIN come directory di lavoro. Utilizzare/riferire questo file TestSettings nella riga di comando per eseguire mstest. In questo modo, è possibile eseguire Mstest direttamente nella cartella BIN senza dover scaricare le DLL in una directory esterna. Ancora una volta, usa l'attributo di deployment per eseguire il debug da studio, in questo caso le testettings non funzioneranno.

1

Ho trovato se i test vengono distribuiti nell'area di test (true per impostazione predefinita), la copia locale non funzionerà in alcune circostanze come il caricamento dinamico degli assiemi.

È possibile sia eliminare questa distribuzione off utilizzando un file runsettings (https://msdn.microsoft.com/en-us/library/ms182475.aspx) e

<DeploymentEnabled>False</DeploymentEnabled> 

Oppure, un piccolo trucco (un po 'brutto in quanto richiede manuale/codifica difficile il montaggio), utilizzando un DeploymentItem per il binario (detto in altre risposte, ma, non specifiche per la gestione DLL come da OP):

[DeploymentItem("bin\\release\\iRock.dll")] 
[DeploymentItem("bin\\debug\\iRock.dll")] 

consiglio di fare sia il debug/release, a seconda di ciò che viene utilizzato sul vostro CI/Dev.