0Pricing
Linux Command Line & Bash Scripting Mastery · Lektion

Fixtures, temporäre Umgebungen und Coverage

Erstellen Sie isolierte Test-Fixtures und messen Sie, welche Zweige Ihrer Skripte von den Tests tatsächlich ausgeführt werden.

Fixtures, temporäre Umgebungen und Coverage ist eine kostenlose Linux Command Line & Bash Scripting Mastery-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Linux Command Line & Bash Scripting Mastery-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Linux Command Line & Bash Scripting Mastery-Kurs umfasst insgesamt 4 Lektionen.

Warum Fixtures und Isolation wichtig sind

Beim Testen von Bash-Skripten besteht das größte Risiko in Seiteneffekten: Ihre Tests verändern versehentlich echte Dateien, echte Datenbanken oder den tatsächlichen Systemzustand. Ein Test, der auf Ihrem Rechner erfolgreich ist, aber Produktionsdaten beschädigt, ist schlimmer als gar kein Test.

Die Lösung sind Test-Fixtures – kontrollierte, verwerfbare Umgebungen, die reale Bedingungen nachbilden, ohne etwas Echtes anzutasten. Gute Fixtures bieten:

  • Reproduzierbarkeit – Tests liefern bei jedem Durchlauf dasselbe Ergebnis
  • Isolation – Tests beeinflussen sich weder gegenseitig noch das Hostsystem
  • Sicherheit – destruktive Operationen greifen nur auf wegwerfbare Daten zu
  • Geschwindigkeit – keine Netzwerkaufrufe und keine umfangreichen I/O-Operationen, sofern sie nicht unbedingt erforderlich sind

Beim Testen von Bash bestehen Fixtures typischerweise aus temporären Verzeichnissen mit bekannten Dateien, Mock-Executables, die am Anfang von $PATH stehen, und Umgebungsvariablen, die auf den Testprozess beschränkt sind.

Temporäre Verzeichnisse erstellen und bereinigen

Das Standardmuster für ein temporäres Verzeichnis pro Test verwendet mktemp -d. Dieser Befehl erstellt ein eindeutiges Verzeichnis in /tmp und gibt dessen Pfad aus. Sie speichern den Pfad und registrieren einen trap, der das Verzeichnis beim Beenden der Shell automatisch entfernt – auch im Fehlerfall.

Dieses aus zwei Zeilen bestehende Idiom sollte in jeder Testdatei vorkommen, die auf das Dateisystem zugreift:

#!/usr/bin/env bash
set -euo pipefail

# Create an isolated temp directory
TMPDIR=$(mktemp -d)
# Always clean up, even if the script exits early or errors out
trap 'rm -rf "$TMPDIR"' EXIT

echo "Working in: $TMPDIR"

# Simulate creating fixture files
mkdir -p "$TMPDIR/project/{src,tests,logs}"
echo 'version=1.2.3' > "$TMPDIR/project/.env"
echo 'Hello fixture' > "$TMPDIR/project/src/main.sh"

ls -R "$TMPDIR/project"
echo 'Temp dir will be removed automatically on exit'

Eine Fixture-Verzeichnisstruktur aufbauen

Eine gut strukturierte Fixture bildet die Verzeichnisstruktur nach, die Ihr getestetes Skript tatsächlich erwartet. Betrachten Sie sie als kleine Nachbildung der Projektwurzel. Die Fixture-Einrichtungsfunktion erstellt diese Struktur vor jedem Test, und das Teardown entfernt sie.

Wichtige Vorgehensweisen:

  • Verwenden Sie eine setup()-Funktion, die Ihr Test-Framework vor jedem Test aufruft
  • Verwenden Sie eine teardown()- oder cleanup()-Funktion, die nach jedem Test ausgeführt wird, auch im Fehlerfall
  • Halten Sie Fixture-Dateien minimal – verwenden Sie nur Dateien, die das Skript tatsächlich einliest
  • Benennen Sie Fixture-Dateien aussagekräftig, damit Fehler leicht zu diagnostizieren sind
#!/usr/bin/env bash
# fixture_helpers.bash — source this from your test files

