Unit Testing and PostSharp

Question

Me pregunto cuál es la mejor manera de hacerlo ... Me interesa introducir PostSharp en uno de mis proyectos, pero no estoy seguro de cómo unidades de clases de prueba marcadas con un atributo correctamente.

Por ejemplo:

public class hello { 

    [MyAspectThatDoesSomethingToTheDatabaseWhenThisMethodGetsCalled] 
    public int omg(string lol) { 
     //fancy logic in here 
    } 
} 

me gustaría probar la lógica en el método de OMG(), pero en las pruebas de unidad que necesita para asegurarse de que el aspecto no quede llama, porque hay no es realmente una base de datos.

¿Pensamientos?

Answer 1

Probablemente puede usar la inyección de dependencia e introducir una propiedad estática para la clase de aspecto donde decide qué tipo de proveedor de acceso a la base de datos usará (por ejemplo, utilizando una fábrica), configurando el falso en el alcance de una prueba.

Answer 2

Mi opinión es que debe probar el código como si el aspecto se codificara manualmente, es decir, probar la funcionalidad completa del método, incluidas las funcionalidades implementadas por el aspecto.

La pregunta es ahora documentados en la documentación en línea en PostSharp http://doc.postsharp.net/postsharp-3.0/Content.aspx/PostSharp-3.0.chm/html/2ad6cf92-08eb-4537-a434-d88a3e493721.htm

Answer 3

No estoy de acuerdo con Gael. Un amigo me ha dicho que debo probar el código que voy a escribir y, en general, solo una vez.

Answer 4

No estoy del todo seguro de cómo funciona postsharp, pero como actualmente entiendo, invocas un proceso de creación posterior para entretejer los aspectos en el IL.

Si mi comprensión es correcta y si puede omitir el tejido posterior a la construcción, entonces debe probar su método ignorando el aspecto (y probar el aspecto por separado en otro lugar).

¿Por qué?

Si el resultado es el aspecto y el método, que está probando 3 cosas a la vez:

1. el método
2. el aspecto
3. el tejido del aspecto en el código

Esto es mal karma y puede llevarte por el agujero del conejo si algo sale mal (además de convertir tu prueba de unidad en una prueba de integración).

Mirando la lista anterior:

• que hacer necesidad de prueba el método, de manera aislada, sin otras distracciones como esto le permitirá centrarse en asegurarse de que el método hace exactamente lo que espera, ni más ni menos.
• que no necesidad de prueba el aspecto cada vez se usa, sólo prueba una vez y asegúrese de que hace lo que usted cree
• que no lo hace necesita prueba que el tejido funciona; es (debería) probarse como parte de la implementación posterior.

Answer 5

Para desactivar aspectos relacionados con la base de datos en mi código, presenté una clase estática llamada TestingEnvironment con una propiedad booleana llamada TurnOffAspects. El código en aspecto verifica esta propiedad y si se establece en "verdadero", el aspecto regresa sin hacer nada. Durante la configuración de la prueba, establecí la propiedad TestingEnvironment.TurnOffAspects en verdadero y, durante el desmontaje de la prueba, regreso a falso. Por supuesto, puede hacer que las cosas sean más granulares introduciendo una propiedad por cada aspecto que tenga. Debe elegir muy cuidadosamente qué aspectos desactiva, ya que pueden tener un gran impacto en la prueba y hacer que su código de producción falle incluso cuando la prueba pase.

Answer 6

Si desea escribir la prueba UNIT pura, considere deshabilitar PostSharp para el módulo durante las pruebas UNIT TESTING estableciendo el símbolo de compilación 'SkipPostSharp' en su proyecto o establezca la propiedad MSBuild 'SkipPostSharp = True'.

Si usted está dispuesto a hacer integración prueba, puede probar la funcionalidad completa de su método y atributo PostSharp, incluido el acceso DB (como suggested by Gael).

Answer 7

Mi enfoque actual es hacer que las pruebas se ejecuten como parte del proceso de compilación en nuestro TFS. Esto puede no ser útil para todos los escenarios, pero he pasado bastante tiempo para encontrar una solución que me permita ejecutar las pruebas unitarias de nuestra lógica comercial sin ningún impacto de PostSharp.

Creé dos definiciones de compilación diferentes, una de las cuales tiene los Argumentos MSBuild establecidos en /p:SkipPostSharp=True (este es el que ejecuta las pruebas unitarias) y el otro en False respectivamente. Además, configuro la opción Disable Tests en True para la definición de compilación usando PostSharp.

Sé que esto no es ideal (especialmente porque ahora tengo el problema de no poder ejecutar las pruebas localmente sin ningún cambio), pero no pude encontrar ninguna otra forma de evitarlo. Parece que no hay demasiadas personas con los mismos problemas. Como soy un novato absoluto en términos de MSBuild y su configuración, tal vez alguien con un mejor conocimiento podría ayudar.

También jugué con el Configuration Manager en Visual Studio para crear otra definición de construcción, pero todos mis intentos solo produjeron más problemas que cualquier otra cosa.