shUnit2 vs. bats: Welches Test-Framework für welches Bash-Projekt

1. Zwei grundverschiedene Philosophien für dasselbe Problem

Sowohl shUnit2 als auch bats-core lösen dasselbe Grundproblem: Bash-Skripte automatisiert und wiederholbar testen, statt sie nur manuell auszuführen und die Ausgabe mit dem Auge zu prüfen. Die Herangehensweise unterscheidet sich aber grundlegend. shUnit2 orientiert sich am klassischen xUnit-Muster, das aus JUnit, PHPUnit und ähnlichen Frameworks bekannt ist: Testfunktionen mit dem Präfix test, Assertion-Funktionen wie assertEquals, und optionale setUp/tearDown-Hooks.

bats-core (Bash Automated Testing System) geht einen anderen Weg und erweitert Bash selbst um eine @test-Syntax, die jeden Test als eigenständigen, lesbaren Block mit einer beschreibenden Zeichenkette definiert. Das Ergebnis liest sich eher wie eine Spezifikation im BDD-Stil (Behavior Driven Development) als wie klassischer xUnit-Code, was gerade für Teams mit Erfahrung in RSpec, Jest oder ähnlichen BDD-Frameworks vertraut wirkt.

2. shUnit2 in der Praxis: Assertion-Funktionen und xUnit-Struktur

Ein shUnit2-Test ist eine ganz normale Bash-Funktion, deren Name mit test beginnt. Innerhalb der Funktion prüfen Assertion-Funktionen wie assertEquals, assertTrue oder assertNotNull das erwartete Verhalten und melden bei einer Abweichung einen Fehler mit Zeilennummer und erwartetem gegen tatsächlichem Wert. Am Ende der Testdatei bindet ein einziger source-Aufruf auf shunit2 den eigentlichen Test-Runner ein, der automatisch alle test*-Funktionen findet und ausführt.

Dieser Aufbau ist besonders vertraut für Teams, die bereits mit PHPUnit, JUnit oder ähnlichen Frameworks in anderen Sprachen arbeiten, weil sich Testfälle, Assertions und Setup/Teardown nahezu eins zu eins übertragen lassen. shUnit2 selbst ist reines POSIX-Shell-kompatibles Bash, was es zusätzlich zu einer robusten Wahl macht, wenn Skripte nicht nur unter Bash, sondern auch unter dash oder anderen POSIX-Shells laufen sollen.

#!/usr/bin/env bash
# test_deploy_helpers.sh -- shUnit2 style

source ./deploy_helpers.sh

setUp() {
  export DEPLOY_ENV="staging"
}

testNormalizeVersionStripsLeadingV() {
  result="$(normalize_version "v1.2.3")"
  assertEquals "1.2.3" "$result"
}

testIsProductionReturnsFalseForStaging() {
  assertFalse "is_production"
}

# Must be the last line: pulls in the shUnit2 runner
source ./shunit2

3. bats-core in der Praxis: @test-Blöcke und der run-Helper

Ein bats-Test besteht aus einer .bats-Datei mit einem oder mehreren @test "beschreibung" { ... }-Blöcken. Innerhalb eines Blocks steht ganz normaler Bash-Code, ergänzt um den eingebauten Helfer run, der ein Kommando ausführt und dessen Exit-Code sowie Ausgabe in den Variablen $status und $output verfügbar macht, ohne dass ein Testfehler den gesamten Testlauf sofort abbricht.

Statt eigener Assertion-Funktionen wie bei shUnit2 verlässt sich bats-core auf das eingebaute [[ ]] beziehungsweise die POSIX-Testfunktion [ ], kombiniert mit run, um Exit-Codes und Ausgaben zu prüfen. Zusätzliche Bibliotheken wie bats-assert und bats-support liefern optional lesbarere Assertion-Helfer wie assert_success oder assert_output, sind aber nicht Teil des Kerns.

#!/usr/bin/env bats
# test_deploy_helpers.bats -- bats-core style

setup() {
  load 'deploy_helpers.sh'
  export DEPLOY_ENV="staging"
}

@test "normalize_version strips a leading v" {
  run normalize_version "v1.2.3"
  [ "$status" -eq 0 ]
  [ "$output" = "1.2.3" ]
}

@test "is_production returns false for staging" {
  run is_production
  [ "$status" -ne 0 ]
}

4. Setup und Teardown: gemeinsame Muster, unterschiedliche Namen

Beide Frameworks bieten Hooks, die vor und nach jedem einzelnen Test ausgeführt werden, mit fast identischer Semantik, aber unterschiedlicher Benennung. shUnit2 verwendet die klassischen xUnit-Namen setUp und tearDown, bats-core die kleingeschriebenen setup und teardown. In beiden Fällen laufen diese Funktionen isoliert vor beziehungsweise nach jedem Testfall, sodass sich temporäre Verzeichnisse, Umgebungsvariablen oder Mock-Kommandos sauber pro Test aufbauen und wieder entfernen lassen.

Ein praktischer Unterschied zeigt sich bei dateiweiten Hooks: shUnit2 kennt zusätzlich oneTimeSetUp und oneTimeTearDown, die genau einmal pro Testdatei laufen, etwa um eine gemeinsame Testdatenbank aufzusetzen. bats-core bietet dafür setup_file und teardown_file, die dieselbe Aufgabe übernehmen, aber erst in neueren bats-core-Versionen verfügbar sind, was bei älteren Installationen berücksichtigt werden muss.

