c# - unitarias - Visual Studio 2015 InvalidProgramException en prueba unitaria con falsificaciones

testing in c# visual studio

Question

Estoy usando Visual Studio 2015 Enterprise RTM para escribir pruebas unitarias para un proyecto que usa Unity Container .

Descubrí que el simple hecho de agregar un ensamblaje de falsificaciones para Unity, ni siquiera usar el falso, es suficiente para generar esta excepción:

System.InvalidProgramException: Common Language Runtime detectó un programa no válido.

Considere los siguientes pasos para reproducirse:

• Al utilizar Visual Studio 2015 Enterprise RTM, se crea un proyecto de prueba unitaria que se dirige a .NET 4.6

• Agregue el paquete NuGet "Unity" versión 3.5.1404.0

• Agregue el paquete NuGet "CommonServiceLocator" versión 1.2.0

• Escribe una prueba unitaria individual así:

[TestClass]
public class UnitTest1 : IDisposable
{
    [TestMethod]
    public void TestMethod1()
    {
        new ResolvedArrayParameter<IDisposable>(new IDisposable[] {this});
    }

    void IDisposable.Dispose()
    {
    }
}

• Verifique los pases de prueba

• Haga clic con el botón derecho en la referencia de Microsoft.Practices.Unity y seleccione "Agregar ensamblaje de falsificaciones".

• Vuelva a ejecutar la prueba

• Observe el siguiente fallo notable de la prueba:

Nombre de la prueba: TestMethod1
Test FullName: UnitTestProject11.UnitTest1.TestMethod1
Origen de la prueba: c: / temp / UnitTestProject11 / UnitTestProject11 / UnitTest1.cs: línea 12
Resultado de la prueba: error
Duración de la prueba: 0: 00: 00.0572447

Resultado StackTrace:

en Microsoft.Practices.Unity.ResolvedArrayParameter..ctor (Tipo arrayParameterType, Type elementType, Object [] elementValues)
en Microsoft.Practices.Unity.ResolvedArrayParameter`1..ctor (Object [] elementValues)
en UnitTestProject11.UnitTest1.TestMethod1 () en c: / temp / UnitTestProject11 / UnitTestProject11 / UnitTest1.cs: línea 13
Mensaje de resultado:
Método de prueba UnitTestProject11.UnitTest1.TestMethod1 lanzó la excepción:
System.InvalidProgramException: Common Language Runtime detectó un programa no válido.

La característica más extraordinaria de este problema es que evidentemente las falsificaciones ni siquiera necesitan aparecer directamente en el código para no manifestarse.

Una gran cantidad de violines revela que reorientar el proyecto de prueba a .NET 4.5 "soluciona" el problema, lo cual no es bueno para mí debido a another problema que publiqué hace algunas semanas.

Aún más violín con prácticamente todas las configuraciones falsas (contratos de código, etc.) no dieron solución.

Cualquier consejo sobre este tema sería muy apreciado.

Answer 1

La única solución general es asegurarse de que todas las partes coincidan con la versión de CLR que está utilizando muy de cerca y que VS tenga las últimas actualizaciones.

No hay una solución mágica para este problema. Necesita saber (excavar) la compatibilidad exacta de la versión CLR de todas las piezas que están conectadas en su proyecto cuando inyecta falsificaciones. Tenga en cuenta que la "compatibilidad" puede ser solo cuestión de manifestarse, pero con mayor frecuencia son la cuestión de los matices de cómo se generó / se genera el código final y para qué versión de la máquina virtual.

Normalmente, estas cosas no tienen importancia para la ejecución y la depuración, ya que existen varias capas que aseguran que las diferencias menores de versión no importen o que obtienes un cambio silencioso a lo que sea que tu código sea declarado compatible.

Pero, cuando usa Fakes, el "sistema" inyecta código sin procesar en su (que incluye bibliotecas de terceros involucradas) y eso significa que omite la mayoría de los controles; de lo contrario, no podría funcionar. Pero, cuando llega el momento de ejecutar realmente el código, el motor (máquina virtual) tiene que verificar su propia seguridad / integridad y tiende a volverse paranoico y rescatar si parece que las declaraciones no coinciden lo suficiente.

Esta es la razón por la cual alguien preguntó si las asambleas involucradas tienen un nombre fuerte o están firmadas. Ese es el único nivel de garantía en el que el "sistema" realmente confiará. Sin eso, se puede adivinar y, aunque en general no importa para las carreras normales, si importa mucho para la inyección de código.

Todavía no estoy hablando de posibles problemas reales, todo esto es suponer que el código real está bien y que las declaraciones son confusas. Podrías tratar de jugar con eso, pero tomaría mucho tiempo y esfuerzo. Es mucho más fácil verificar si puedes obtener versiones de ensamblajes que combinen mejor.

El hecho de que los errores desaparecieron cuando cambiaste tu sabor a 4.5 indica que algunos de los ensamblajes involucrados no están "lo suficientemente cerca" para 4.6 o pueden haber fallas técnicas con la inyección de código que fueron arregladas por actualizaciones que no has tomado todavía.

Sí, implica mucho dolor, pero ese es el precio de querer estar en la frontera.