GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — java/docs/developing_de.md at java25 · cloudogu/java

Expand file tree

/

developing_de.md

Copy path
More file actions
More file actions

Latest commit

 

History

History
History
77 lines (55 loc) · 2.47 KB
/

developing_de.md

Copy path

File metadata and controls

77 lines (55 loc) · 2.47 KB
Raw
Copy raw file
Download raw file
Outline
Edit and raw actions

Entwicklung des Cloudogu EcoSystem Alpine Base Image

Shell-Tests mit BATS

Sie können Bash-Tests im Verzeichnis unitTests erstellen und ändern. Das Make-Target unit-test-shell unterstützt Sie mit einer verallgemeinerten Bash-Testumgebung.

make unit-test-shell

BATS ist so konfiguriert, dass es JUnit-kompatible Berichte in target/shell_test_reports/ hinterlässt.

Um testbare Shell-Skripte zu schreiben, sollten diese Aspekte beachtet werden:

Allgemeine Struktur von Skripten-unter-Tests

Es ist eher unüblich, ein Script-under-test wie startup.sh ganz alleine auszuführen. Effektive Unit-Tests werden höchstwahrscheinlich zu einem Albtraum, wenn keine angemessene Skriptstruktur vorhanden ist. Da diese Skripte sich gegenseitig quellen und Code ausführen, muss alles vorher eingerichtet werden: globale Variablen, Mocks von jedem einzelnen aufgerufenen Binary... und so weiter. Letztendlich würden die Tests eher auf einer End-to-End-Testebene als auf einer Unit-Test-Ebene stattfinden.

Die gute Nachricht ist, dass das Testen einzelner Funktionen mit diesen kleinen Teilen möglich ist:

  1. Sourcing-Ausführungsgarantien verwenden
  2. Führen Sie Binärdateien und logischen Code nur innerhalb von Funktionen aus
  3. Sourcen mit (dynamischen, aber fixierten) Umgebungsvariablen

Sourcing-Ausführungsgarantien verwenden

Ermöglichen Sie Sourcing mit sourcing execution guards wie diesem:

# yourscript.sh
function runTheThing() {
    echo "hello world"
}

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
  runTheThing
fi

Die folgende if-Bedingung wird ausgeführt, wenn das Skript durch einen Aufruf über die Shell ausgeführt wird, aber nicht, wenn es von einer Quelle kommt:

$ ./yourscript.sh
hello world
$ source yourscript.sh
$ runTheThing
hello world
$

Sourcing Execution Guards funktionieren auch mit Parametern:

# yourscript.sh
function runTheThing() {
    echo "${1} ${2}"
}

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
  runTheThingWithParameters "$@"
fi

Man beachte die korrekte Argumentübergabe mit "$@", die auch Argumente mit Leerzeichen und dergleichen zulässt.

$ ./yourscript.sh hello world
hello world
$ source yourscript.sh
$ runTheThing hello bash
hello bash
$

Binärdateien und Logikcode nur innerhalb von Funktionen ausführen

Umgebungsvariablen und Konstanten sind in Ordnung, aber sobald Logik außerhalb einer Funktion läuft, wird sie während des Skript-Sourcings ausgeführt.

You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.