Testfiksturer, midlertidige miljøer og dekningsgrad

Ved testing av Bash-skript er den største risikoen bivirkninger: Testene endrer ved et uhell ekte filer, ekte databaser eller den faktiske systemtilstanden. En test som består på maskinen Deres, men ødelegger produksjonsdata, er verre enn ingen test i det hele tatt.

Løsningen er test-fixtures – kontrollerte, kortvarige miljøer som gjenspeiler virkelige forhold uten å berøre noe ekte. Gode fixtures gir Dem:

• Reproduserbarhet – testene gir samme resultat hver gang
• Isolasjon – testene forstyrrer ikke hverandre eller vertsmaskinen
• Sikkerhet – destruktive operasjoner berører bare data som kan kastes
• Hastighet – ingen nettverkskall og ingen omfattende I/O med mindre det er helt nødvendig

Ved Bash-testing er fixtures vanligvis midlertidige kataloger fylt med kjente filer, falske kjørbare filer som plasseres tidlig i $PATH, og miljøvariabler som er begrenset til testprosessen.

Det standardiserte mønsteret for en midlertidig katalog per test bruker mktemp -d, som oppretter en unik katalog i /tmp og skriver ut banen til den. De lagrer banen og registrerer en trap for å fjerne katalogen automatisk når skallet avsluttes – også ved feil.

Dette tolinjers idiomet bør finnes i alle testfiler som berører filsystemet:

En godt strukturert fixture gjenspeiler katalogoppsettet som skriptet som testes, faktisk forventer. Tenk på den som en miniatyrisert falsk prosjektrot. Fixture-oppsettfunksjonen oppretter dette oppsettet før hver test, og teardown fjerner det.

Viktig praksis:

• Bruk en setup()-funksjon som testrammeverket kaller før hver test
• Bruk en teardown() eller cleanup() som kjøres etter hver test, også ved feil
• Hold fixture-filene minimale – bare det skriptet faktisk leser
• Gi fixture-filene beskrivende navn, slik at feil blir enkle å diagnostisere

Mange Bash-skript kaller eksterne verktøy som curl, aws, docker eller git. I tester ønsker De ikke å kontakte ekte tjenester, så De erstatter verktøyene med falske kjørbare filer.

Teknikken er enkel:

1. Opprett en midlertidig bin/-katalog i fixturen
2. Skriv små shell-skript der med samme navn som de ekte verktøyene
3. Legg katalogen først i $PATH før De kaller skriptet som testes

Ettersom $PATH søkes gjennom fra venstre mot høyre, vinner den falske filen. Den ekte binærfilen blir aldri kalt.

En fixture er bare nyttig hvis De kan kontrollere hva skriptet gjorde. Standardmønstrene er:

• Fang stdout/stderr i variabler med $() eller prosessubstitusjon
• Undersøk loggfiler som er skrevet av falske binærfiler
• Kontroller avslutningskoder eksplisitt med $? eller betinget logikk
• Bekreft at bestemte filer ble opprettet, endret eller ikke berørt

Hvis De skriver små, fokuserte hjelpefunksjoner for kontroll, blir testene lettere å lese, og De får presise feilmeldinger når noe går galt.

Skript leser ofte fra miljøvariabler som $HOME, $CONFIG_PATH eller $DATABASE_URL. I tester må De overstyre disse uten å forurense det virkelige miljøet.

Den tryggeste tilnærmingen er å kjøre skriptet som testes, i et underskall med bare variablene De angir eksplisitt. Kommandoen env lar Dem redusere miljøet og legge tilbake bare det De trenger:

• env -i VAR=val ./script.sh – helt rent miljø
• (export VAR=val; ./script.sh) – underskallet arver det overordnede miljøet og får i tillegg overstyringene Deres

Bruk av underskall innebærer også at hvis skriptet endrer $IFS, $PWD eller annen global tilstand, slipper disse endringene aldri tilbake til testkjøringen.

Dekningsgrad svarer på spørsmålet: Hvilke linjer (og grener) i skriptet ble faktisk kjørt av testene? En høy dekningsgrad garanterer ikke at koden er riktig, men en lav dekningsgrad avdekker uprøvde kjørebaner som sannsynligvis kan inneholde feil.

Hovedverktøyet for Bash-dekning er kcov. Det fungerer ved å instrumentere skriptet på operativsystemnivå ved hjelp av PTRACE (Linux) eller dtrace (macOS), og krever derfor ingen endringer i kildekoden. Det produserer en HTML-rapport som viser røde linjer (ikke dekket) og grønne linjer (dekket).

Grunnleggende bruk:

• kcov --include-path=./src coverage-out/ ./src/myscript.sh
• Åpne coverage-out/index.html i en nettleser for å undersøke resultatene
• Parse coverage-out/myscript.sh/coverage.json i CI for å få en maskinlesbar prosentverdi

Merk: kcov må installeres separat (brew install kcov på macOS, apt install kcov på Ubuntu 20.04+).

Her er et komplett eksempel som viser et distribuerbart skript, en test som kjører det, og kcov-kallet som måler dekningen. Legg merke til at utdatakatalogen er separat for hver test, slik at De kan slå sammen resultater fra flere testkjøringer senere.

En enkelt test dekker sjelden alle grener. De kjører flere tester – hver i sin egen katalog for dekningsutdata – og slår dem deretter sammen. kcovs --merge-flagg kombinerer flere kjøringer til én samlet rapport.

Det typiske mønsteret i en CI-pipeline:

• Kjør test A → skriv utdata til cov/test_a/
• Kjør test B → skriv utdata til cov/test_b/
• Slå sammen → kcov --merge cov/all/ cov/test_a/ cov/test_b/
• Parse cov/all/<script>/coverage.json for å hente den endelige prosentverdien

De kan også håndheve en minimumsgrense og la CI-byggingen mislykkes hvis dekningen faller under den:

Det finnes to hovedmål for dekningsgrad som De vil møte:

• Linjedekning – ble denne linjen kjørt i det hele tatt? Den er enkel å manipulere: Én enkelt test kan berøre mange linjer uten å dekke viktige betingede kjørebaner.
• Gren-dekning – ble hver gren i hver if, case og &&/|| fulgt? Dette gir et langt sterkere signal. Det krever tester for både den sanne og den usanne siden av hver avgjørelse.

kcov rapporterer begge deler. Den viktige innsikten er: 100 % linjedekning innebærer ikke 100 % gren-dekning. Se på dette skriptet – én enkelt test med en fil som ikke er tom, vil dekke hver linje, men grenen for tom fil (linje 9 nedenfor) blir aldri nådd:

La oss sette alt sammen: En robust CI-pipeline for Bash-prosjekter kombinerer oppsett av fixtures, testkjøring med kcov, sammenslåing og en terskelsjekk i ett enkelt skript. Dette skriptet blir inngangspunktet for CI – én kommando for å kjøre alt.

Designprinsipper for CI-testkjøreren:

• Hver test case kaller setup_fixture og registrerer teardown_fixture via trap
• Skriptet som testes, startes med en falsk $PATH og avgrensede miljøvariabler
• kcov pakker inn hver kjøring og skriver resultatet til en nummerert undermappe
• Etter alle testene slår kcov sammen resultatene, og terskelskriptet avgjør om byggingen får passere
• CI-kjøreren avsluttes med en status ulik null hvis en test eller dekning-sjekken feiler

Denne leksjonen dekket hele verktøykassen for pålitelig og isolert testing av Bash:

• Midlertidige mapper – mktemp -d sammen med en trap ... EXIT garanterer automatisk opprydding, uansett hvordan testen avsluttes.
• Fixture-struktur – Et par med setup_fixture og teardown_fixture oppretter og sletter et minimalt mappetre som gjenspeiler virkelige inndata til skriptet.
• Falsk PATH – Plasser stub-kjørbare filer i $FIXTURE/bin/, og sett denne mappen foran $PATH for å fange opp kall til curl, aws, docker eller andre eksterne verktøy uten å berøre systemets binærfiler.
• Avgrensning av miljø – Kjør skriptet som testes i et subshell (() eller env -i) slik at endrede variabler aldri lekker tilbake til testkjøreren.
• Påstander – Små hjelpefunksjoner (assert_eq, assert_file_exists, assert_contains) gir tydelig bestått/ikke bestått-utdata og meningsfulle feilmeldinger.
• kcov-dekning – Pakker inn kjøringen av skriptet uten endringer i kildekoden og produserer HTML- og JSON-rapporter for linje- og grendekning.
• Sammenslåing og terskel – Kombiner flere kcov-kjøringer med --merge, analyser JSON-filen og la CI feile hvis dekningen faller under minimumsgrensen.
• Grendekning kontra linjedekning – Sikt alltid mot grendekning. Linjedekning alene kan overse hele betingede kjørebaner og gi falsk trygghet.

Med disse teknikkene blir Bash-testene Deres like grundige som tester for ethvert kompilert språk.