X
BLOG

Prueba unitaria de código C / C ++: cuándo simular

Prueba unitaria de código C / C ++: cuándo simular Tiempo de leer: 6 minutos
La prueba unitaria consiste en probar las unidades aisladas. En esta publicación, analizamos 7 veces para simular, incluidas algunas preguntas útiles para que pueda guiarse a través de las pruebas unitarias de C y C ++.

¿Cuánto aislamiento de prueba unitaria necesitamos? Esta es una pregunta recurrente e importante que se debate comúnmente al desarrollar pruebas unitarias para C y C ++. Y no me refiero aquí al aislamiento del compañero desarrollador, sentado a nuestro lado en el espacio abierto y tocando el ritmo de la música desde sus auriculares (que, por cierto, también es muy importante cuando queremos crear buenos código de calidad). Me refiero al aislamiento del código probado de su entorno circundante: sus llamados colaboradores.

Antes de continuar, permítanme aclarar una cosa: cuando se habla de stubbing y burlarse de los lenguajes C y C ++, por lo general hay una línea entre C y C ++ debido a las diferencias en la capa del lenguaje que se reflejan en la complejidad, las capacidades y las expectativas. con respecto a los típicos marcos de burla. Con Parasoft C / C ++test, la situación es ligeramente diferente porque la mayoría de las capacidades del marco están disponibles para ambos idiomas. Por lo tanto, al discutir este tema, daré un ejemplo de prueba unitaria de C o C ++ y, a menos que marque algo específicamente como compatible solo para C o C ++, siempre debe asumir que se proporciona una funcionalidad específica para ambos lenguajes.

Obtenga todo lo que necesita para crear, ejecutar y mantener pruebas unitarias. Vea la prueba de Parasoft C / C ++ en acción.
Solicita Una Demo

¿Aislar o no aislar?

Por un lado, el sentido común dicta que no debemos aislarnos a menos que tengamos una buena razón para ello. Al final, probar a los colaboradores reales solo aumenta nuestra penetración de la base del código. ¿Por qué deberíamos renunciar a una cobertura de código adicional y la posibilidad de encontrar un error? Bueno, parece que hay buenas razones para ello; lo discutiremos pronto.

Por otro lado, un probador de unidades ortodoxo argumentará que la prueba de unidades consiste en probar las unidades aisladas y debería permanecer como es. La prueba con colaboradores reales es el dominio de la fase de integración. Es un hecho bien conocido que al incluir a los colaboradores reales en el alcance de la prueba, hacemos que nuestras pruebas sean más ruidosas. Las pruebas que se basan en colaboradores reales reaccionarán no solo a los cambios en el código probado, sino también a los cambios en los componentes dependientes. Las pruebas más ruidosas encarecen el proceso de mantenimiento y generan mucha distracción. A largo plazo, esta distracción suele convertirse en la razón principal para abandonar la práctica de las pruebas unitarias.

Entonces, ¿cuál es la estrategia para aislar el código probado? Dado lo anterior, es difícil formular una buena regla para determinar qué colaboradores deben ser burlados para proporcionar un aislamiento adecuado del código probado. Desde la perspectiva de la eficiencia y la eficacia de las pruebas, los enfoques de “aislar todo lo que pueda” y “evitar el aislamiento de la prueba unitaria si es posible” tienen ventajas y desventajas.

3 razones sencillas para burlarse

Aquí hay algunas situaciones más obvias:

1. Colaborador aún no implementado o aún en desarrollo

Esto es muy simple. No tenemos otra opción y necesitamos una implementación simulada. El diagrama a continuación ilustra este entorno típico de prueba unitaria (SUT - sistema bajo prueba, DOC - componente / colaborador dependiente):

2. Independencia del hardware

Para los desarrolladores que escriben aplicaciones de escritorio, esta clase de problemas puede parecer distante, pero para los desarrolladores integrados, la independencia del hardware de las pruebas unitarias es un aspecto importante que permite un alto nivel de automatización y ejecución de pruebas sin necesidad de hardware. Un buen ejemplo aquí sería una unidad bajo prueba que interactúa con hardware GPS, esperando que se proporcione una cierta secuencia de coordenadas de localización para calcular la velocidad. Aunque es una buena idea que hagamos más ejercicio, no puedo imaginar a los probadores corriendo con un dispositivo para simular el movimiento, solo para generar las entradas de prueba requeridas, en cualquier momento que se requiera una sesión de prueba unitaria. Con ese fin, este ejemplo ilustra cuán tarde en el ciclo de vida de desarrollo sería la prueba de GPS de un dispositivo si la independencia del hardware no fuera posible durante el desarrollo.

3. Inyección de fallas

Inyectar errores a propósito es un escenario común en las pruebas. Esto podría usarse, por ejemplo, para probar que la asignación de memoria ha fallado o para ver si un componente de hardware ha fallado. Algunos desarrolladores intentan estimular al colaborador real en la fase de inicialización de la prueba, para que responda con un error cuando sea llamado desde el código probado. Para mí, esto no es práctico y suele ser demasiado complicado. Una implementación falsa, específica de la prueba, que simula una falla, suele ser una opción mucho mejor.

