¿Qué son las pruebas de módulos? Definición, ejemplos

⚡ Resumen inteligente

Las pruebas de módulos comprueban subprogramas, subrutinas, clases y procedimientos individuales, en lugar del programa ensamblado, por lo que los defectos afloran dentro de un pequeño bloque de código bien comprendido, donde resultan económicos de localizar y reparar.

🎯 Objetivo: El objetivo es exponer los errores de un módulo, no demostrar que el módulo funciona.
⚪ Orientación: La técnica empleada se basa principalmente en el modelo de caja blanca, complementado con casos de caja negra extraídos de la especificación.
⏩ Paralelismo: Se pueden probar varios módulos al mismo tiempo, lo que acorta el tiempo total de prueba.
🔗 Dos métodos: Los módulos se combinan de forma incremental, paso a paso, o de forma no incremental en una sola pasada.
🧰 Andamio: Los controladores proporcionan datos de prueba a un módulo, mientras que los módulos ficticios (stubs) hacen las veces de módulos a los que estos llaman.
🆚 Propiedad: Los probadores escriben las pruebas de módulo después de codificar, mientras que los desarrolladores escriben las pruebas unitarias durante el proceso.
⚠️ Desafíos: El trabajo no incremental, los dobles de prueba mal interpretados y la depuración frecuente consumen la mayor parte del esfuerzo.

Descubre más

¿Qué son las pruebas de módulos?

Pruebas de módulos Es un tipo de prueba de software que verifica subprogramas, subrutinas, clases o procedimientos individuales dentro de un programa. En lugar de probar todo el programa de software a la vez, las pruebas de módulos recomiendan probar los componentes más pequeños del programa.

Las pruebas de módulos se basan principalmente en el enfoque de caja blanca. El objetivo de las pruebas de módulos no es demostrar el correcto funcionamiento del módulo, sino la presencia de un error. Esta inversión es crucial: una ejecución que no encuentra nada confirma muy poco, mientras que una ejecución que revela un defecto cumple su cometido.

Las pruebas a nivel de módulo también permiten introducir el paralelismo en el proceso de prueba, ya que crean la oportunidad de probar varios módulos simultáneamente en lugar de esperar a que se complete la compilación.

Por qué hacer pruebas de módulos

Se recomienda realizar pruebas de módulos porque modifican la economía de la detección de defectos.

La probabilidad de identificar errores o fallos en fragmentos más pequeños de un programa aumenta.
Se pueden probar varios módulos simultáneamente, por lo que este enfoque permite realizar pruebas en paralelo.
La complejidad de las pruebas se puede gestionar fácilmente, ya que cada módulo se analiza de forma independiente.
Se encontró un defecto dentro de un módulo. tracPermite escribir una pequeña cantidad de código, por lo que el tiempo de depuración se reduce drásticamente.

¿Cómo hacer pruebas de módulos?

Diseñando un caso de prueba es el segmento importante de las pruebas de módulos. Al diseñar casos de prueba para una prueba de módulo, un probador debe tener en cuenta dos cosas.

Especificación para el módulo
El código fuente del módulo.

Analice la lógica del módulo utilizando uno o más de los siguientes métodos: caja blanca métodos, y luego complementar estos casos de prueba aplicando cuadro negro métodos para la especificación del módulo. Los valores realistas importan tanto como las rutas elegidas, así que prepare el datos de prueba junto con los casos, y no después.

Una vez diseñados los casos de prueba, el siguiente paso es combinar los módulos para realizar las pruebas. El método utilizado es uno u otro. incrementales no incremental método.

Método no incremental — Todos los módulos se prueban de forma independiente. Primero se combinan todos los módulos y luego se prueba el programa completo.
Método incremental — Cada módulo se prueba primero y luego se agrega gradualmente a la colección que se está probando. Se realiza una nueva prueba paso a paso.
Dentro de las pruebas incrementales existen dos enfoques, de arriba hacia abajo y de abajo hacia arriba pruebas.
Para ejecutar el módulo con los datos seleccionados, se requiere un controlador que suministre los datos de prueba, supervise la ejecución y capture los resultados.

La elección entre ambos métodos supone un compromiso entre el esfuerzo de configuración y la facilidad de diagnóstico.

Aspecto	Método incremental	Método no incremental
Mixta	Un módulo a la vez, añadido a una colección probada.	Todos los módulos combinados y luego probados juntos.
Se necesita andamio	Más controladores y esbozos, escritos progresivamente	Menos dobles de prueba, ya que hay módulos reales presentes.
Aislamiento de fallos	Fuerte: un fallo apunta al módulo recién añadido	Débil: un fallo podría tener su origen en cualquier parte.
Mejores adecuados para	Construcciones grandes con muchos módulos que interactúan entre sí.	Programas pequeños con pocos módulos y bajo acoplamiento

Controladores y stubs en las pruebas de módulos

El controlador mencionado anteriormente es uno de los dos componentes. Dado que un módulo bajo prueba rara vez se encuentra al principio o al final de la cadena de llamadas, los evaluadores sustituyen con código ficticio lo que falte a ambos lados.

Destornillador — reemplaza el módulo que realiza la llamada por encima del que se está probando. Proporciona los datos de prueba, invoca el módulo, supervisa la ejecución y captura los resultados. Las pruebas ascendentes dependen de los controladores, ya que los módulos inferiores están listos antes que los superiores.
Talón — reemplaza un módulo llamado que se encuentra debajo del que se está probando. Acepta la llamada y devuelve una respuesta fija y conocida para que el módulo bajo prueba pueda completar su ruta. Las pruebas descendentes dependen de los stubs, ya que los módulos superiores están listos primero.

