java - tecnicas - Exactamente qué es la prueba de integración, en comparación con la unidad
tecnicas de pruebas de software (5)
Estoy empezando a usar las pruebas unitarias en mis proyectos, y estoy escribiendo pruebas que se están realizando a nivel de método / función.
Entiendo esto y tiene sentido.
Pero, ¿qué es la prueba de integración? Por lo que leí, se mueve el alcance de las pruebas para probar características más grandes de una aplicación.
Esto implica que escribo un nuevo conjunto de pruebas para probar cosas más grandes como (en un sitio de comercio electrónico) la funcionalidad de pago, la funcionalidad de inicio de sesión del usuario, la funcionalidad de la cesta. ¿Así que aquí tendría 3 pruebas de integración escritas?
¿Es correcto? Si no, alguien puede explicar lo que significa.
Además, la prueba de integración involucra a la interfaz de usuario (contexto de aplicación web aquí) y emplearía los gustos de selenio para automatizar. O bien, las pruebas de integración aún se encuentran en el nivel del código, pero unen clases de diferencias y áreas del código.
Aquí hay un par de restricciones que satisface una buena prueba de unidad. Cumplir con estas restricciones también requería un buen código comprobable.
- Sin E / S - disco o red
- Solo una aserción (si es múltiple, deben ser variaciones menores entre sí)
- No ejerce (cubre) mucho más código de producción de lo que afirma
Estas restricciones generalmente no se aplican a las pruebas de integración.
La prueba de unidad es donde está probando su lógica de negocios dentro de una clase o un fragmento de código. Por ejemplo, si está probando que una sección particular de su método debe llamar a un repositorio, su prueba de unidad comprobará que el método de la interfaz que llama al repositorio se llame la cantidad correcta de veces que espera, de lo contrario, falla la prueba.
Por otro lado, las pruebas de integración están probando que el comportamiento real del servicio o repositorio (base de datos) es correcto. Es verificar que, en función de los datos que usted ingrese, recupere los resultados esperados. Esto se vincula con las pruebas unitarias para que sepa qué datos debe recuperar y qué hace con esos datos.
Las pruebas unitarias son pruebas de que el código probado está dentro de la clase real. Otras dependencias de esta clase se burlan o se ignoran, porque el enfoque es probar el código dentro de la clase.
Las pruebas de integración son pruebas que involucran acceso a disco, servicio de aplicaciones y / o marcos de la aplicación de destino . Las pruebas de integración se ejecutan aisladas de otros servicios externos.
Daré un ejemplo. Tiene una aplicación Spring y realizó muchas pruebas unitarias para garantizar que la lógica de negocios funciona correctamente. Perfecto. Pero qué tipo de pruebas tienes para garantizar:
- Su servicio de aplicación puede comenzar
- Su entidad de base de datos está asignada correctamente
- Tienes todas las anotaciones necesarias funcionando como se espera.
- Su filtro funciona correctamente
- Tu API está aceptando algún tipo de datos
- Tu característica principal está realmente trabajando en el escenario básico.
- Su consulta de base de datos está funcionando como se esperaba
- Etc ...
Esto no se puede hacer con pruebas unitarias, pero usted, como desarrollador, debe garantizar que todo funcione también. Este es el objetivo de las pruebas de integración.
El escenario ideal son las pruebas de integración que se ejecutan independientemente de otros sistemas externos que la aplicación utiliza en un entorno de producción. Puede lograr eso utilizando las llamadas de Wiremock for Rest, una base de datos de memoria como H2, frijoles burlones de algunas clases específicas que llaman sistemas externos, etc.
Un poco de curiosidad: Maven tiene un complemento específico para Pruebas de integración: el maven failsafe plugin Maven que ejecutó las clases de prueba que el nombre termina con TI . Ejemplo: UserIT.java.
La confusión sobre lo que significa la prueba de integración
Algunas personas entienden la "prueba de integración" como una prueba que implica la "integración" a otros sistemas externos que utiliza el sistema actual. Este tipo de pruebas solo se pueden realizar en un entorno en el que tenga todos los sistemas en funcionamiento para atenderlo. Nada falso, nada burlado.
Esto podría ser solo un problema de denominación, pero tenemos una falta de pruebas (lo que entiendo como pruebas de integración) que atienden la necesidad de los elementos descritos anteriormente. Por el contrario, estamos saltando para una definición de pruebas unitarias (solo clase de prueba) a una prueba de integración (todo el sistema real arriba). ¿Qué hay en medio de esto si no las pruebas de integración?
Puedes leer más sobre esta confusión en este artículo de Martin Fowler.
Por lo que veo, las pruebas de selenio deberían estar en otra serie de pruebas. Esas pruebas son las pruebas más frágiles en la naturaleza, incluso si las escribe correctamente. Aquí puede utilizar Specflow o algún otro tipo de especificación mediante el marco de ejemplo. Quizás puedas llamar a estas pruebas como pruebas de aceptación. Estos son para desarrolladores y expertos en negocios también. La integración, o las pruebas de módulo normalmente no utilizan la interfaz de usuario. Las pruebas de integración ejercitan algunas clases que están trabajando juntas. Estas son pruebas de nivel inferior a las pruebas de selenio y un poco más fáciles de mantener. Estas pruebas son solo para desarrolladores.
Considere un método como este PerformPayment(double amount, PaymentService service) ;
Una prueba de unidad sería una prueba en la que se crea un simulacro para el argumento de service .
Una prueba de integración sería una prueba en la que utiliza un servicio externo real para que pruebe si ese servicio responde correctamente a sus datos de entrada.