Algunas cosas en la industria del software nunca pasan de moda. A pesar de que el desarrollo y las pruebas de software han cambiado a lo largo de los años, una técnica de prueba sigue en boga: las pruebas de integración. Han sobrevivido al declive de la metodología en cascada, la popularidad de la metodología ágil y hasta el actual flujo de trabajo de desarrollo impulsado por DevOps.
Pero debido al panorama en constante cambio de las pruebas de software, las pruebas de integración a menudo se confunden con otros tipos de pruebas, como las pruebas unitarias y de Extremo-a-Extremo (E2E: End-to-End).
«Es algo común difuminar las líneas entre las diferentes formas de pruebas, pero todas tienen propósitos diferentes e importantes, pero mutuamente excluyentes», dijo Aaron Schneider, arquitecto senior de soluciones en Qualitest, una consultora de pruebas de software.
¿Qué son las pruebas de integración?
Las pruebas de integración tratan de evaluar las interacciones entre las secciones de código y asegurarse de que los datos se pasen en formatos que cada lado pueda entender.
Si bien las pruebas unitarias aseguran la lógica esencial dentro de secciones individuales de código y mientras que las pruebas E2E son de alto nivel, las pruebas de integración residen en el medio y comparten algunas cualidades de cada una.
💡Quizás te interesen estos artículos:
- ¿Por qué la cobertura de pruebas unitarias es una parte importante de QA?
- ¿Por qué la ejecución aleatoria es una oportunidad para mejorar las Pruebas Unitarias?
Al igual que las pruebas unitarias, las pruebas de integración están escritas principalmente por desarrolladores y pueden automatizarse, pero prueban características completamente diferentes.Las pruebas de integración tratan de observar cómo las secciones de código se comportan juntas. A su vez son distintas de las pruebas E2E porque están automatizadas y deben escribirse y ejecutarse poco después de que el código esté disponible para la prueba, incluso puede ser un objetivo que se ejecuten automáticamente cuando se realiza entrega de nuevo código.
Algunos proyectos necesitan más pruebas de integración que otros
Es difícil encontrar proyectos de software que no necesiten algún tipo de prueba de integración.Esto se debe a que cada vez que un sistema interactúa con otro sistema, ya sea interno del proyecto como un microservicio o con un colaborador externo de software o hardware, puede tener problemas de integración.
Las pruebas bien seleccionadas también pueden ayudar a orientar a los nuevos desarrolladores y ayudarles a entender el código base cuando hay rotación de personal. Y contar con las pruebas adecuadas ayuda a los desarrolladores a sentirse seguros al escribir más código, sin temer que el código existente se vuelva inestable.
Pero las empresas generalmente están limitadas por el dinero y el tiempo de los empleados, por lo que deben ser al menos algo exigentes con respecto a qué tipo de pruebas escribir y qué áreas del código reciben cobertura de prueba. Hay muchas estrategias para determinar que cubrir con las pruebas de integración, pero dos que se resaltan en el artículo original son:
- Ver en que punto los desarrolladores se sienten menos confiandos en intervenir.
- Ver que partes de la aplicación reciben mayor solicitud de soporte técnico o de atención al cliente.
💡Quizás te interese leer el artículo: Estrategia de automatización de pruebas: qué debemos automatizar
De la pirámide al trofeo de pruebas
Existe un debate en el campo de las pruebas de software sobre si la pirámide de pruebas tradicional debería cambiarse. En un marco de trofeo de pruebas, las pruebas unitarias ya no son las más importantes y numerosas. En cambio, las pruebas de integración forman la mayor parte de las pruebas de un proyecto porque cada vez se considera que tienen lo mejor de ambos mundos. Al igual que las pruebas E2E, cada prueba de integración puede cubrir una gran cantidad de código y, con la ayuda de más herramientas, las pruebas de integración también son fáciles de escribir y automatizar, al igual que las pruebas unitarias.
💡 En este artículo puedes ver, como parte de las pruebas estáticas de código: Las cinco métricas de código para mejorar la calidad del software
Hubo un tiempo en el cual, para realizar las pruebas de integración, era necesario crear datos específicos en los elementos a integrar como la base de datos o servicios externos e incluso sincronizar la data entre ellos, o sea, que el dato de prueba se encuentre en tres servicios para que la prueba resulte exitosa. Afortunadamente, han aparecido muchas herramientas, entre ellas los dobles de pruebas (o mocks), que ayudan a los desarrolladores a escribir mejores pruebas de integración y en mayor cantidad.
Conclusiones
A medida que las empresas adopten patrones de desarrollo más centrados en los microservicios y el uso de contenedores, las pruebas de integración solo se volverán más importantes para asegurarse de que las partes altamente segmentadas del código base puedan funcionar juntas correctamente.
Las pruebas de integración adecuadas también son importantes entre ciertos productos. Apple por ejemplo apuesta por hacer de la buena integración una prioridad para que cada aplicación pueda funcionar con todos sus dispositivos creando un ecosistema que aporta valor a la vida de sus consumidores.
En cada etapa de desarrollo, en cada producto, hay interacciones e integraciones de una forma u otra, ya sea internamente con su propio software, entre software y hardware, o entre diferentes dispositivos en el mundo real, la integración es increíblemente importante y de allí la necesidad de asegurarse que funcione correctamente.
Fuentes
Basado en:
- Want to Have Confidence In Your Code? Embrace Integration Testing por Tammy Xu.
- Write tests. Not too many. Mostly integration por Kent C. Dodds.
- Static vs Unit vs Integration vs E2E Testing for Frontend Apps por Kent C. Dodds.
Foto por Leonardo Ramos en Unsplash.
Genial. LA verdad no conocía sobre esta discusión.