FIXTURE_ROOT=''

setup_fixture() {
  FIXTURE_ROOT=$(mktemp -d)
  # Build the directory tree the deploy script expects
  mkdir -p "$FIXTURE_ROOT"/{dist,config,logs}
  echo '{"version":"2.0"}' > "$FIXTURE_ROOT/config/app.json"
  echo 'console.log("app")' > "$FIXTURE_ROOT/dist/index.js"
  touch "$FIXTURE_ROOT/logs/.gitkeep"
  export FIXTURE_ROOT
  echo "[setup] Fixture ready at $FIXTURE_ROOT"
}

teardown_fixture() {
  if [[ -n "$FIXTURE_ROOT" && -d "$FIXTURE_ROOT" ]]; then
    rm -rf "$FIXTURE_ROOT"
    echo '[teardown] Fixture removed'
  fi
}

# Self-test
setup_fixture
ls "$FIXTURE_ROOT"
teardown_fixture

Executables mit einem gefälschten PATH mocken

Viele Bash-Skripte rufen externe Tools wie curl, aws, docker oder git auf. In Tests möchten Sie keine echten Dienste aufrufen, daher ersetzen Sie diese Tools durch gefälschte Executables.

Die Vorgehensweise ist einfach:

  1. Erstellen Sie innerhalb Ihrer Fixture ein temporäres Verzeichnis bin/
  2. Schreiben Sie dort kleine Shell-Skripte mit denselben Namen wie die echten Tools
  3. Stellen Sie dieses Verzeichnis vor dem Aufruf Ihres getesteten Skripts an den Anfang von $PATH

Da $PATH von links nach rechts durchsucht wird, hat der Fake Vorrang. Die echte Binärdatei wird niemals aufgerufen.

#!/usr/bin/env bash
set -euo pipefail

FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT

# Create a fake 'curl' that records calls and returns canned data
FAKE_BIN="$FIXTURE/bin"
mkdir -p "$FAKE_BIN"

cat > "$FAKE_BIN/curl" << 'SCRIPT'
#!/usr/bin/env bash
# Log every argument for later inspection
echo "curl $*" >> "$FIXTURE_BIN_LOG"
# Return a canned HTTP 200 response body
echo '{"status":"ok","id":42}'
SCRIPT
chmod +x "$FAKE_BIN/curl"

# Export the log path so the fake can find it
export FIXTURE_BIN_LOG="$FIXTURE/curl_calls.log"

# Prepend fake bin directory to PATH
export PATH="$FAKE_BIN:$PATH"

# Now any call to 'curl' hits our fake
curl -s https://api.example.com/health
curl -X POST https://api.example.com/deploy

echo '--- Recorded curl calls ---'
cat "$FIXTURE_BIN_LOG"

Befehlsausgaben erfassen und überprüfen

Eine Fixture ist nur dann nützlich, wenn Sie überprüfen können, was Ihr Skript getan hat. Die gängigen Muster sind:

  • Erfassen Sie stdout/stderr mit $() oder einer Prozesssubstitution in Variablen
  • Untersuchen Sie Protokolldateien, die von Fake-Binärdateien geschrieben wurden
  • Prüfen Sie Exit-Codes explizit mit $? oder bedingter Logik
  • Überprüfen Sie, ob bestimmte Dateien erstellt, geändert oder unverändert gelassen wurden

Wenn Sie kleine, fokussierte Hilfsfunktionen für Überprüfungen schreiben, werden Ihre Tests übersichtlich und liefern bei Fehlern präzise Fehlermeldungen.

#!/usr/bin/env bash
set -euo pipefail

# Minimal assertion helpers
assert_eq() {
  local desc="$1" expected="$2" actual="$3"
  if [[ "$expected" == "$actual" ]]; then
    echo "PASS: $desc"
  else
    echo "FAIL: $desc"
    echo "  expected: $expected"
    echo "  actual:   $actual"
    return 1
  fi
}

assert_file_exists() {
  local desc="$1" file="$2"
  if [[ -f "$file" ]]; then
    echo "PASS: $desc"
  else
    echo "FAIL: $desc — file not found: $file"
    return 1
  fi
}