Un caso práctico hace que la correspondencia sea concreta. Si un módulo de cálculo de pagos está terminado, pero la pantalla de pago que lo llama no lo está, un controlador le proporciona al módulo un conjunto de totales de pedido y registra la respuesta. Si el servicio de consulta de impuestos al que llama el módulo también está incompleto, un módulo auxiliar devuelve una tasa impositiva fija para que el cálculo continúe. Ninguno de los componentes básicos se implementa; ambos se descartan una vez que llegan los módulos reales, razón por la cual la mala interpretación de los simuladores de prueba se menciona más adelante como un desafío recurrente.

Consejos de ejemplo para la prueba de módulos

Aquí hay algunos consejos a tener en cuenta antes de realizar pruebas de módulos.

RevRevisa los casos de prueba antes de usarlos.
Evite confusiones sobre el origen de las discrepancias.
Utilice herramientas de prueba automatizadas.
Examine las variables que deberían permanecer sin cambios.
Intercambia los módulos entre los evaluadores para evitar las autopruebas.
Reutiliza los casos de prueba.

El quinto consejo tiene más peso del que aparenta. Un desarrollador que prueba únicamente el módulo recién escrito repite las mismas suposiciones que generaron el defecto, por lo que rotar los módulos entre diferentes personas es una de las maneras más económicas de mejorar la calidad.

Pruebas unitarias frente a pruebas de módulos

En muchos equipos, ambos términos se utilizan indistintamente, aunque la autoría y el alcance difieren.

Prueba de módulo	Examen de la unidad
Las pruebas de módulo son una colección de pruebas escritas por un evaluador después de que un desarrollador haya escrito algún código.	Pruebas unitarias son una colección de pruebas escritas por un desarrollador durante el proceso de desarrollo de software
Las pruebas de módulos pueden implicar la combinación de las pruebas unitarias.	Las pruebas unitarias pueden probar las unidades de forma aislada.

Pruebas de módulos vs. Pruebas de componentes vs. Pruebas de integración

Las pruebas de módulos también se ubican junto a dos niveles adyacentes que pueden confundirse fácilmente con este. La tabla los separa según lo que se está probando y quién normalmente realiza la prueba.

Aspecto	Pruebas de módulos	Prueba de componentes	Pruebas de integración
Bajo prueba	Un subprograma, clase o procedimiento	Un componente autónomo con sus dependencias inmediatas.	Las interfaces entre módulos combinados
Propietario habitual	Probador, después de que se escribe el código.	Tester	probador de integración
Andamio	Conductores y espárragos	Stubs para dependencias externas	Cada vez menos dobletes de prueba
Defecto expuesto	Error lógico dentro del módulo	Error de comportamiento en el componente	Error de interfaz y de paso de datos

En el uso cotidiano prueba de componentes y las pruebas de módulos se tratan frecuentemente como la misma actividad, mientras que pruebas de integración El proceso comienza únicamente una vez que cada módulo individual haya sido aprobado por separado.

Desafíos en las pruebas de módulos

Estos son los retos a los que se enfrentan con mayor frecuencia los equipos cuando se introducen las pruebas de módulos.

Las pruebas no incrementales requieren más trabajo — Combinar todo primero significa que un solo fallo puede hacer que los evaluadores tengan que repetir todo el programa.
La prueba de malentendidos se duplica — Un stub que devuelve un valor irreal produce una ejecución verde que no prueba nada.
A menudo, las pruebas de depuración — El código de andamiaje conlleva sus propios defectos, y el tiempo dedicado a corregir un controlador es tiempo que no se dedica a probar el módulo.
Necesito entender el código. — La orientación de caja blanca significa que un evaluador que no pueda leer el módulo no podrá diseñar casos significativos para él.

Preguntas Frecuentes

La familia xUnit abarca la mayoría de los lenguajes, con bibliotecas de simulación que proporcionan los stubs y una herramienta de cobertura que muestra qué rutas se alcanzaron. La elección depende del lenguaje del módulo, no del nivel de prueba.

Un modelo lee el código fuente del módulo, enumera las ramas y propone un caso para cada una, incluyendo valores límite que a menudo se pasan por alto en un análisis manual. RevLa revisión sigue siendo necesaria, porque los casos generados afirman lo que hace el código en lugar de lo que requiere la especificación.

Sí, y es precisamente en el andamiaje donde estos asistentes rinden al máximo, ya que un controlador o un fragmento de código es un código repetitivo con una estructura conocida. Los valores devueltos aún requieren una decisión humana, porque un fragmento de código que parezca plausible puede ocultar el defecto que se está buscando.

Basta con que cada rama y cada límite del módulo se hayan ejercitado al menos una vez. Un objetivo porcentual por sí solo puede resultar engañoso, ya que una alta cobertura de enunciados puede dejar resultados de decisiones completos sin probar.

Después de compilar un módulo y antes de que sus interfaces se prueben conjuntamente, se aplica el primer nivel de pruebas al código entregado. Por ello, los defectos detectados en esta etapa nunca llegan a las fases de integración o del sistema.

Sigue el código existente. El enfoque descendente es adecuado para proyectos donde primero se escribe la lógica de control y luego se crean módulos auxiliares; el enfoque ascendente es adecuado para proyectos donde primero se implementan los módulos de utilidad y los controladores los llaman.

El módulo se compila correctamente, su especificación está disponible, sus dependencias están presentes o simuladas, y los datos de prueba están listos. Si se empieza sin la especificación, el ejercicio se convierte en una descripción del código.

Las pruebas nunca pueden demostrar que un módulo no tiene defectos, solo que superó las pruebas realizadas. Por lo tanto, diseñar ejecuciones que intenten provocar fallos en el módulo proporciona más información que diseñar ejecuciones que se espera que pasen sin problemas.