¿Qué es una buena estrategia de prueba de integración?

7

Estoy iniciando un proyecto en el que quiero tener una cobertura de prueba bastante completa y tengo el lujo de conducir la estrategia de prueba. Me decidí por un plan viable para pruebas de unidad, y también decidí usar Gherkin para describir características y un puerto de Cucumber para ejecutar los escenarios como pruebas de aceptación de extremo a extremo.

El problema es que siento que hay una brecha entre esas dos capas. Puedo probar todas mis unidades de forma aislada y puedo probar que mis funciones funcionan, pero puedo pensar en otras cosas que voy a querer probar.

También provengo de un proyecto diferente con pruebas automatizadas (mal implementadas) que son muy frágiles y son una pesadilla de mantenimiento, el objetivo de estas pruebas es reemplazar principalmente las pruebas de regresión manual. Escribir pruebas más mantenibles es una obligación, pero en un nivel superior no estoy seguro de que nuestras pruebas sean las correctas.

Como ejemplo, dada una aplicación web, digamos que hay un formulario para agregar un evento con fechas de inicio y finalización. Como una prueba de extremo a extremo, podemos validar que puede, de hecho, agregar un evento. Pero si su fecha de inicio es posterior a la fecha de finalización, recibirá un mensaje de error y no creo que la forma en que se maneja un error de entrada trivial del usuario pertenezca a un archivo de características. Por otro lado, parece haber una creencia bastante fuerte de que la prueba de unidad de la interfaz de usuario no vale la pena; en su lugar, uno debería hacer pruebas de integración automatizadas.

Entonces, ¿qué hago para este código?

¿Realizo una prueba de unidad de los componentes relacionados con los mensajes de error en general, así como que este formulario los mostrará y omito la automatización para que aparezcan? ¿Hago lo anterior y luego automatizo que solo se muestre un mensaje de error en algún lugar según lo previsto, y asumo que el resto funcionará? ¿Intento automatizar cada caso de error potencial diferente para cada formulario?

Esto llega al punto medio de las pruebas de integración, de las cuales estoy receloso. Según mi experiencia, mantener un gran número de pruebas de integración no parece valer la pena. Por otro lado, existe una funcionalidad por encima del nivel de la unidad y por debajo del nivel de la función que, idealmente, me gustaría probar, tanto en la interfaz de usuario como fuera de ella. Y me preocupa qué tipo de confianza puede aportar la regresión automática si no afecta a todo.

Estoy perfectamente dispuesto a escribir pruebas de integración, pero en el contexto de cuándo escribir pruebas, qué pruebas escribir y cuántas escribir, ¿cuál es un buen enfoque para abordar este problema?

    
pregunta Kate Jo 29.04.2014 - 03:49

3 respuestas

3

Todo se reduce a ser rentable y pragmático. Debido a que usted está a cargo de las pruebas para este proyecto, tenga cuidado de no utilizar todos los tipos de métodos de prueba o de cambiar las cosas que han funcionado en el pasado, o de introducir un montón de nuevas herramientas o prácticas solo por el hecho de hacerlo. No estoy diciendo que ese sea tu plan, solo quería decirlo.

Si la GUI contiene mucha lógica, que no debería, entonces debe ser probada. Idealmente, la GUI contiene muy poca lógica (o ninguna, pero en realidad eso es un desafío). Si contiene mucha lógica, vea si es factible o más barato refactorizar el código GUI en lugar de crear y mantener una gran base de pruebas de GUI lentas. Si la interfaz gráfica de usuario contiene poca o ninguna lógica, entonces es posible que no pueda probarla en absoluto, o muy pocas pruebas básicas para asegurarse de que las "conexiones" estén bien, como se mencionó anteriormente. Además, como solo hay unos pocos, no tiene que preocuparse por su rendimiento y la sobrecarga de mantenimiento no es tan alta.

Sin embargo, deberías realizar una prueba de integración del resto de tu sistema (al menos la excepción GUI). El sistema debe diseñarse de tal manera que no requiera una GUI para manejarlo, podría ser una interfaz de línea de comandos (automatizada), una interfaz de servicio web, etc.