assert_contains() {
  local desc="$1" needle="$2" haystack="$3"
  if [[ "$haystack" == *"$needle"* ]]; then
    echo "PASS: $desc"
  else
    echo "FAIL: $desc — '$needle' not found in output"
    return 1
  fi
}

# Demo usage
TMPDIR=$(mktemp -d)
trap 'rm -rf "$TMPDIR"' EXIT
echo 'hello world' > "$TMPDIR/greeting.txt"
OUT=$(cat "$TMPDIR/greeting.txt")
assert_eq   'file content matches'     'hello world' "$OUT"
assert_file_exists 'greeting file created' "$TMPDIR/greeting.txt"
assert_contains    'output has hello'     'hello'       "$OUT"

Gültigkeitsbereich von Umgebungsvariablen in Tests

Skripte lesen häufig Umgebungsvariablen wie $HOME, $CONFIG_PATH oder $DATABASE_URL ein. In Tests müssen Sie diese überschreiben, ohne die echte Umgebung zu verunreinigen.

Am sichersten führen Sie das getestete Skript in einer Subshell aus, in der nur die Variablen gesetzt sind, die Sie ausdrücklich festlegen. Mit dem Befehl env können Sie die Umgebung bereinigen und nur die benötigten Variablen wieder hinzufügen:

  • env -i VAR=val ./script.sh – vollständig bereinigte Umgebung
  • (export VAR=val; ./script.sh) – Subshell übernimmt die übergeordnete Umgebung und zusätzlich Ihre Überschreibungen

Durch die Verwendung von Subshells gelangen Änderungen des Skripts an $IFS, $PWD oder einem anderen globalen Zustand außerdem niemals zurück in Ihren Test-Runner.

#!/usr/bin/env bash
set -euo pipefail

FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT

# Write a tiny script under test that reads env vars
cat > "$FIXTURE/deploy.sh" << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
ENV_NAME=${DEPLOY_ENV:-unknown}
CFG=${CONFIG_DIR:-/etc/app}
echo "Deploying to $ENV_NAME using config from $CFG"
SCRIPT
chmod +x "$FIXTURE/deploy.sh"

echo '--- Test 1: staging env ---'
# Run in a clean subshell with explicit vars
(
  export DEPLOY_ENV=staging
  export CONFIG_DIR="$FIXTURE/config"
  "$FIXTURE/deploy.sh"
)

echo '--- Test 2: production env ---'
(
  export DEPLOY_ENV=production
  export CONFIG_DIR=/etc/prod-config
  "$FIXTURE/deploy.sh"
)

echo '--- Test 3: defaults ---'
# No env vars set — script should use its own defaults
env -i PATH="$PATH" "$FIXTURE/deploy.sh"

Einführung in kcov für Bash-Coverage

Coverage beantwortet die Frage: Welche Zeilen (und Verzweigungen) meines Skripts haben die Tests tatsächlich ausgeführt? Ein hoher Coverage-Wert garantiert keine Korrektheit, aber ein niedriger Wert zeigt nicht getestete Pfade auf, in denen sich wahrscheinlich Fehler verbergen.

Das wichtigste Tool für Bash-Coverage ist kcov. Es instrumentiert das Skript auf Betriebssystemebene mit PTRACE (Linux) oder dtrace (macOS) und erfordert daher keine Änderungen an Ihrem Quellcode. Es erstellt einen HTML-Bericht mit roten (nicht abgedeckten) und grünen (abgedeckten) Zeilen.

Grundlegende Verwendung:

  • kcov --include-path=./src coverage-out/ ./src/myscript.sh
  • Öffnen Sie coverage-out/index.html in einem Browser, um die Ergebnisse zu untersuchen
  • Analysieren Sie in der CI-Datei coverage-out/myscript.sh/coverage.json, um einen maschinenlesbaren Prozentsatz zu erhalten

Hinweis: kcov muss separat installiert werden (brew install kcov unter macOS, apt install kcov unter Ubuntu 20.04+).

kcov auf ein echtes Skript anwenden

