🧪 1. Das BATS Framework (@test, run, assertions)
BATS erlaubt sauberes Test-Driven Development (TDD) für Shell-Skripte mit automatischer Isolation von Testfällen:
#!/usr/bin/env bats
setup() {
export TEST_CONFIG="/tmp/app_test.conf"
echo "PORT=8080" > "$TEST_CONFIG"
}
teardown() {
rm -f "$TEST_CONFIG"
}
@test "App startet mit gültiger Konfiguration" {
run ./app.sh --config "$TEST_CONFIG"
[ "$status" -eq 0 ]
[ "${lines[0]}" = "Server listening on 8080" ]
}🎠2. Mocking & Sandbox-Isolation über PATH
Weil Unittests keine echten Server oder Cloud-APIs anrufen sollen, fangen wir Binaries wie docker oder systemctl per PATH-Priorisierung ab:
PATH = "/tmp/mock_bin : /usr/local/bin : /usr/bin : /bin"
│
├──> [1. Treffer: /tmp/mock_bin/docker] ──▶ Sofortige Simulation (healthy / 0ms)
└──> [2. Ignoriert: /usr/bin/docker]
│
├──> [1. Treffer: /tmp/mock_bin/docker] ──▶ Sofortige Simulation (healthy / 0ms)
└──> [2. Ignoriert: /usr/bin/docker]
🎬 Didaktische Analogie: Das Film-Stunt-Double
Ein Mock ist wie ein Stunt-Double am Filmset: Statt den echten Hauptdarsteller (teure Cloud-API oder Produktions-Datenbank) in gefährliche Szenen zu schicken, springt ein kostengünstiger Dummy ein, der genau die erwartete Reaktion liefert.
📑 3. Cheat-Sheet: BATS Assertions & Runner
| BATS Konstrukt | Bedeutung | Beispiel |
|---|---|---|
@test "name" { ... } |
Definiert einen isolierten Testfall | @test "Exit code is 0" { ... } |
run <command> |
Führt Befehl aus & erfasst Status/Output | run ./script.sh |
$status |
Exit-Code des letzten run |
[ "$status" -eq 0 ] |
$output |
Gesamte Textausgabe von stdout & stderr | [[ "$output" =~ "Success" ]] |
${lines[0]} |
Erste Zeile des Ausgabestroms | [ "${lines[0]}" = "OK" ] |
🧠Diagnostischer Selbst-Check
Überprüfe dein Verständnis der Kernkonzepte und typischen CLI-/Git-Fallen, bevor du die Kommandos in der Praxis anwendest.