Debe haber el mayor número de pruebas unitarias, luego un número menor de estas pruebas de integración "básicas" y muy pocas pruebas grandes / GUI.

    
respondido por el jordan 03.05.2014 - 06:21
0

Haz BDD. Escriba pruebas de aceptación para definir los escenarios importantes del sistema. Tendrá la mayoría de las pruebas de integración que necesita, además de documentación valiosa y una prueba de que su sistema hace lo que se supone que debe hacer.

Luego agregue pruebas de integración para que tenga una buena cobertura de integración. (El comentario de BobDalgleish es una buena manera de pensar acerca de la cobertura de integración). Generalmente, encuentro que la cobertura de integración perdida me ayuda a encontrar pruebas de aceptación faltantes.

Luego agregue pruebas unitarias para especificar detalles de comportamiento y corrección técnica. No tendrá que probar un poco el código, ya que las pruebas de aceptación / integración ya lo probarán. Pensará en cosas para probar en otro código, e incluso puede volver a probar las rutas a través de ese código que ya se probaron en las pruebas de aceptación / integración para que las pruebas de unidad tengan sentido sin leer las pruebas de integración.

    
respondido por el Dave Schweisguth 09.05.2014 - 05:09
0

Tiendo a pensar que deberías comenzar desde abajo y continuar, en términos de pruebas. Pruebas unitarias primero: las piezas más pequeñas, más granulares. Sin ellos, el resto de las pruebas no tienen mucha base en ellas.

Las pruebas de integración vendrían después. Manejaría las pruebas de integración antes de UI / UAT. Se pueden escribir casi igual que las pruebas unitarias, pero se pueden clasificar de manera diferente (de tal manera que la prueba que se ejecuta pueda realizar pruebas unitarias de retroalimentación rápida sin pruebas de integración, o viceversa, o ambas juntas).

Normalmente, las pruebas unitarias serían rápidas y se ejecutarán cada vez que se registra un compromiso. Las pruebas de integración serían un tipo de prelanzamiento. UI / UAT es la última.

Para elegir su ejemplo específico de "fecha de inicio no debe ser posterior a la fecha de finalización", creo que definitivamente debería ser una prueba de unidad. No requiere ningún otro componente de integración para probarlo. Sin embargo, "asegúrese de que la entrada escriba en la base de datos", por ejemplo, sería una prueba de integración.

Creo que, de forma predeterminada, las capas de dominio / lógica de negocios de un proyecto obtienen mucha más cobertura de prueba unitaria que, por ejemplo, una capa MVC. Las pruebas de unidad más importantes se realizan contra el inicio de sesión empresarial, IMO. La prueba de integración es realmente donde se conecta la capa MVC y, por ejemplo, la capa de dominio / BL y la capa de acceso a datos para asegurarse de que todo funciona correctamente.

Como tal, es importante que la arquitectura básica del sistema sea correcta. El objeto de negocio debe validar, por ejemplo, que la Fecha de inicio no sea posterior a la Fecha de finalización. Esto se vuelve muy natural para las pruebas unitarias, dado que las pruebas unitarias realmente tienden a golpear con fuerza la capa de dominio, pero no tanto en la capa MVC. (por supuesto, la capa MVC podría / debería verificar esto antes de que realmente llegue al dominio, pero eso es una amabilidad, no una necesidad).

Entonces, con todo lo dicho, normalmente haré algo como lo siguiente:

Project.Domain
Project.Domain.Tests.Unit
Project.WebApp
Project.WebApp.Tests.Unit
Project.WebApp.Tests.Integration

Las pruebas de integración se manejan de manera muy similar, pero se les asigna una clasificación que los corredores de prueba pueden usar para ejecutar solo la unidad, o la unidad y la integración, etc.

Es posible que algunas cosas en el proyecto de aplicación web aún quieran ser probadas en la unidad: controladores para asegurarse de que están recuperando JSON correctamente, etc., pero en general, la prueba de la unidad tiende a obtener el mayor beneficio en el nivel de dominio, y, respectivamente, la integración a la presentación / capas de datos.

Y una vez que todo esté en su lugar, ¡terminar con todas las pruebas de UAT / UI también es bueno!

    
respondido por el jleach 08.03.2017 - 16:30

Lea otras preguntas en las etiquetas