Hier sehen Sie ein durchgängiges Beispiel mit einem bereitstellbaren Skript, einem Test, der es ausführt, und dem kcov-Aufruf zur Messung der Coverage. Beachten Sie, dass das Ausgabeverzeichnis pro Test angelegt wird, damit Sie die Ergebnisse später aus mehreren Testläufen zusammenführen können.

#!/usr/bin/env bash
# This demo shows the *structure* of a kcov workflow.
# It will not run kcov itself (not guaranteed to be installed),
# but the script under test and test runner are fully runnable.
set -euo pipefail

FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT

# 1. Script under test
cat > "$FIXTURE/process.sh" << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
INPUT="$1"
if [[ ! -f "$INPUT" ]]; then
  echo "ERROR: file not found" >&2
  exit 1
fi
LINE_COUNT=$(wc -l < "$INPUT")
if (( LINE_COUNT == 0 )); then
  echo "WARNING: file is empty"
else
  echo "Processed $LINE_COUNT lines"
fi
SCRIPT
chmod +x "$FIXTURE/process.sh"

# 2. Happy path test (exercises line 6 and 11)
echo -e 'one\ntwo\nthree' > "$FIXTURE/data.txt"
OUT=$("$FIXTURE/process.sh" "$FIXTURE/data.txt")
echo "Happy path: $OUT"

# 3. Empty file test (exercises line 9)
touch "$FIXTURE/empty.txt"
OUT=$("$FIXTURE/process.sh" "$FIXTURE/empty.txt")
echo "Empty file: $OUT"

# 4. Missing file test (exercises line 5-6)
if ! OUT=$("$FIXTURE/process.sh" "$FIXTURE/missing.txt" 2>&1); then
  echo "Missing file (expected error): $OUT"
fi

# To measure coverage, wrap each call with kcov:
# kcov --include-path="$FIXTURE" "$FIXTURE/cov/happy" "$FIXTURE/process.sh" ...
# kcov --merge "$FIXTURE/cov/all" "$FIXTURE/cov/happy" "$FIXTURE/cov/empty"

Coverage aus mehreren Testläufen zusammenführen

Ein einzelner Test deckt nur selten alle Verzweigungen ab. Sie führen mehrere Tests aus – jeden in einem eigenen Coverage-Ausgabeverzeichnis – und führen sie anschließend zusammen. Das --merge-Flag von kcov kombiniert mehrere Durchläufe zu einem einheitlichen Bericht.

Das typische Muster in einer CI-Pipeline:

  • Test A ausführen → Ausgabe nach cov/test_a/
  • Test B ausführen → Ausgabe nach cov/test_b/
  • Zusammenführen → kcov --merge cov/all/ cov/test_a/ cov/test_b/
  • cov/all/<script>/coverage.json analysieren, um den endgültigen Prozentsatz zu erhalten

Sie können außerdem einen Mindestschwellwert festlegen und den CI-Build fehlschlagen lassen, wenn die Coverage darunter fällt:

#!/usr/bin/env bash
# extract_coverage.sh — parse kcov JSON and fail below threshold
set -euo pipefail

MIN_COVERAGE=80   # percent
COV_JSON="${1:-coverage-out/myscript.sh/coverage.json}"

if [[ ! -f "$COV_JSON" ]]; then
  echo "ERROR: coverage JSON not found at $COV_JSON" >&2
  exit 1
fi

# kcov JSON contains a key like: "percent_covered": "87.50"
PERCENT=$(grep -oP '"percent_covered":\s*"\K[0-9.]+' "$COV_JSON")
PERCENT_INT=${PERCENT%%.*}   # truncate decimal

echo "Coverage: ${PERCENT}%  (minimum: ${MIN_COVERAGE}%)"

if (( PERCENT_INT < MIN_COVERAGE )); then
  echo "FAIL: coverage ${PERCENT}% is below threshold ${MIN_COVERAGE}%" >&2
  exit 1
fi

echo "PASS: coverage threshold met"

Branch-Coverage im Vergleich zu Line-Coverage