4 razones menos sencillas para burlarse

Además de estos casos obvios en los que siempre se desea un colaborador burlado, existen otras situaciones más sutiles en las que los colaboradores falsos son una buena opción. Si nuestro proceso de prueba sufre alguno de los problemas que se enumeran a continuación, es una indicación de que se requiere un mejor aislamiento del código probado.

1. Las pruebas unitarias no son repetibles

Es difícil implementar pruebas estables que dependan de una dependencia volátil. Lo que generalmente sucede en tales casos es que recibimos diferentes resultados de prueba sin cambiar el código probado o el código de las pruebas. La fugacidad puede ser un efecto de depender de las llamadas del sistema o depender de una señal externa que no se puede controlar desde el interior de la prueba. Un ejemplo clásico es el reloj del sistema: si un escenario de prueba requiere reaccionar en ciertos puntos en el tiempo, entonces la automatización es difícil de lograr sin colaboradores burlados que tengan control total sobre las entradas indirectas al código probado.

2. Los entornos de prueba son difíciles de inicializar

Inicializar el entorno de prueba puede resultar muy complejo. Simular a los colaboradores reales para que proporcionen entradas confiables al código probado puede ser una tarea desalentadora, si no imposible.

Los componentes a menudo están interrelacionados, y cuando intentamos inicializar un módulo específico, podemos terminar inicializando la mitad del sistema. Reemplazar a los colaboradores reales con una implementación falsa reduce la complejidad de la inicialización del entorno de prueba.

3. El estado de la prueba es difícil de determinar

En muchos casos, la determinación del veredicto de la prueba requiere verificar el estado del colaborador después de que se ejecuta la prueba. Con colaboradores reales, a menudo es imposible porque no existe un método de acceso adecuado en la interfaz de colaborador real para consultar el estado después de la prueba.

Reemplazar a un colaborador real con un simulacro generalmente soluciona el problema, y ​​podemos extender la implementación falsa con todo tipo de métodos de acceso para determinar el resultado de la prueba.

4. Las pruebas son lentas

Hay casos en los que una respuesta del colaborador real puede llevar una cantidad considerable de tiempo. No siempre está claro cuándo el retraso se vuelve inaceptable y cuándo se requiere aislamiento. ¿Es aceptable o no un retraso de 2 minutos en una ejecución de prueba? A menudo es deseable poder ejecutar conjuntos de pruebas lo más rápido posible, quizás después de cada cambio de código. Los grandes retrasos debidos a interacciones con colaboradores reales pueden hacer que los conjuntos de pruebas sean demasiado lentos para ser prácticos. Las simulaciones de estos colaboradores reales pueden ser más rápidas en varios órdenes de magnitud y llevar el tiempo de ejecución de las pruebas a un nivel aceptable.

Preguntas útiles para determinar si burlarse o no

Por lo tanto, cuando escriba una nueva prueba unitaria de C o C ++ y decida utilizar colaboradores originales o implementaciones simuladas, considere las siguientes cuatro preguntas:

  1. ¿El colaborador real es una fuente de riesgo para la estabilidad de mis pruebas?
  2. ¿Es difícil inicializar al colaborador real?
  3. ¿Es posible verificar el estado del colaborador después de la prueba, para decidir el estado de la prueba?
  4. ¿Cuánto tiempo tardará el colaborador en responder?

Si conocemos al colaborador lo suficientemente bien como para responder a todas estas preguntas, entonces es una decisión fácil de una forma u otra. Si no es así, sugiero comenzar con el colaborador real y tratar de responder estas cuatro preguntas sobre la marcha. En la práctica, este es el enfoque que la mayoría de los profesionales del desarrollo impulsado por pruebas (TDD) aplican en su trabajo diario. Significa que debe cuidar sus casos de prueba y revisarlos cuidadosamente hasta que se estabilicen.

Muy a menudo, el aislamiento de la prueba unitaria se complica por las dependencias de la unidad bajo prueba. Hay casos claramente deseables en los que se necesita burlarse de un componente dependiente, pero también situaciones más sutiles. En algunos casos, no está claro y depende del riesgo y la incertidumbre que tiene una dependencia en el entorno de prueba.

Obtenga todo lo que necesita para crear, ejecutar y mantener pruebas unitarias. Vea la prueba de Parasoft C / C ++ en acción.
Solicita Una Demo
Escrito por

Miroslaw Zielinski

Gerente de producto para las soluciones de prueba integradas de Parasoft, las especialidades de Miroslaw incluyen C / C ++, RTOS, análisis de código estático, pruebas unitarias, gestión de la calidad del software para aplicaciones críticas de seguridad y cumplimiento del software con los estándares de seguridad.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft