Pregunta

Me gustaría ser capaz de ejecutar MSTest de confianza parcial. Esto permitiría que configure lo que el código, que mis pruebas de unidad de llamada, puede y no puede hacer.

El problema que estoy tratando de resolver es dejar que mis (unidad) pruebas automáticas fallan cuando se usan cosas como el sistema de archivos, bases de datos, reloj del sistema y otros recursos externos. Mediante la ejecución de confianza parcial puedo configurar qué tipo de acciones el dominio de aplicación pueden y no pueden hacer. Esto me permite detectar lugares en el código que no lo hacen correctamente abstraer los recursos usados.

Si hay otras maneras de lograr esto, por favor hágamelo saber.

¿Fue útil?

Solución

Por desgracia, MSTest no tiene incorporado un mecanismo para esto, y los cambios en la aplicación de políticas de CAS en .NET 4.0 han restringido severamente los enfoques adoptados para esto.

El método más sencillo para esto sería restringir la concesión permiso CAS en el dominio de aplicación creada por MSTest para ejecutar las pruebas en una prueba en particular el montaje. Sin embargo, las versiones actuales de MSTest no permiten la interceptación y / o personalización de la creación dominio de aplicación. No podemos evitar esto mediante la adición de código a un método ya que la política AssemblyInitialize dominio de aplicación los cambios realizados después del inicio de código que se ejecuta en el dominio de aplicación no tendrá ningún efecto.

Esto básicamente nos deja con un único mecanismo compatible para la aplicación de restricciones de permisos CAS para las pruebas de: aplicar un PermissionSet.PermitOnly desde dentro de un método de ensayo o el código que invoca el método de ensayo. por ejemplo:.

[TestMethod]
public void SomeTest()
{
    SomeStaticTestUtilityClass.TargetPermissionSet.PermitOnly();

    // Run the rest of your test code here.
}

Puede ser posible hacerlo a través de prueba de atributos personalizados utilizando el método descrito en el http://blogs.msdn.com/b/vstsqualitytools/archive/2009/09/04/extending-the-visual- estudio de unidad de prueba de tipo-parte-1.aspx . Sin embargo, no he probado esto, y no estoy seguro de si el mecanismo de invocación de método de prueba permitiría aplicar el PermitOnly de una manera que resultaría en que es estar presente en la pila de llamadas para el código de prueba.

Si usted tiene una gran cantidad de éstos al autor y el uso de una costumbre ITestMethodInvoker bien no funciona o es de otra manera inadecuada, otra opción sería utilizar un post-compilador como PostSharp para insertar las llamadas PermitOnly.

Si ninguno de estos trajes, y no está casado con MSTest, es posible que también desee considerar la posibilidad de cambiar su marco de pruebas a uno que es más fácilmente extensible.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top