Test-fixtures, midlertidige miljøer og dækning

Når du tester Bash-scripts, er den største risiko bivirkninger: at dine tests ved et uheld ændrer rigtige filer, rigtige databaser eller den virkelige systemtilstand. En test, der består på din maskine, men ødelægger produktionsdata, er værre end slet ingen test.

Løsningen er test-fixtures — kontrollerede, midlertidige miljøer, der afspejler virkelige forhold uden at røre noget virkeligt. Gode fixtures giver dig:

• Reproducerbarhed — tests giver det samme resultat hver gang
• Isolation — tests påvirker ikke hinanden eller værtsmaskinen
• Sikkerhed — destruktive handlinger berører kun data, der kan kasseres
• Hastighed — ingen netværkskald og ingen tung I/O, medmindre det er absolut nødvendigt

I Bash-testning er fixtures typisk midlertidige mapper med kendte filer, falske eksekverbare filer placeret tidligt i $PATH og miljøvariabler, der er begrænset til testprocessen.

Det almindelige mønster for en midlertidig mappe pr. test bruger mktemp -d, som opretter en unik mappe i /tmp og udskriver dens sti. Du gemmer stien og registrerer en trap, der automatisk fjerner mappen, når shellen afsluttes — også ved fejl.

Dette idiom på to linjer bør findes i enhver testfil, der arbejder med filsystemet:

En velstruktureret fixture afspejler den mappestruktur, som dit script under test faktisk forventer. Tænk på den som en miniature-rodmappe for et falsk projekt. Fixture-opsætningsfunktionen opretter denne struktur før hver test, og oprydningen fjerner den.

Vigtige fremgangsmåder:

• Brug en setup()-funktion, som dit testframework kalder før hver test
• Brug en teardown() eller cleanup(), der kører efter hver test, også ved fejl
• Hold fixture-filer minimale — kun det, som scriptet faktisk læser
• Navngiv fixture-filer beskrivende, så fejl er nemme at diagnosticere

Mange Bash-scripts kalder eksterne værktøjer som curl, aws, docker eller git. I tests vil du ikke ramme rigtige tjenester, så du erstatter disse værktøjer med falske eksekverbare filer.

Teknikken er enkel:

1. Opret en midlertidig bin/-mappe i din fixture
2. Skriv små shell-scripts dér med samme navne som de rigtige værktøjer
3. Sæt mappen forrest i $PATH, før du kalder dit script under test

Da $PATH gennemsøges fra venstre mod højre, vinder den falske fil. Den rigtige binærfil bliver aldrig kaldt.

En fixture er kun nyttig, hvis du kan kontrollere, hvad dit script gjorde. De almindelige mønstre er:

• Opsaml stdout/stderr i variabler med $() eller proces-substitution
• Undersøg logfiler, som falske binærfiler har skrevet
• Kontrollér afslutningskoder eksplicit med $? eller betinget logik
• Kontrollér, at bestemte filer blev oprettet, ændret eller ikke blev berørt

Hvis du skriver små, fokuserede hjælpefunktioner til kontrol, bliver dine tests læsbare, og du får præcise fejlmeddelelser, når noget går galt.

Scripts læser ofte fra miljøvariabler som $HOME, $CONFIG_PATH eller $DATABASE_URL. I tests skal du overskrive disse uden at forurene det rigtige miljø.

Den sikreste metode er at køre scriptet under test i en subshell med kun de variabler, du eksplicit angiver. Kommandoen env lader dig reducere miljøet og derefter tilføje netop det, du har brug for:

• env -i VAR=val ./script.sh — helt rent miljø
• (export VAR=val; ./script.sh) — subshell nedarver det overordnede miljø samt dine overskrivninger

Brug af subshells betyder også, at hvis scriptet ændrer $IFS, $PWD eller anden global tilstand, slipper ændringerne aldrig tilbage til din testrunner.

Dækning besvarer spørgsmålet: Hvilke linjer (og grene) i mit script udførte testene faktisk? Et højt dæknings-tal garanterer ikke korrekthed, men et lavt tal afslører uprøvede stier, som sandsynligvis indeholder fejl.

Det vigtigste værktøj til Bash-dækning er kcov. Det fungerer ved at instrumentere scriptet på OS-niveau med PTRACE (Linux) eller dtrace (macOS), så det ikke kræver ændringer i kildekoden. Det producerer en HTML-rapport, der viser røde (ikke dækkede) og grønne (dækkede) linjer.