Es gibt zwei wichtige Coverage-Metriken, denen Sie begegnen werden:

  • Line-Coverage – wurde diese Zeile überhaupt ausgeführt? Leicht zu manipulieren: Ein einzelner Test kann viele Zeilen berühren und dabei wichtige bedingte Pfade auslassen.
  • Branch-Coverage – wurde jeder Zweig jedes if, case und jeder Ausdruck mit &&/|| durchlaufen? Dies ist ein deutlich aussagekräftigeres Signal. Dafür sind Tests sowohl für die wahre als auch für die falsche Seite jeder Entscheidung erforderlich.

kcov meldet beide Werte. Die entscheidende Erkenntnis: 100 % Line-Coverage bedeuten nicht automatisch 100 % Branch-Coverage. Betrachten Sie dieses Skript: Ein einzelner Test mit einer nicht leeren Datei deckt jede Zeile ab, aber der Zweig für eine leere Datei (unten Zeile 9) wird nie erreicht:

#!/usr/bin/env bash
# Illustrates line vs branch coverage gap
set -euo pipefail

check_file() {
  local f="$1"
  if [[ -f "$f" ]]; then        # branch A (true) OR branch B (false)
    local lines
    lines=$(wc -l < "$f")
    if (( lines > 0 )); then    # branch C (true) OR branch D (false)
      echo "File has $lines lines"
    else
      echo "File is empty"     # branch D — unreached if only tested with non-empty file
    fi
  else
    echo "File missing"        # branch B — unreached if only tested with existing file
  fi
}

# Only one test: covers lines 5-10 (4 of 6 branches)
TMPDIR=$(mktemp -d)
trap 'rm -rf "$TMPDIR"' EXIT
echo 'data' > "$TMPDIR/sample.txt"
check_file "$TMPDIR/sample.txt"

# To reach 100% branch coverage you also need:
# check_file "/nonexistent/path"
# check_file "$TMPDIR/empty.txt" (after: touch "$TMPDIR/empty.txt")

Fixtures und Codeabdeckung in CI

Alles zusammengeführt: Eine robuste CI-Pipeline für Bash-Projekte kombiniert das Einrichten der Fixtures, die Testausführung unter kcov, das Zusammenführen der Ergebnisse und die Prüfung eines Schwellenwerts in einem einzigen Skript. Dieses Skript wird zum CI-Einstiegspunkt – ein Befehl, um alles auszuführen.

Entwurfsprinzipien für den CI-Test-Runner:

  • Jeder Testfall ruft setup_fixture auf und registriert über trap teardown_fixture
  • Das zu testende Skript wird mit einem gefälschten $PATH und lokal begrenzten Umgebungsvariablen aufgerufen
  • kcov umschließt jeden Aufruf und schreibt die Ergebnisse in ein nummeriertes Unterverzeichnis
  • Nach allen Tests führt kcov die Ergebnisse zusammen, und das Schwellenwertskript entscheidet, ob der Build zugelassen wird
  • Der CI-Runner wird mit einem Fehlercode ungleich null beendet, wenn ein Test oder die Prüfung der Codeabdeckung fehlschlägt
#!/usr/bin/env bash
# ci_runner.sh — full fixture + coverage pipeline entry point
set -euo pipefail

SRC="./src/deploy.sh"
COV_ROOT="$(mktemp -d)/coverage"
trap 'rm -rf "$COV_ROOT"' EXIT
mkdir -p "$COV_ROOT"

PASS=0
FAIL=0
RUN_NUM=0

run_test() {
  local name="$1" test_fn="$2"
  local fixture
  fixture=$(mktemp -d)
  local cov_out="$COV_ROOT/run_$((++RUN_NUM))"

  if (
    trap 'rm -rf "$fixture"' EXIT
    export FIXTURE="$fixture"
    # Fake bin directory shadowing real tools
    mkdir -p "$fixture/bin"
    export PATH="$fixture/bin:$PATH"
    "$test_fn" "$fixture"
  ); then
    echo "PASS: $name"
    (( PASS++ )) || true
  else
    echo "FAIL: $name"
    (( FAIL++ )) || true
  fi
}

