2010-06-21 9 views
7

Nel mio progetto scrivo test utilizzando il framework di test unitario di Microsoft. Tutti i miei test passano quando li corro da Visual Studio, ma quando ho eseguito i test da MSBuild tutti i test non con il seguente messaggio erorr:MSTest exception: Adapter Test Adapter ha gettato un'eccezione: Type non risolto per membro

Unit Test Adapter threw exception: Type is not resolved for member SomeType,SomeAssembly Version=assemblyVersion, Culture=neutral, PublicKeyToken=..

Il montaggio non trovato è un assembly 3rd party a cui fa riferimento tutto dei progetti.

Lo script di build è utilizzato da TFS in modo Sono ADED le seguenti righe:

<RunTest>true</RunTest> 

<ItemGroup> 
    <MetaDataFile Include="$(BuildProjectFolderPath)myproject.vsmdi"> 
     <TestList>CI_Tests</TestList> 
    </MetaDataFile> 
</ItemGroup> 

ho trovato il this post che mostra una soluzione a questo problema, ma purtroppo non posso chnage i file sul TFS server.

Help!

+0

è questa assemblea installato nella GAC? –

+0

no, è un semplice assembly .NET chiamato Common.Logging –

risposta

3

La prima cosa da verificare sarebbe se questo assembly viene copiato nella cartella da cui msbuild esegue i test. Potrebbe essere il caso di avere una copia nella cartella bin/debug a causa di alcuni motivi storici, ma la dipendenza non è impostata correttamente nel progetto.

+0

no, la dll è copiata ... –

+0

è la versione corretta? e le dipendenze di questa dll? – Grzenio

+0

Penso che la versione sia corretta e le uniche dipendenze di questa DLL sono .NET BCL –

9

Ho riscontrato lo stesso problema nei miei test di unità. L'articolo collegato sopra indica che il problema è che VSTS causa la copia di alcuni oggetti nel CallContext del thread.

Per quello che vale, nel mio caso il problema era che avevo inserito manualmente un oggetto nel CallContext del thread, che ha causato questa eccezione. Sono stato in grado di risolvere questo cancellando CallContext nella mia routine di TestCleanup. Non ho dovuto modificare alcun file da nessuna parte.

+1

[TestCleanup] public void Cleanup() {CallContext.FreeNamedDataSlot ("__ Key"); } - Sì, ha funzionato anche per me, grazie! – Fabio

+0

La mia squadra ha avuto un problema simile con i nostri test unitari. Siamo stati in grado di farli funzionare utilizzando GetContext() e SetContext() invece di LogicalGetContext() e LogicalSetContext(). Il vantaggio di questo approccio è che non dobbiamo ricordare di "liberare" gli oggetti che inseriamo nel contesto. Pensiamo che il lato negativo di questo è che potrebbe non funzionare in scenari cross AppDomain. – Paul

+0

Grazie, @Telewin e @Fabio !!! Grande aiuto !!! :) –

4

Avevo anche incontrato lo stesso problema, ma in cui l'inizializzazione di StructureMap è stata eseguita all'interno del costruttore per una classe di test di base.

Sono stato in grado di aggirare il problema spostando la chiamata dal costruttore al metodo [TestInitialize]. Ho anche assicurato che il metodo [TestCleanUp] eliminasse il contenitore StructureMap creato. Dopo questo MSBuild (2010) avrebbe eseguito i test senza generare questo errore.

1

ha avuto questo errore

Unit Test Adapter threw exception: 
Type is not resolved for member 'NHibernate.HibernateException,NHibernate 

Come si è scoperto che il problema era in deroga gettato in costruttore statico per il test. Era completamente estraneo all'aspetto del messaggio e stava accadendo durante la creazione del DB usando BuildSchema.

Messaggio di errore molto disinformativo da parte di MSTest che mi è costato un sacco di ore e stress. inserendo la migrazione in qualcosa di meglio come NUnit nella nostra lista TODO.

0

This article Ha risolto il problema con questo errore:

To recap, MyCustomException was thrown at very early stage of test execution. The dll that contained it was not loaded yet so Unit Test Adapter indeed could not reach it.

Problemi correlati