¿Qué es exactamente una prueba de integración?

Mis amigos y yo hemos estado luchando por clasificar exactamente qué es una prueba de integración.

Ahora, de camino a casa, me di cuenta de que cada vez que trato de dar un ejemplo del mundo real de una prueba de integración, resulta ser una prueba de aceptación, es decir. algo que una persona de negocios diría en voz alta que especifica qué debe entregar el sistema.

Revisé la documentación de Ruby on Rails para su clasificación de estos tipos de prueba, y ahora me ha arrojado por completo.

¿Me puede dar una breve descripción académica de una prueba de integración con un ejemplo del mundo real?

Por el momento me gusta esta declaración: "No es importante cómo lo llames, sino lo que hace" hecho por Gojko Adzic en este artículo .

Realmente necesita especificar con las personas que hablan sobre las pruebas lo que pretende probar.

Hay muchas personas que tienen diferentes puntos de vista, dependiendo de cuál sea su rol.

Para los evaluadores, una metodología de prueba generalmente aceptada en los Países Bajos es TMap . TMap hace la siguiente distinción.

• prueba de unidad
• prueba de integración de la unidad
• prueba del sistema
• prueba de integración del sistema
• prueba de aceptación (todo tipo / nivel)
• prueba de aceptación funcional
• prueba de aceptación del usuario
• prueba de aceptación de producción

Tienen un tipo más específico de pruebas que se pueden realizar dentro de las pruebas mencionadas anteriormente. Mire esta palabra doc para una descripción general.

Wikipedia también tiene una buena visión general .

El libro que el programador pragmático dice:

• una prueba unitaria es una prueba que ejercita un módulo
• Las pruebas de integración muestran que las partes principales de un sistema funcionan bien juntas

Mirando estas diferentes fuentes y poniendo algunas de mis propias experiencias y opiniones, comenzaría haciendo distinciones por tres categorías

• quien hace las pruebas en general
• lo que se prueba

• cual es el objetivo de la prueba

  • Prueba unitaria : prueba la lógica en clases por programadores para mostrar la corrección del nivel de código. Deben ser rápidos y no depender de otras partes del sistema que no pretendas probar
  • Prueba de aceptación funcional : pruebe los escenarios de casos de uso en un conjunto de datos limitado (especialmente creado) realizado por el departamento de pruebas para mostrar que cada escenario especificado funciona como se especifica.
  • Prueba de aceptación del usuario : pruebe escenarios de casos de uso en producción como datos hechos por representantes de los usuarios para que acepten formalmente la aplicación
  • Prueba de integración : pruebe las rutas de comunicación entre las diferentes partes del módulo realizadas por el departamento de prueba o por los desarrolladores para mostrar que todos los módulos funcionan correctamente juntos.

Mi lista anterior es solo un comienzo y una sugerencia, pero realmente pienso: "No es importante cómo lo llames, sino lo que hace"

Espero que esto ayude.

26-10-2016 Editar: Recientemente, se introdujo una muy buena introducción en las pruebas de unidad de YouTube frente a las pruebas de integración - Reflexiones de MPJ - FunFunFunction # 55

prueba de integración, resulta ser una prueba de aceptación

Obviamente.

Estos dos son casi lo mismo. Pero hay algunas dimensiones ligeramente diferentes a la definición de la prueba.

Integración == el sistema en su conjunto.

Aceptación == el sistema en su conjunto.

La única diferencia, y esto es sutil, es la definición de los casos de prueba.

Integración == casos de prueba para probar la profundidad y el grado de integración. ¿Funciona para todos los casos de borde y casos de esquina? Los casos de prueba tienden a ser técnicos, escritos por diseñadores y codificadores.

Aceptación == casos de prueba para ejercitar solo el 80% del conjunto de características centrado en el usuario final. No todos los casos de borde y esquina. Los casos de prueba tienden a ser no técnicos, escritos por usuarios finales.

Personalmente, me gusta pensar en una prueba de integración como una prueba de características cuando cada componente del sistema es real , sin objetos simulados.

Un repositorio real, una base de datos real, una interfaz de usuario real. Usted prueba la funcionalidad específica cuando el sistema está completamente ensamblado y es como se supone que debe ser cuando se implementa.

En mi poca experiencia (lo admito), entendí que la palabra integración realmente puede crear malentendidos: realmente, es difícil encontrar algo completamente aislado en un sistema, algunos elementos necesitarán cierta integración con seguridad.

Por lo tanto, me acostumbré a hacer las siguientes distinciones:

• Utilizo pruebas unitarias para identificar, documentar y enfatizar todos los comportamientos que la clase que estoy probando es responsable de realizar.
• Estoy haciendo pruebas de integración cada vez que tengo un componente (tal vez más de uno) en mi sistema que está teniendo una conversación con otro sistema " externo ". (continúa abajo ...)
• Implemento una prueba de aceptación para definir, documentar y enfatizar un cierto flujo de trabajo que el sistema espera.