Grundlæggende brug:

• kcov --include-path=./src coverage-out/ ./src/myscript.sh
• Åbn coverage-out/index.html i en browser for at undersøge resultaterne
• I CI skal du fortolke coverage-out/myscript.sh/coverage.json for at få en maskinlæsbar procentværdi

Bemærk: kcov skal installeres separat (brew install kcov på macOS, apt install kcov på Ubuntu 20.04+).

Her er et eksempel fra start til slut, der viser et script, som kan sættes i drift, en test, der gennemgår det, og kcov-kaldet, der måler dækningen. Bemærk, at outputmappen er specifik for testen, så du senere kan sammenflette resultater fra flere testkørsler.

En enkelt test dækker sjældent alle grene. Du kører flere tests — hver i sin egen outputmappe for dækning — og sammenfletter dem derefter. kcow's --merge-flag kombinerer flere kørsler til én samlet rapport.

Det typiske mønster i en CI-pipeline:

• Kør test A → output til cov/test_a/
• Kør test B → output til cov/test_b/
• Sammenflet → kcov --merge cov/all/ cov/test_a/ cov/test_b/
• Fortolk cov/all/<script>/coverage.json for at få den endelige procentværdi

Du kan også håndhæve en minimumsgrænse og få CI-buildet til at mislykkes, hvis dækningen falder under den:

Der er to primære dækningsmålinger, som du vil møde:

• Linjedækning — blev denne linje overhovedet udført? Den er nem at manipulere med: En enkelt test kan berøre mange linjer, samtidig med at den overser vigtige betingede stier.
• Gren-dækning — blev hver gren i hver if, case og &&/|| valgt? Det er et langt stærkere signal. Det kræver tests af både den sande og den falske side af hver beslutning.

kcov rapporterer begge dele. Den vigtigste pointe er: 100 % linjedækning medfører ikke 100 % gren-dækning. Overvej dette script — en enkelt test med en ikke-tom fil dækker hver linje, men grenen for en tom fil (linje 9 nedenfor) nås aldrig:

Her samles det hele: Et robust CI-forløb til Bash-projekter kombinerer opsætning af testfixtures, testkørsel under kcov, sammenfletning og en tærskelkontrol i ét script. Dette script bliver indgangspunktet til CI — én kommando til at køre det hele.

Designprincipper for CI-testkøreren:

• Hver test case kalder setup_fixture og registrerer teardown_fixture via trap
• Scripten, der testes, kaldes med en falsk $PATH og afgrænsede miljøvariabler
• kcov omslutter hver kørsel og skriver til en nummereret undermappe
• Efter alle tests sammenfletter kcov resultaterne, og tærskelscripten fungerer som kontrol for bygningen
• CI-testkøreren afsluttes med en fejlkode, hvis en test eller kodedækningskontrollen mislykkes

Denne lektion gennemgik hele værktøjskassen til pålidelig og isoleret Bash-testning:

• Midlertidige mapper — mktemp -d sammen med en trap ... EXIT garanterer automatisk oprydning, uanset hvordan testen afsluttes.
• Testfixturestruktur — Et par bestående af setup_fixture og teardown_fixture udfylder og sletter et minimalt mappetræ, der afspejler virkelige input til scripts.
• Falsk PATH — Placér stub-kørbare filer i $FIXTURE/bin/, og indsæt den forrest i $PATH for at opfange kald til curl, aws, docker eller et hvilket som helst eksternt værktøj uden at røre systemets binærfiler.
• Afgrænsning af miljøet — Kør scripten, der testes, i en subshell (() eller env -i), så ændrede variabler aldrig lækker tilbage til testkøreren.
• Påstande — Små hjælpefunktioner (assert_eq, assert_file_exists, assert_contains) giver tydeligt bestået/mislykket-output og meningsfulde fejlmeddelelser.
• kcov-kodedækning — Omslutter scriptafkørsel uden ændringer af kildekoden og producerer HTML- og JSON-rapporter for linje- og grendækning.
• Sammenfletning og tærskel — Kombinér flere kcov-kørsler med --merge, fortolk JSON-resultatet, og lad CI mislykkes, hvis kodedækningen falder under dit minimum.
• Grendækning kontra linjedækning — Sigt altid efter grendækning; linjedækning alene kan overse hele betingede forløb og give falsk tryghed.

Med disse teknikker bliver dine Bash-tests lige så grundige som tests af ethvert kompileret sprog.