# Example test function
test_happy_path() {
  local fx="$1"
  mkdir -p "$fx/dist"
  echo 'app.js' > "$fx/dist/index.js"
  # Would normally run: kcov "$cov_out" "$SRC" --env=staging "$fx"
  echo "[test] happy path executed in $fx"
}

run_test 'happy_path' test_happy_path

echo "Results: $PASS passed, $FAIL failed"
(( FAIL == 0 ))

Wissenscheck: Die Technik mit dem gefälschten PATH

Testen Sie Ihr Verständnis der Technik mit dem gefälschten PATH, die in Bash-Test-Fixtures verwendet wird.

Rückblick: Fixtures, temporäre Umgebungen und Codeabdeckung

In dieser Lektion haben Sie das vollständige Werkzeugset für zuverlässige, isolierte Bash-Tests kennengelernt:

  • Temporäre Verzeichnisse – mktemp -d zusammen mit einem trap ... EXIT stellt die automatische Bereinigung sicher, unabhängig davon, wie der Test endet.
  • Fixture-Struktur – Ein Paar aus setup_fixture und teardown_fixture erstellt und löscht eine minimale Verzeichnisstruktur, die die tatsächlichen Eingaben von Skripten nachbildet.
  • Gefälschter PATH – Platzieren Sie Stub-Executables in $FIXTURE/bin/ und stellen Sie dieses Verzeichnis $PATH voran, um Aufrufe von curl, aws, docker oder anderen externen Tools abzufangen, ohne System-Binaries zu verändern.
  • Begrenzung des Gültigkeitsbereichs von Umgebungsvariablen – Führen Sie das zu testende Skript in einer Subshell (() oder env -i) aus, damit geänderte Variablen nicht an den Test-Runner zurückgegeben werden.
  • Assertions – Kleine Hilfsfunktionen (assert_eq, assert_file_exists, assert_contains) erzeugen eine klare Erfolgs-/Fehlerausgabe und aussagekräftige Fehlermeldungen.
  • kcov-Codeabdeckung – Umschließt die Skriptausführung, ohne Änderungen am Quellcode zu erfordern, und erzeugt HTML- und JSON-Berichte zur Zeilen- und Branch-Abdeckung.
  • Zusammenführen und Schwellenwert – Führen Sie mehrere kcov-Ausführungen mit --merge zusammen, analysieren Sie das JSON und lassen Sie CI fehlschlagen, wenn die Codeabdeckung unter das festgelegte Minimum sinkt.
  • Branch- gegenüber Zeilenabdeckung – Richten Sie sich immer auf die Branch-Abdeckung aus. Die Zeilenabdeckung allein kann ganze bedingte Pfade übersehen und ein trügerisches Sicherheitsgefühl vermitteln.

Mit diesen Techniken werden Ihre Bash-Tests genauso gründlich wie Tests für jede kompilierte Sprache.

Häufig gestellte Fragen

Ist die Lektion „Fixtures, temporäre Umgebungen und Coverage“ kostenlos?

Ja — der vollständige Text von „Fixtures, temporäre Umgebungen und Coverage“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Linux Command Line & Bash Scripting Mastery-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Linux Command Line & Bash Scripting Mastery-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Fixtures, temporäre Umgebungen und Coverage“?

Erstellen Sie isolierte Test-Fixtures und messen Sie, welche Zweige Ihrer Skripte von den Tests tatsächlich ausgeführt werden. Du übst Linux Command Line & Bash Scripting Mastery mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Linux Command Line & Bash Scripting Mastery zu starten?

Keine Vorkenntnisse erforderlich. Linux Command Line & Bash Scripting Mastery auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.

Wie lange dauert die Lektion „Fixtures, temporäre Umgebungen und Coverage“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Linux Command Line & Bash Scripting Mastery-Lektion Code schreiben und ausführen?

Ja. Jede Linux Command Line & Bash Scripting Mastery-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Funktionen mit Bats-core per Unit-Test prüfen
  2. Befehle mocken und externe Tools stubben
  3. Fixtures, temporäre Umgebungen und Coverage
  4. Shell-Tests in CI-Pipelines ausführen
← Zurück zu Linux Command Line & Bash Scripting Mastery