En la definición de la prueba de integración, por externo me refería a un sistema que está fuera de mi rango de desarrollo : no puedo cambiar inmediatamente su forma de comportamiento, por ningún motivo. Podría ser una biblioteca, un componente del sistema que no se puede cambiar (es decir, se comparte con otros proyectos de la empresa), un dbms, etc. Para estas pruebas necesito configurar algo muy similar al entorno real del sistema funcionará en: un sistema externo debe inicializarse y establecerse en un cierto estado; los datos realistas deben registrarse en la base de datos; etc.

En cambio, cuando estoy haciendo pruebas de aceptación, finjo cosas: estoy trabajando en algo diferente, estoy trabajando en las especificaciones del sistema, no en su capacidad de colaborar con entidades externas.

Esta es realmente una visión más limitada en comparación con lo que KeesDijk describió anteriormente, sin embargo, supongo que los proyectos en los que trabajé hasta ahora eran lo suficientemente pequeños como para permitirme este nivel de simplificación.

Una prueba de integración verifica que los componentes de un sistema complejo (p. Ej., Software, aeronave, planta de energía) están trabajando juntos como se diseñó.

Imaginemos que estamos hablando de un avión (con el software es más abstracto y difícil hacer la diferencia). Las pruebas de integración incluyen, verificando:

• Correcta interacción entre algunos componentes. Ejemplo: al presionar el botón de arranque, el motor arranca y la hélice alcanza la velocidad de rotación esperada (la aeronave aún permanece en tierra)
• correcta interacción con componentes externos. Ejemplo: compruebe que la radio integrada puede comunicarse con una radio estacionaria (el avión aún está en tierra)
• interacción correcta entre todos los componentes involucrados, para que el sistema en su conjunto funcione como se espera. Ejemplo: una tripulación de pilotos e ingenieros de prueba inicia el avión y vuela con él (todos usan paracaídas ...).

La prueba de integración aborda un problema técnico , a saber, que el sistema funciona a pesar de su subdivisión en componentes. En software los componentes pueden ser casos de uso, módulos, funciones, interfaces, bibliotecas, etc.

La prueba de aceptación verifica que el producto es apto para su propósito. En principio son realizados por el cliente. Tomando la analogía del avión, incluyen verificar que:

• Los escenarios empresariales previstos conducen al resultado esperado en una situación casi real. Ejemplo: ensayar un abordaje con pasajeros de prueba para verificar que el personal pueda monitorear el abordaje como se esperaba con los procedimientos operativos. Algunos escenarios podrían ser tan simples que se verían como pruebas unitarias, pero los realiza el usuario (por ejemplo, pruebe los enchufes eléctricos con el equipo de las empresas).
• El sistema funciona en una situación comercial casi real. Ejemplo: haga un vuelo de prueba vacío entre dos destinos reales, con pilotos recién entrenados de la aerolínea para verificar que el consumo de combustible sea el prometido.

La prueba de aceptación aborda más un problema de responsabilidad . En una relación cliente / proveedor puede ser una responsabilidad contractual (cumplimiento de todos los requisitos). Pero, en cualquier caso, también es responsabilidad de la organización usuaria garantizar que sus tareas puedan llevarse a cabo con el sistema y prevenir con prudencia cualquier problema imprevisto (por ejemplo, como esta corporación ferroviaria que descubrió durante las pruebas de aceptación que tenían que acortar algunos quais porque los nuevos vagones eran 5 cm demasiado grandes, ¡no es broma!).

Conclusiones: las pruebas de integración y aceptación se superponen. Ambos tienen la intención de mostrar que el sistema en su conjunto funciona. Sin embargo, el "todo" podría ser más grande para el cliente (porque el sistema puede ser parte de un sistema organizacional más grande), y más técnico para el integrador del sistema:

Las pruebas de integración no son más que verificar la conexión y la corrección del flujo de datos entre dos o más módulos.

Por ejemplo: cuando redactamos un correo (un módulo) y lo enviamos a una identificación de usuario válida (segundo módulo), la prueba de integración consiste en verificar si el correo enviado está en los elementos enviados.

Una definición práctica de una prueba de integración es: cualquier prueba que requiera interacción con algo fuera de proceso.

Por ejemplo:

• El sistema de archivos
• La red
• Una base de datos
• Una API externa

Existe un tipo de contrato entre su proceso y el mundo externo, y la verificación mínima de ese contrato debe ser el objetivo de una prueba de integración. es decir, no debe hacer más que verificar el contrato. Si lo hace, entonces se está moviendo hacia el sistema / espacio de extremo a extremo.

Las pruebas unitarias pueden probar toda la lógica dentro de los límites de su proceso, y pueden hacerlo fácilmente precisamente debido a la falta de dependencias en el "mundo externo" lento / frágil / complejo.

Si bien hay pruebas de integración que esta definición no cubre (de ahí por qué la llamé una definición práctica ), creo que son mucho menos comunes / útiles.

Nota: en sentido estricto, sí, esta definición también abarcaría las pruebas de sistema / de extremo a extremo. En mi filosofía, son una forma de prueba de integración "extrema", de ahí que sus nombres enfaticen otro aspecto. En la otra dirección, una prueba unitaria puede considerarse una prueba de integración de cero componentes, es decir, todas las pruebas pueden considerarse en algún lugar del espectro de integración, integrando entre 0-n componentes :-)