Simulare comandi e creare stub per strumenti esterni

Quando si testa uno script Bash che chiama curl, aws, git o un altro strumento esterno, si presenta un problema: le chiamate reali accedono alla rete, modificano lo stato, hanno un costo o semplicemente falliscono in un ambiente CI in cui tali strumenti non sono installati.

Mocking significa sostituire il comando reale con uno falso sotto il proprio controllo. Il falso (lo stub) restituisce output e codici di uscita prevedibili, rendendo il test rapido, isolato e riproducibile.

• Non è necessario alcun accesso alla rete o al cloud
• I test vengono eseguiti in millisecondi anziché in secondi
• È possibile simulare errori difficili da riprodurre sui sistemi reali
• Le pipeline CI rimangono pulite e prive di dipendenze

Bash offre un meccanismo sorprendentemente semplice per farlo: è sufficiente inserire il proprio binario falso in una posizione precedente a quello reale in $PATH.

Quando la shell esegue un comando come curl, cerca in ogni directory di $PATH, da sinistra a destra, ed esegue la prima corrispondenza trovata.

Questo significa che, anteponendo a PATH una directory contenente un proprio script curl, la shell non raggiungerà mai /usr/bin/curl.

Pattern di sostituzione:

1. Creare una directory temporanea (la propria stub bin)
2. Scrivere un eseguibile falso con lo stesso nome del comando reale
3. Anteporre quella directory a PATH
4. Eseguire lo script da testare: chiamerà il proprio stub, non il binario reale
5. Ripulire la directory temporanea dopo il test

Questa tecnica funziona senza accesso root, senza modificare i file di sistema e senza alcun framework speciale.

Il pattern standard usa mktemp -d per creare una directory temporanea isolata per gli stub. Ogni test o suite di test dispone della propria directory, evitando contaminazioni tra test.

Al termine del test, rimuovere la directory con rm -rf. L'uso di un trap garantisce la pulizia anche quando il test termina anticipatamente a causa di un errore.

Uno stub è semplicemente un file eseguibile con lo stesso nome del comando che si desidera sostituire. Stampa l'output previsto dallo script in fase di test e termina con il codice scelto.

Regole fondamentali per gli stub:

• Il file deve essere eseguibile (chmod +x)
• La riga shebang (#!/usr/bin/env bash) è obbligatoria
• Stampare l'output che lo script reale dovrebbe analizzare
• Usare exit 0 per indicare il successo e un valore diverso da zero per simulare gli errori

Ora mettiamo insieme i concetti. Supponiamo di avere uno script di deployment che chiama curl per controllare un endpoint di stato, quindi termina con un errore se il servizio non è operativo. Si desidera testare sia il percorso di successo sia quello di errore senza usare un server reale.

Uno degli utilizzi più preziosi degli stub è la simulazione dei fallimenti difficili da riprodurre con strumenti reali: timeout di rete, errori di autorizzazione, disco pieno o un'API remota che restituisce un 500.

Per simulare un fallimento, è sufficiente fare in modo che lo stub termini con un codice diverso da zero. È inoltre possibile scrivere in stderr esattamente come farebbe il comando reale, così da verificare completamente la gestione degli errori dello script.

A volte è necessario verificare non solo che cosa produce lo script, ma anche come chiama uno strumento esterno: gli argomenti passati, il numero di chiamate o il loro ordine. Uno stub spy registra le chiamate in un file.

Dopo il test, il test harness legge il file dei record e ne verifica il contenuto. In questo modo si ottiene una verifica a livello di argomento senza alcun framework speciale.

Uno script reale chiama spesso diversi strumenti esterni. È possibile creare gli stub per tutti questi strumenti nella stessa directory STUB_BIN. Ogni file stub è indipendente e può restituire output e codici di uscita diversi.

Mantenga gli stub essenziali: restituisca solo ciò che lo script sottoposto al test analizza effettivamente. Non cerchi di simulare ogni flag, ma solo il sottoinsieme utilizzato dallo script.

Per i casi semplici non è necessario scrivere alcun file. È possibile definire una funzione shell con lo stesso nome del comando. Poiché le funzioni vengono risolte prima della ricerca esterna in PATH, hanno automaticamente la precedenza.

Questo è l'approccio più rapido per i test unitari degli script con codice caricato tramite source. Tuttavia, gli stub basati su funzioni funzionano solo all'interno dello stesso processo della shell: non sono visibili alle subshell avviate con bash -c in modo esplicito né ai processi eseguiti in background. In questi casi, utilizzi l'approccio basato sui file.

Quando lo script sottoposto al test avvia una subshell (ad esempio bash script.sh o una pipeline), gli stub di funzioni shell definiti nel processo padre non vengono ereditati per impostazione predefinita. Sono disponibili due opzioni:

• Utilizzare export -f function_name per esportare la funzione, rendendola disponibile ai processi bash figli
• Oppure ricorrere agli stub basati su file in una directory STUB_BIN, che funzionano sempre oltre i confini tra processi

export -f è elegante, ma funziona solo con bash (non con sh o altre shell). Preferisca gli stub basati su file negli ambienti CI poliglotta.

Quando utilizza BATS (Bash Automated Testing System), la configurazione degli stub deve trovarsi nell'hook setup() e la pulizia nell'hook teardown(). BATS ripristina l'ambiente tra un test e l'altro, quindi ogni test dispone di una directory per gli stub nuova.

Le variabili di BATS, come $BATS_TEST_TMPDIR, forniscono automaticamente una directory temporanea per ogni test: la utilizzi al posto di mktemp -d per ottenere codice più pulito.

Verifichi la propria comprensione della simulazione dei comandi e dei modelli di stub in Bash.

Uno sviluppatore scrive un test che definisce una funzione shell chiamata aws per simulare la vera AWS CLI. Il test funziona correttamente se eseguito direttamente nel terminale, ma quando la pipeline CI esegue lo script sottoposto al test come bash deploy.sh, lo stub viene ignorato e viene chiamato il comando reale aws.

Qual è la correzione corretta?

Ha appreso il kit completo di strumenti per sostituire i comandi reali con simulazioni controllate durante i test degli script Bash.

Tecniche fondamentali trattate:

• Prependere una directory a PATH — creare una directory STUB_BIN con mktemp -d, scrivervi file stub eseguibili e anteporre la directory a PATH
• Codici di uscita degli stub — restituire 0 per il successo e valori diversi da zero per simulare fallimenti specifici (errori di rete, autorizzazione negata e così via)
• Stub spy — aggiungere gli argomenti a un file di log all'interno dello stub per verificare come lo script ha chiamato gli strumenti esterni
• Più stub — inserire diversi file stub nella stessa directory STUB_BIN per simulare contemporaneamente un intero ecosistema di dipendenze
• Stub di funzione — definire una funzione shell con lo stesso nome di un comando per la simulazione nello stesso processo; utilizzare export -f per raggiungere i processi bash figli
• Integrazione con BATS — utilizzare gli hook setup()/teardown() e $BATS_TEST_TMPDIR per un isolamento pulito tra i test

Utilizzi sempre un trap '...' EXIT per garantire la pulizia degli stub indipendentemente dall'esito del test. Mantenga gli stub essenziali: restituisca solo ciò che lo script analizza effettivamente. Gli stub basati su file sono la scelta più portabile per le pipeline CI.