2010-06-21 14 views
7

En mi proyecto, escribo pruebas utilizando el marco de prueba de unidades de Microsoft. Todas mis pruebas pasan cuando las dirigen desde Visual Studio, pero cuando corro las pruebas de MSBuild todas las pruebas de error con el siguiente mensaje erorr:Excepción de MSTest: el adaptador de prueba de unidad arrojó una excepción: el tipo no se resuelve para el miembro

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

La asamblea no encontrado es un montaje de 3 ª parte referenciada por todas de los proyectos.

La escritura de la estructura es utilizada por TFS así que he ADED las siguientes líneas:

<RunTest>true</RunTest> 

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

que he encontrado la this post que muestra una solución a este problema, pero por desgracia no puedo chnage los archivos en el TFS servidor.

¡Ayuda!

+0

es este montaje instalado en la GAC? –

+0

no, es un ensamblado .NET simple llamado Common.Logging –

Respuesta

3

Lo primero que se debe comprobar es si este conjunto se copia a la carpeta desde la que msbuild ejecuta las pruebas. Puede ser que tenga una copia en su carpeta bin/Debug debido a algunas razones históricas, pero la dependencia no está configurada correctamente en el proyecto.

+0

no, el dll se copia ... –

+0

¿es la versión correcta? y las dependencias de este dll? – Grzenio

+0

Creo que la versión es correcta y las únicas dependencias que este dll tiene es .NET BCL –

9

Me encontré con el mismo problema en mis pruebas unitarias. El artículo vinculado anteriormente indica que el problema es que VSTS causa la copia de algunos objetos en el CallContext de la secuencia.

Por lo que vale, en mi caso el problema fue que había colocado manualmente un objeto en el CallContext de la secuencia, lo que provocó esta excepción. Pude resolver esto borrando el CallContext en mi rutina TestCleanup. No tuve que cambiar ningún archivo en ninguna parte.

+1

[TestCleanup] public void Cleanup() {CallContext.FreeNamedDataSlot ("__ Key"); } - Sí, también me ha funcionado, ¡gracias! – Fabio

+0

Mi equipo tuvo un problema similar con nuestras pruebas unitarias. Pudimos hacer que funcionaran usando GetContext() y SetContext() en lugar de LogicalGetContext() y LogicalSetContext(). El beneficio de este enfoque fue que no tenemos que recordar "liberar" los elementos que colocamos en el contexto. Creemos que la desventaja de esto es que podría no funcionar en escenarios de AppDomain cruzados. – Paul

+0

Gracias, @Telewin y @Fabio !!! Gran ayuda! :) –

4

También me encontré con el mismo problema pero donde tenía la inicialización de StructureMap que se realiza dentro del constructor para una clase de prueba base.

Pude solucionar el problema moviendo la llamada del constructor al método [TestInitialize]. También me aseguré de que el método [TestCleanUp] eliminara el contenedor StructureMap creado. Después de esto MSBuild (2010) se ejecutará a través de las pruebas sin aumentar este error.

1

tenido este error

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

Al final resultó que el problema estaba en excepción lanzada en constructor estático para la prueba. No tenía ninguna relación con el aspecto del mensaje y estaba sucediendo durante la creación del DB mediante BuildSchema.

Mensaje de error muy poco informativo por MSTest que me costó muchas horas y estrés. colocando la migración en algo mejor como NUnit en nuestra lista de TODO.

0

This article resuelto mi problema con este error:

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.

Cuestiones relacionadas