Testen von Bash-Scripts mit Jenkins
Dez. 8, 2020
--
Bash Scripts Testing 656x400

Testen von Bash-Scripts mit Jenkins

Bei Magnolia verwenden wir Jenkins und AWS EC2-Instanzen, um unsere Builds auszuführen. Meistens verwenden wir Maven-Builds, die JUnit 4/5 sowohl für Unit- als auch für IT/UI-Tests nutzen. Für letztere verwenden wir auch Docker und Selenium, um Instanzen zu starten und Testszenarien auszuführen.

Bevor wir diese Instanzen verwenden können, müssen sie Dienstprogramme, Einstellungen und einige Bash-Skripte herunterladen. Wir nennen diese Skripte die "aws-build-scripts". Sie sind für unseren Entwicklungs-Workflow von entscheidender Bedeutung und müssen den Best Practices für die Entwicklung entsprechen. Aus diesem Grund müssen wir sie validieren. Im heutigen Blog erfahren Sie, wie wir eine Testsuite mit einem minimalistischen Setup erstellt haben.

Evaluierung von Test-Frameworks

Sicherlich gibt es spezielle Bibliotheken wie shUnit2 oder Bats. Das sind die Lösungen, auf die wir sofort gestoßen sind. Aber in unserem Anwendungsfall ging es nur darum, die Stabilität unserer Builds zu verbessern. Die Investition in eine Bibliothek eines Drittanbieters hätte die Einrichtung kompliziert gemacht, so schön das auch gewesen wäre. Außerdem wäre es für einen Kollegen schwieriger geworden, ein Problem ohne Vorkenntnisse dieser Frameworks zu lösen. Wir haben uns entschieden, dass es das nicht wert ist.

Magnolia Features

Magnolia allows you to manage all your content and media in one place, and create personalized experiences across multiple channels. See an overview of key capabilities and benefits.

Definition einer einfachen Testkonvention

Wir haben nichts unternommen, bis wir auf Probleme stießen, die wir nicht einfach erklären konnten. In diesem Moment wurde uns klar, dass wir eine Art Test brauchen, der bei jeder Änderung ausgelöst wird. Wir dachten: "Warte, wir sind nur eine Jenkins-Datei davon entfernt!" Da Jenkins automatisch unsere Bitbucket-Repositories durchsucht, können wir es zur Lösung unseres Problems einsetzen. Wir brauchten Jenkins in diesem Fall nicht, um irgendetwas zu bauen, aber wir konnten es verwenden, um Tests auszuführen.

Dann haben wir uns eine Jenkinsfile-Konvention ausgedacht, um einfache Tests durchzuführen:

Java
  stage('NAME_OF_THE_BASH_FILE') { stages { stage('FIRST_TEST_DESCRIPTION') { steps { script { // GIVEN // hier ist es möglich, den Vorzustand des Tests einzurichten und zu bewerten, zum Beispiel: sh "docker volume create test-volume" def volumes = callSh("docker volume ls --filter 'dangling=true'") assert volumes.contains("test-volume") // WHEN sh "./NAME_OF_THE_BASH_FILE" // THEN // wrap up the test, for instance: volumes = callSh("docker volume ls --filter 'dangling=true'") assert !volumes.contains("test-volume") } } } stage('SECOND_TEST_DESCRIPTION') { ... } } }  

callSh() stammt aus einer Datei namens callSh.groovy, die den folgenden Inhalt hat:

Java
  def call(command) { return sh(script: command, returnStdout: true).trim() }  

Um zum Beispiel alle Docker-Volumes für den nächsten Build zu bereinigen und zu entfernen, führen wir diesen Test aus:

Java
  stage('Entfernt baumelnde Volumes') { steps { script { // GIVEN sh "docker volume create test-volume" def volumes = callSh("docker volume ls --filter 'dangling=true'") assert volumes.contains("test-volume") // WHEN sh "./docker-clean-up.sh" // THEN volumes = callSh("docker volume ls --filter 'dangling=true'") assert !volumes.contains("test-volume") } } }  

Die 'GIVEN, WHEN, THEN'-Konvention und die Groovy (Java)-Syntax machen es allen unseren Entwicklern leicht, sich mit der Testsuite vertraut zu machen.

Der Anwendungsfall kann sogar erweitert werden, wenn andere Funktionen von Jenkins-Pipelines genutzt werden. Beispielsweise können Tests mit der when-Klausel wie folgt optional gemacht werden:

Java
  stage('Leaves already mounted volume') { when { expression { return callSh("df").contains("/home/ubuntu/ec2") } } ...  

Das war's: Ein gelungenes Beispiel für einfaches Testen von Bash-Skripten. Sie können sich die vollständige Test-Suite hier ansehen. Viel Spaß beim Nachmachen oder beim Anpassen an Ihre Bedürfnisse!

Über den autor

Maxime Michel

Site Reliability Engineer, Magnolia

Half developer, half Site Reliability Engineer (SRE), Maxime contributes to Magnolia’s source code and works closely with the wider product development team. He believes that machines can take care of repetitive tasks so that people can focus on more creative and interesting work. In his role at Magnolia, Maxime is responsible for processes and automation to present our users with a simple solution and a great user experience.