Pruebas de Integración
Desarrolladores en sus marcas, listos, ¡fuera!
Actualmente hay una crisis con BMW en Corea. El país ha registrado uno de sus veranos más calurosos. Todas las ciudades coreanas registraron más de 40 grados Celsius. Este verano Corea registró un punto más cálido que el Desierto del Sahara y los vehículos de BMW comenzaron a incendiarse.
Usted puede ver, Corea tiene una de las más estrictas regulaciones de emisiones de carbono para los automóviles diesel en el mundo, en parte para proteger a sus fabricantes de automóviles y también debido a la creciente preocupación de la población sobre la contaminación del aire creada en parte por este tipo de motores. Eso de alguna manera hizo que los dispositivos de recirculación de gases de escape (EGR) fueran una escasez para BMW, ya que había muy pocos tipos de dispositivos de EGR que cumplieran con la regulación coreana. Lo mismo se aplica a Hyundai y Kia. Estos fabricantes de automóviles coreanos utilizan los mismos dispositivos EGR. Estos dispositivos EGR fueron señalados por BMW como la causa del sobrecalentamiento y comenzaron a reemplazarlos.
Entonces, ¿los automóviles de Kia y Hyundai también se incendiaron? No. Entonces, ¿BMW fabrica autos diésel peores que Hyundai y Kia? No. Entonces, ¿qué está pasando y por qué solo los autos diésel de BMW se están incendiando?
La falta de prueba de integración, supongo.
Recientemente hemos descubierto la importancia de la prueba unitaria. La idea es que las características se dividan en la unidad más pequeña y se ejecuten pruebas automáticas en cada característica específica del desarrollo de software. Esta es una idea que los desarrolladores de software tomaron del proceso de fabricación, donde para hacer un automóvil hay que probarlo y las pruebas se realizan en la unidad de la característica. El parabrisas se prueba por su característica y el pomo de la puerta se prueba en función de su característica específicamente definida. Esto, sin embargo, no completa el proceso de prueba. Es importante ver todos estos diferentes componentes trabajando juntos. Esa es la prueba de integración.
Los dispositivos EGR funcionan bien por sí solos como una unidad. Sin embargo, se desconoce al fabricante de los dispositivos EGR y dónde y con qué condición se instalarán exactamente estos dispositivos EGR. Usted como fabricante de automóviles tendría que pensar en su ventilación y la carga de trabajo que se le pone en comparación con el calor que genera dentro del automóvil completado. Entonces, una vez que todo está ensamblado, se debe ejecutar la prueba de integración, para ver si todos los componentes funcionan en armonía. Cuanto más complicado se vuelve el producto, más componentes requiere y la prueba de integración se vuelve más sofisticada.
¿Has visto cómo Boeing ensambla sus aviones? Tiene cientos de miles, si no son millones de partes para hacer un solo jumbo jet. Cada parte es rigurosamente probada por su proveedor (prueba de unidad) pero una vez que llegan y se ensamblan en una fábrica de Boeing se prueban para ver si todos funcionan bien, juntos. El fabricante de la consola del piloto desconoce el estado de las aletas. Es el trabajo de los ingenieros de Boeing asegurarse de que funcionen bien juntos.
Del mismo modo que tomamos prestada la idea de las pruebas unitarias de los fabricantes, la prueba de integración es otra lección importante para todos los desarrolladores de software. Digamos que creamos una página de inicio de sesión. El diseñador solo piensa en la intuición de la interfaz de usuario. El programador de UI solo piensa en el nombre de usuario y la contraseña que se transfieren al servidor de inicio de sesión de forma segura y sencilla. El programador del servidor de inicio de sesión solo piensa en la exactitud de su proceso de autenticación. Son pruebas unitarias. La prueba de integración sería probar si se puede iniciar sesión de forma intuitiva, segura y correcta utilizando la interfaz de usuario.
El caso más común de prueba de integración en desarrollo de software es ver si la capa lógica funciona correctamente con la base de datos. La base de datos viene con sus propias pruebas unitarias y nuestra capa lógica tiene sus propias pruebas unitarias, pero el diablo está en el detalle. En el nivel más básico de la prueba de integración con la base de datos, la integración de datos puede tener diferentes configuraciones de codificación al de la capa lógica, idioma o huso horario por ejemplo. Luego, los programadores tienen que avanzar para ver si la cantidad de resultados devueltos por la base de datos es procesable por la capa lógica dentro de su propia memoria y restricciones de potencia de procesamiento.
La próxima vez que vea un programa que tenga todos los botones de trabajo y cuadros de entrada pero que no funcionen como un todo, sepa que los programadores se olvidaron de hacer una prueba de integración.
