Mocka kommandon och stubba externa verktyg

När Ni testar ett Bash-skript som anropar curl, aws, git eller något annat externt verktyg uppstår ett problem: riktiga anrop når nätverket, ändrar tillstånd, kostar pengar eller misslyckas helt enkelt i en CI-miljö där verktygen inte är installerade.

Mocking innebär att det riktiga kommandot ersätts med ett falskt som Ni kontrollerar. Er falska implementation (en stub) returnerar förutsägbara utdata och slutstatusar, så att testet blir snabbt, isolerat och reproducerbart.

• Ingen åtkomst till nätverk eller molntjänster behövs
• Tester körs på millisekunder i stället för sekunder
• Ni kan simulera fel som är svåra att utlösa i riktiga system
• CI-pipelines förblir rena och fria från beroenden

Bash ger Er en förvånansvärt enkel mekanism för detta: placera bara Er falska binärfil någonstans tidigare i $PATH än den riktiga.

När shellen kör ett kommando som curl söker den igenom varje katalog i $PATH från vänster till höger och kör den första träff den hittar.

Det innebär att shellen aldrig når /usr/bin/curl om Ni lägger till en katalog först som innehåller Ert eget curl-skript.

Mönstret för att åsidosätta kommandon:

1. Skapa en temporär katalog (Er stub-bin)
2. Skriv en falsk körbar fil med samma namn som det riktiga kommandot
3. Lägg till katalogen först i PATH
4. Kör skriptet som testas — det anropar Er stub i stället för den riktiga binärfilen
5. Städa bort den temporära katalogen efter testet

Detta fungerar utan root-åtkomst, utan att systemfiler ändras och utan något särskilt ramverk.

mktemp -d för att skapa en isolerad temporär katalog för Era stubbar. Varje test eller testsvit får sin egen katalog, vilket förhindrar att tester påverkar varandra.

När testet är klart tar Ni bort katalogen med rm -rf. Med en trap säkerställs städningen även när testet avslutas i förtid på grund av ett fel.

En stub är helt enkelt en körbar fil med samma namn som kommandot Ni vill ersätta. Den skriver ut den utdata som skriptet som testas förväntar sig och avslutas med den kod Ni väljer.

Viktiga regler för stubbar:

• Filen måste vara körbar (chmod +x)
• Shebang-raden (#!/usr/bin/env bash) krävs
• Skriv ut den utdata som Ert riktiga skript skulle tolka
• Använd exit 0 vid lyckat resultat och ett värde som inte är noll vid simulerade fel

Nu sätter vi ihop delarna. Anta att Ni har ett distributionsskript som anropar curl för att kontrollera en hälsoendpunkt och sedan avslutas med ett fel om tjänsten inte är frisk. Ni vill testa både det lyckade fallet och felvägen utan en riktig server.

En av de mest värdefulla användningarna av stubbar är att simulera fel som är svåra att återskapa med riktiga verktyg – nätverkstimeouter, behörighetsfel, fulla diskar eller ett fjärr-API som returnerar 500.

För att simulera ett fel låter du helt enkelt stubben avslutas med en kod som inte är noll. Du kan också skriva till stderr precis som det riktiga kommandot skulle göra, så att skriptets felhantering testas fullt ut.

Ibland behöver du kontrollera inte bara vad skriptet skriver ut, utan också hur det anropar ett externt verktyg – vilka argument det skickar, hur många gånger det anropas eller i vilken ordning. En spionstub loggar sina anrop till en fil.

Efter testet läser testharnessen loggfilen och kontrollerar dess innehåll. Det ger dig verifiering på argumentnivå utan något särskilt ramverk.

Ett verkligt skript anropar ofta flera externa verktyg. Du kan stubba alla i samma STUB_BIN-katalog. Varje stubfil är fristående och kan returnera olika utdata och avslutskoder.

Håll stubbarna minimala: returnera bara det som skriptet under test faktiskt tolkar. Försök inte simulera alla flaggor – använd bara den delmängd som skriptet använder.

I enkla fall behöver du inte skriva några filer alls. Du kan definiera en skalfunktion med samma namn som kommandot. Eftersom funktioner matchas före sökning i den externa PATH:en får de automatiskt företräde.

Detta är den snabbaste metoden för enhetstestning av skript som läses in med source. Funktionsstubbar fungerar dock bara i samma skalprocess – de är inte synliga för underskal som startas med uttryckligt bash -c eller för bakgrundsprocesser. Använd den filbaserade metoden i sådana fall.

När skriptet under test startar ett underskal (t.ex. bash script.sh eller en pipeline) är skalfunktioner som definierats i det överordnade skalet intevs ärvs som standard. Du har två alternativ:

• Använd export -f function_name för att exportera funktionen – då blir den tillgänglig i underordnade bash-processer
• Eller använd filbaserade stubbar i en STUB_BIN-katalog, vilket alltid fungerar över processgränser

export -f är elegant, men fungerar bara med bash (inte med sh eller andra skal). Föredra filbaserade stubbar i polyglotta CI-miljöer.

När du använder BATS (Bash Automated Testing System) hör stubbförberedelserna hemma i hooken setup(), och nedstängningen i teardown(). BATS återställer miljön mellan testerna, så varje test får en ny stubkatalog.

BATS-variabler som $BATS_TEST_TMPDIR ger dig automatiskt en temporär katalog per test – använd den i stället för mktemp -d för renare kod.

Du har lärt dig hela verktygslådan för att ersätta riktiga kommandon med kontrollerade ersättningar när du testar Bash-skript.

Viktiga tekniker:

• PATH-företräde – skapa en STUB_BIN-katalog med mktemp -d, skriv körbara stubfiler där och placera katalogen först i PATH
• Stubbers avslutskoder – returnera 0 vid lyckat resultat och värden som inte är noll för att simulera specifika fel (nätverksfel, nekad åtkomst osv.)
• Spionstubbar – lägg till argument i en loggfil inifrån stubben för att kontrollera hur skriptet anropade externa verktyg
• Flera stubbar – placera flera stubfiler i samma STUB_BIN för att mocka ett helt ekosystem av beroenden samtidigt
• Funktionsstubbar – definiera en skalfunktion med samma namn som ett kommando för mockning i samma process; använd export -f för att nå underordnade bash-processer
• BATS-integrering – använd hookarna setup()/teardown() och $BATS_TEST_TMPDIR för ren isolering per test

Använd alltid en trap '...' EXIT för att garantera att stubbarna städas bort oavsett testresultat. Håll stubbarna minimala – returnera bara det som skriptet faktiskt tolkar. Filbaserade stubbar är det mest portabla valet för CI-pipelines.