Simulación de comandos y sustitución de herramientas externas

Cuando prueba un script de Bash que llama a curl, aws, git o cualquier herramienta externa, se enfrenta a un problema: las llamadas reales acceden a la red, modifican el estado, cuestan dinero o simplemente fallan en un entorno de CI donde esas herramientas no están instaladas.

Simular significa sustituir el comando real por uno falso que usted controla. Su elemento falso (el stub) devuelve una salida y unos códigos de salida predecibles, por lo que la prueba es rápida, aislada y reproducible.

• No se necesita acceso a la red ni a la nube
• Las pruebas se ejecutan en milisegundos en lugar de segundos
• Puede simular errores difíciles de provocar en sistemas reales
• Los pipelines de CI se mantienen limpios y sin dependencias

Bash ofrece un mecanismo sorprendentemente sencillo para hacerlo: coloque el binario falso en una ubicación anterior a la del binario real dentro de $PATH.

Cuando el shell ejecuta un comando como curl, busca en cada directorio de $PATH, de izquierda a derecha, y ejecuta la primera coincidencia que encuentra.

Esto significa que, si antepone un directorio que contiene su propio script curl, el shell nunca llegará a /usr/bin/curl.

El patrón de sustitución:

1. Cree un directorio temporal (su stub bin)
2. Escriba un ejecutable falso con el mismo nombre que el comando real
3. Anteponha ese directorio a PATH
4. Ejecute el script que se va a probar; este llamará a su stub, no al binario real
5. Limpie el directorio temporal después de la prueba

Esto funciona sin acceso root, sin modificar archivos del sistema y sin ningún framework especial.

El patrón estándar usa mktemp -d para crear un directorio temporal aislado para los stubs. Cada prueba o suite de pruebas obtiene su propio directorio, lo que evita la contaminación entre pruebas.

Cuando termine la prueba, elimine el directorio con rm -rf. Usar un trap garantiza la limpieza incluso si la prueba finaliza antes de tiempo debido a un error.

Un stub no es más que un archivo ejecutable con el mismo nombre que el comando que desea sustituir. Imprime la salida que espera el script que se está probando y termina con el código que usted elija.

Reglas principales para los stubs:

• El archivo debe ser ejecutable (chmod +x)
• La línea de shebang (#!/usr/bin/env bash) es obligatoria
• Imprima la salida que analizaría su script real
• Use exit 0 para indicar éxito y un valor distinto de cero para simular fallos

Ahora vamos a juntar todo. Suponga que tiene un script de despliegue que llama a curl para comprobar un endpoint de estado y que termina con un error si el servicio no está operativo. Quiere probar tanto el caso esperado como el caso de error sin usar un servidor real.

Uno de los usos más valiosos de los stubs es simular fallos que son difíciles de reproducir con herramientas reales: tiempos de espera de red, errores de permisos, disco lleno o una API remota que devuelve un 500.

Para simular un fallo, haga que el stub termine con un código distinto de cero. También puede escribir en stderr exactamente como lo haría el comando real, para probar por completo el manejo de errores de su script.

A veces necesita comprobar no solo qué muestra su script, sino también cómo llamó a una herramienta externa: los argumentos que le pasó, cuántas veces la llamó o en qué orden. Un stub espía registra sus invocaciones en un archivo.

Después de la prueba, su entorno de pruebas lee el archivo de registro y comprueba su contenido. Así obtiene una verificación a nivel de argumentos sin ningún framework especial.

Un script real suele llamar a varias herramientas externas. Puede simularlas todas en el mismo directorio STUB_BIN. Cada archivo de stub es independiente y puede devolver salidas y códigos de salida diferentes.

Mantenga los stubs mínimos: devuelva únicamente lo que el script que está probando realmente analiza. No intente simular todas las opciones; limítese al subconjunto que utiliza su script.

En casos sencillos, no necesita escribir ningún archivo. Puede definir una función de shell con el mismo nombre que el comando. Como las funciones se resuelven antes de buscar ejecutables externos en PATH, tienen prioridad automáticamente.

Este es el enfoque más rápido para realizar pruebas unitarias de scripts cargados con source. Sin embargo, los stubs basados en funciones solo funcionan dentro del mismo proceso de shell; no estarán disponibles para subshells iniciados explícitamente con bash -c ni para procesos ejecutados en segundo plano. En esos casos, use el enfoque basado en archivos.

Cuando el script que está probando inicia un subshell (por ejemplo, bash script.sh o una tubería), los stubs de funciones de shell definidos en el proceso padre no se heredan de forma predeterminada. Tiene dos opciones:

• Use export -f function_name para exportar la función; estará disponible para los procesos hijos de bash
• O recurra a stubs basados en archivos en un directorio STUB_BIN, que siempre funcionan entre distintos procesos

export -f es elegante, pero solo funciona con bash (no con sh ni con otros shells). En entornos de CI políglotas, dé preferencia a los stubs basados en archivos.

Cuando utiliza BATS (Bash Automated Testing System), la configuración de los stubs debe hacerse en el hook setup() y la limpieza, en teardown(). BATS restablece el entorno entre pruebas, por lo que cada prueba obtiene un directorio de stubs nuevo.

Las variables de BATS, como $BATS_TEST_TMPDIR, le proporcionan automáticamente un directorio temporal para cada prueba; úselo en lugar de mktemp -d para obtener un código más limpio.

Compruebe su comprensión de la simulación de comandos y los patrones de stubs en Bash.

Un desarrollador escribe una prueba que define una función de shell llamada aws para simular el AWS CLI real. La prueba funciona correctamente directamente en la terminal, pero cuando la canalización de CI ejecuta el script que se está probando como bash deploy.sh, el stub se ignora y se llama al comando aws real.

¿Cuál es la solución correcta?

Ha aprendido el conjunto completo de herramientas para reemplazar comandos reales por simulaciones controladas durante las pruebas de scripts de Bash.

Técnicas principales:

• Anteponer una ruta a PATH: cree un directorio STUB_BIN con mktemp -d, escriba allí archivos de stub ejecutables y anteponga el directorio a PATH
• Códigos de salida de los stubs: devuelva 0 para indicar éxito y valores distintos de cero para simular fallos concretos (errores de red, permiso denegado, etc.)
• Stubs espía: añada los argumentos a un archivo de registro dentro del stub para comprobar cómo su script llamó a las herramientas externas
• Varios stubs: coloque varios archivos de stub en el mismo STUB_BIN para simular de una vez todo un ecosistema de dependencias
• Stubs de funciones: defina una función de shell con el mismo nombre que un comando para simularlo dentro del mismo proceso; use export -f para llegar a procesos hijos de Bash
• Integración con BATS: use los hooks setup()/teardown() y $BATS_TEST_TMPDIR para aislar correctamente cada prueba

Use siempre un trap '...' EXIT para garantizar la limpieza de los stubs independientemente del resultado de la prueba. Mantenga los stubs mínimos: devuelva únicamente lo que su script analiza realmente. Los stubs basados en archivos son la opción más portable para las canalizaciones de CI.