5. CI-Integration: Ausgabeformate und Pipeline-Einbindung

bats-core unterstützt von Haus aus mehrere maschinenlesbare Ausgabeformate, darunter TAP (Test Anything Protocol) und mit dem Flag --formatter junit auch JUnit-XML, das praktisch jedes CI-System, von GitLab CI über Jenkins bis GitHub Actions, direkt als Testreport visualisieren kann. Diese eingebaute Unterstützung reduziert den Integrationsaufwand erheblich, weil keine zusätzliche Konvertierung der Testergebnisse nötig ist.

shUnit2 gibt Testergebnisse standardmäßig als menschenlesbaren Text aus und bietet keine eingebaute JUnit-XML-Ausgabe. Für eine grafische CI-Integration braucht es entweder ein zusätzliches Wrapper-Skript, das die Textausgabe parst und in ein Standardformat übersetzt, oder man belässt es bei der reinen Exit-Code-Auswertung (0 für Erfolg, ungleich null für Fehler), was für viele CI-Pipelines bereits ausreicht, aber ohne detaillierte Testreports auskommt.

# .gitlab-ci.yml excerpt: bats-core with native JUnit output
test:bash:
  stage: test
  script:
    - bats --formatter junit test/*.bats > report.xml
  artifacts:
    reports:
      junit: report.xml

# shUnit2 fallback: rely on the exit code only
test:bash-shunit2:
  stage: test
  script:
    - ./test_deploy_helpers.sh

6. Installation und Abhängigkeiten: Einzeldatei vs. Paketmanager

shUnit2 besteht aus einer einzigen Shell-Datei, die sich direkt neben die Testdateien im Projekt legen oder als Git-Submodul einbinden lässt, ganz ohne externe Paketverwaltung. Das macht shUnit2 besonders portabel für Umgebungen ohne Internetzugang während der Testausführung oder für Legacy-Systeme, auf denen die Installation zusätzlicher Pakete eingeschränkt ist.

bats-core wird üblicherweise über einen Paketmanager installiert, etwa apt, brew oder npm, oder als Git-Submodul mit den optionalen Erweiterungen bats-support und bats-assert eingebunden. Diese Erweiterungen bringen deutlich lesbarere Fehlermeldungen bei fehlgeschlagenen Assertions mit, erhöhen aber auch die Zahl der externen Abhängigkeiten, die ein Projekt pflegen muss.

7. Kommandos mocken und externe Abhängigkeiten isolieren

Beide Frameworks erlauben, ein externes Kommando durch eine Bash-Funktion gleichen Namens zu überschreiben, was in beiden Fällen als einfache und effektive Mocking-Technik funktioniert, da Bash Funktionen vor PATH-Kommandos auflöst. Der Unterschied liegt im Ökosystem drumherum: bats-core-Projekte greifen häufig auf zusätzliche Libraries wie bats-mock zurück, die komplexere Aufruf-Zähler und Argument-Prüfungen mitbringen.

shUnit2-Projekte lösen dasselbe meist mit reinen Bash-Bordmitteln, etwa einer Zählvariable, die in der Mock-Funktion hochgezählt und im Test mit assertEquals geprüft wird. Für kleinere Testsuiten ist dieser Unterschied kaum spürbar, bei größeren Projekten mit vielen gemockten Abhängigkeiten sparen die bats-core-Erweiterungen jedoch spürbar Boilerplate-Code.

8. Wann shUnit2 die bessere Wahl ist, wann bats

shUnit2 passt gut in Umgebungen, die bereits POSIX-Shell-Kompatibilität pflegen, die Abhängigkeitsfreiheit priorisieren, oder in denen ein Team mit xUnit-Erfahrung aus anderen Sprachen schnell produktiv werden soll. Auch für sehr kleine Testsuiten mit wenigen Testdateien ist die Einzeldatei-Installation von shUnit2 oft der pragmatischere Einstieg ohne zusätzliche Werkzeugkette.

bats-core eignet sich besser für größere Projekte mit CI-Integration als festem Bestandteil des Workflows, für Teams, die einen BDD-Stil mit beschreibenden Testnamen bevorzugen, und überall dort, wo native JUnit-Reports die Testauswertung in der Pipeline erheblich vereinfachen. Die etwas höhere Einstiegshürde durch Paketmanager und optionale Erweiterungen zahlt sich bei wachsenden Testsuiten meist schnell aus.

9. shUnit2 und bats-core im direkten Vergleich

Beide Frameworks sind ausgereift, aktiv gepflegt und für produktive Bash-Testsuiten geeignet, unterscheiden sich aber deutlich in Syntax-Stil, Ausgabeformaten und Ökosystem. Die Entscheidung hängt weniger von technischen Einschränkungen ab, da beide die relevanten Grundfunktionen abdecken, sondern vor allem davon, welcher Stil zum Team und zur bestehenden Toolchain passt.

Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber und dient als schnelle Entscheidungshilfe für neue Bash-Projekte, die sich noch nicht auf ein Test-Framework festgelegt haben.

10. Zusammenfassung

11. FAQ: shUnit2 vs. bats: Das Wichtigste auf einen Blick