Jeder kennt und nutzt Git. Es gibt bis auf Ausnahmen (ich schaue dich an, Perforce) keine ernstzunehmenden Alternativen mehr.

Ich lasse Azubis ab der ersten Woche schon mit Git arbeiten, allerdings zunächst im Kontext einer IDE,
damit sie ihren Code entspannt versionieren können.

Im zweiten Lehrjahr gibt es dann den Blick hinter die Kulissen, also auf die Kommandozeile.

Inhalt

• Basics: Installation, Konfiguration, Repository erstellen, Status & Log, Commits, .gitignore, Remote, Fetch & Pull
• Intermediate: Branching, Merging, Merge-Konflikte, Stash, Diff, Tags
• Advanced: Rebase, Squashen von Commits, Cherry-Pick, Reflog, Bisect

Voraussetzungen

• Ein Terminal / eine Shell (bash, zsh, PowerShell, …)
• Grundlegende Erfahrung mit der Kommandozeile (cd, mkdir, ls/dir)
• Optional: ein GitHub- oder GitLab-Account für Remote-Repositories

Basics

Installation

Damit etwas unter Versionskontrolle gestellt werden kann, muss Git zuerst installiert sein.

Windows:

Download von https://git-scm.com/download/win und Installer ausführen

Linux (Debian/Ubuntu):

sudo apt install git

macOS:

brew install git

Wir können nun testen, ob die Installation erfolgreich war:

git --version

Konfiguration

Bevor wir loslegen, teilen wir Git unseren Namen und unsere E-Mail-Adresse mit.
Diese Infos werden in jedem Commit gespeichert.

git config --global user.name "Dein Name"
git config --global user.email "deine@email.de"

Optional – Standardbranch auf main setzen:

git config --global init.defaultBranch main

Repository erstellen (init)

mkdir my_workspace
cd my_workspace
git init

Damit haben wir ein leeres Git-Repository. Jetzt legen wir die ersten Dateien an:

touch .gitignore
touch README.md
touch app.py

Status & Log

Zwei Befehle, die man ständig braucht sind:

git status # Zeigt den aktuellen Zustand des Repositories
git log # Zeigt die Commit-Historie
git log --oneline # Kompakte Einzeiler-Ansicht

Staging & Commit

Dateien müssen zunächst in die Staging Area und können dann committet werden:

git add . # Alle Änderungen stagen
git add README.md # Einzelne Datei stagen
git commit -m "initial commit" # Commit mit Nachricht

Tipp: Gute Commit-Messages beschreiben was und warum, nicht wie.

.gitignore

Die Datei .gitignore definiert, welche Dateien Git ignorieren soll (Build-Artefakte, IDE-Konfiguration, Secrets, …):

# Beispiel .gitignore
pycache/
*.pyc
.idea/
.env
build/

Remote hinzufügen und pushen

Ein Remote-Repository (z. B. auf GitHub) wird so verknüpft:

git remote add origin https://github.com/user/repo.git
git push -u origin main

-u setzt das Upstream-Tracking, sodass git push danach ohne weitere Argumente funktioniert.

Änderungen vom Remote holen

git fetch # Holt Änderungen, merged aber NICHT
git pull # Holt Änderungen UND merged in den aktuellen Branch

Faustregel: fetch ist sicher und unverbindlich, pull verändert den lokalen Branch.

Intermediate

Remote-Repo clonen

Statt ein Repository von Grund auf neu zu erstellen, kannst du ein bestehendes Remote-Repository mit git clone auf den eigenen Rechner kopieren.
Dabei passiert automatisch einiges:

1. Ein neuer Ordner mit dem Repository-Namen wird erstellt
2. Die gesamte Historie (alle Commits, Branches, Tags) wird heruntergeladen
3. Ein Remote namens origin wird angelegt, der auf die Quell-URL zeigt
4. Der Standard-Branch (z. B. main) wird ausgecheckt

Grundsyntax:

git clone https://github.com/user/repo.git

Einen bestimmten Branch clonen:

git clone -b develop https://github.com/user/repo.git

Damit wird direkt der Branch develop ausgecheckt, nützlich, wenn du nicht auf main arbeiten möchtest.

Tipp: Nach dem Clonen kannst du dir den eingerichteten Remote anzeigen lassen:

cd repo
git remote -v

#origin https://github.com/user/repo.git (fetch)
#origin https://github.com/user/repo.git (push)

Branching

Branches sind einer der größten Vorteile von Git. Sie erlauben paralleles Arbeiten an Features, Bugfixes usw.

git branch # Alle lokalen Branches anzeigen
git branch feature/login # Neuen Branch erstellen
git checkout feature/login # In den Branch wechseln
git checkout -b feature/login # Erstellen + Wechseln in einem Schritt

Merging

Wenn ein Feature fertig ist, wird der Branch zurück in main gemerged:

git checkout main
git merge feature/login

Merge-Konflikte

Wenn zwei Branches dieselbe Stelle in einer Datei geändert haben, entsteht ein Merge-Konflikt.
Git markiert die betroffenen Stellen:

<<<<<<< HEAD
Deine Änderung
=======
Änderung aus dem anderen Branch
>>>>>>> feature/login

Lösung: Datei manuell bereinigen, dann:

git add <datei>
git commit

Stash

Unfertige Änderungen kann man zwischenspeichern, ohne zu committen:

git stash # Änderungen wegstashen
git stash list # Alle Stashes anzeigen
git stash pop # Letzten Stash wiederherstellen und entfernen
git stash apply # Letzten Stash wiederherstellen, aber behalten

Diff

Änderungen anzeigen lassen:

git diff # Unstaged-Änderungen
git diff --staged # Staged-Änderungen (vor dem Commit)
git diff main..feature # Unterschied zwischen zwei Branches

Tags

Releases oder Meilensteine markieren:

git tag v1.0.0
git tag -a v1.0.0 -m "Erstes Release"
git push origin v1.0.0

Advanced

Rebase

Rebase schreibt die Commit-Historie um und setzt Commits auf eine neue Basis.
Nützlich, um einen sauberen, linearen Verlauf zu erzeugen:

git checkout feature/login
git rebase main

Achtung: Rebase verändert die Historie. Deshalb nicht auf bereits gepushten, geteilten Branches verwenden.

Squashen von Commits

Mehrere Commits zu einem zusammenfassen (z. B. vor einem Merge Request):

git rebase -i HEAD~3 # Die letzten 3 Commits interaktiv bearbeiten

Im Editor dann pick für die gewünschten Commits durch squash (oder s) ersetzen.

Cherry-Pick

Einen einzelnen Commit aus einem anderen Branch übernehmen:

git cherry-pick <commit-hash>

Reflog

Das Sicherheitsnetz: Zeigt alle Aktionen, auch nach einem versehentlichen Reset:

git reflog
git checkout <hash> # Verlorenen Stand wiederherstellen

Fazit

Git ist ein mächtiges Werkzeug. Die Basics reichen für den Alltag, aber wer Rebase, Squash und Bisect beherrscht,
kann auch in komplexen Projekten souverän arbeiten.

Weiterführende Ressourcen:

• Git Branching interaktiv lernen
• Pro Git Book (kostenlos)
• Git Cheat Sheet
• git help <befehl>: Die eingebaute Hilfe ist besser, als man denkt

The post Das große Git-Tutorial appeared first on Creatronix.

Motivation

Das Erlernen einer Programmiersprache kann herausfordernd sein. Es gibt zwar unzählige Artikel und Tutorials, doch echtes Verständnis entsteht vor allem durch regelmäßige Wiederholung und praktische Anwendung.

Wer Konzepte immer wieder in kleinen Übungen, Katas und realen Problemen einsetzt, entwickelt mit der Zeit eine Art Muscle Memory fürs Programmieren. Genau diese Routine hilft dabei, Syntax, Denkweisen und Lösungsstrategien nachhaltig zu verinnerlichen.

Die Herausforderungen

Die Programmieraufgaben sind sprachunabhängig, sodass du jede moderne Sprache verwenden kannst, die das Schreiben von Konsolenanwendungen unterstützt.

🟢 Level 1 – Grundlagen (Syntax & einfache Logik)

1. Schreibe das berühmte / berüchtigte „Hello World“
2. Schreibe ein Skript, das alle Zahlen von 1 bis 365 in die Konsole ausgibt
3. Schreibe ein Skript, das 10 Zufallszahlen zwischen 1 und 10 ausgibt
4. Schreibe ein Skript, das alle Buchstaben des Alphabets (großgeschrieben) mit ihrer jeweiligen Position ausgibt, z. B. 1: A, 2: B
5. Schreibe deinen ersten Unit-Test für eine Funktion is_even(num), die true zurückgibt, wenn die Zahl gerade ist

🟡 Level 2 – Einfache Funktionen & Kontrolle

1. Schreibe eine Funktion to_upper, die einen String von lower_case nach upper_case umwandelt
2. Die Funktion compare(num1, num2) soll
   1. -1 zurückgeben, wenn num1 kleiner als num2 ist
   2. ansonsten 1 zurückgeben
   3. wenn beide Werte gleich sind, 0 zurückgeben
3. Die Funktion simple_sum(num) soll alle Zahlen von 1 bis num aufsummieren
   1. Beispiel: Bei Eingabe 4 soll das Ergebnis 10 sein
   2. Für Testfälle liegt num zwischen 1 und 1000
4. Die Funktion time_convert(minutes) soll Minuten in Stunden und Minuten umwandeln (z. B. 63 → 1:03)
5. Die Funktion first_reverse(input) soll den String umdrehen

🟠 Level 3 – Strings & Arrays

1. Die Funktion alphabet_soup(input) soll den String alphabetisch sortieren
2. Die Funktion longest_word(sentence) soll das längste Wort zurückgeben
3. Die Funktion letter_changes(input) soll Buchstaben ersetzen und Vokale kapitalisieren

🔵 Level 4 – Mathematische Grundlagen

1. Die Funktion factorial(num) soll die Fakultät berechnen
2. Schreibe eine Funktion, die Fibonacci-Zahlen erzeugt (inkl. Memoization)
3. Schreibe eine Funktion, die die Collatz-Sequenz als Liste zurückgibt
4. Schreibe eine Funktion, die den Mittelwert (Mean) eines Integer-Arrays berechnet
5. Schreibe eine Funktion, die den Median eines Integer-Arrays berechnet

🟣 Level 5 – Klassische Algorithmen

1. Schreibe eine Funktion, die ein Integer-Array mit Bubble Sort sortiert
2. Schreibe eine Funktion, die eine Liste von Primzahlen mithilfe des Siebs des Eratosthenes zurückgibt
3. Schreibe eine Funktion, die den größten gemeinsamen Teiler mithilfe des euklidischen Algorithmus berechnet

🔴 Level 6 – Anspruchsvoll / Interview-Level

1. Schreibe eine Funktion, die römische Zahlen in Dezimalzahlen konvertiert
2. Schreibe eine Funktion, die Dezimalzahlen in römische Zahlen konvertiert
3. Die Funktion kaprekars_constant(num) berechnet die Anzahl der Schritte bis 6174 erreicht wird

🧪 Hinweis

Ab der Funktion simple_sum sollte nach dem TDD-Prinzip gearbeitet werden (Test → Implementierung → Refactoring).

The post Lerne neue Programmiersprachen schneller mit diesen Coding Challenges appeared first on Creatronix.

Disclaimer

Die folgende Unterteilung in Programmierung, Entwicklung und Engineering ist ein Versuch einer Einordnung von Prozessen, Methoden und Tools. Ich habe dieses Modell entwickelt, um unseren Auszubildenden und Praktikanten, die oft keine Vorkenntnisse hatten, Software-Engineering beizubringen.

Daher enthält es einige persönliche Ansichten und möglicherweise keine präzisen Definitionen. Es spiegelt meine fast 20-jährige Erfahrung in der Softwarebranche als Entwickler, Tester, QA-Mitarbeiter und Teamleiter wider.

Programmierung: der Kern

Ein bekannter Spruch lautet:

A programmer is an organism that turns coffee and pizza into code.

Programmieren bedeutet, Anforderungen des Kunden in ausführbare Anweisungen, die ein Computer versteht, zu übersetzen. Das kann eine einzelne Person — ein Programmierer — tun.

Programmiersprachen

Ein Programmierer braucht eine oder mehrere Programmiersprachen um Quellcode zu erstellen. Quellcode oder oft nur Code ist Text in einer Sprache wie C, C++, Java oder Python. Jede Sprache definiert klare Regeln für Syntax und Semantik.

Vom Quelltext zum Programm

1. Quelltext schreiben (Editor oder IDE)
2. Kompilieren (z. B. C/C++)
3. Linken und ausführbare Datei erzeugen

Beispiel in C:

#include <stdio.h>

int main(void) {
    printf("Hello world\n");
    return 0;
}

gcc -Wall -g -c hello.c
gcc -o hello hello.o -lm

Das reicht schon, damit wurde bereits ein Programm erstellt. Für echte Projekte oder Produkte reicht das reine
Programmieren aber noch nicht aus.

Softwareentwicklung: vom Code zum Produkt

Sobald mehrere Personen beteiligt sind oder Kundennutzen im Fokus steht, kommen Prozesse, Rollen und Werkzeuge hinzu.

Requirements Tracking – Anforderungen erfassen und klären

Damit ein Team von Programmierern das Richtige baut, müssen Anforderungen des Kunden klar beschrieben werden. Eine Anforderung, die in Textform niedergeschrieben wurde, nennt man auch Requirement. Für die Formulierung haben sich zwei Formate etabliert:

• User Story: Als Rolle möchte ich Funktion, damit Nutzen.
• Use Case: strukturierte Beschreibung einer Interaktion zwischen Nutzer und System

Anforderungen erhalten IDs, Status und Verweise auf Implementierung und Tests. So bleibt über den gesamten Lebenszyklus nachvollziehbar, was umgesetzt, geändert oder verworfen wurde.

Auch die guten alten Lastenhefte (Was der Kunde will) und Pflichtenhefte (Was wir verstanden haben und auch umsetzen werden) haben oft noch ihre Daseinsberechtigung.

Neue Rollen

Dedizierte Tester entlasten ein Team von Programmierern und erhöhen die Produktqualität, weil sie Programme systematisch aus Nutzer- und Risikoperspektive prüfen.

Typische Aufgaben für Tester sind:

• Testfälle aus den Anforderungen ableiten
• Teststrategie und Testdaten definieren
• Manuelle und automatisierte Tests durchführen
• Fehler sauber dokumentieren und priorisieren
• Regressionsrisiken vor Releases bewerten

Wichtig: Tester “testen nicht nur am Ende”, sondern arbeiten früh mit den Programmierern zusammen. So werden Qualitätsprobleme früher sichtbar und deutlich günstiger behoben.

Dokumentation

Gute Dokumentation entlastet Teams im Alltag und reduziert Wissensinseln.

• Produktdokumentation: Was kann das System aus Nutzersicht?
• Technische Dokumentation: Architektur, Schnittstellen, Betriebswissen
• Entscheidungsdokumentation: Warum wurde etwas so gebaut?

Wichtig ist nicht “möglichst viel Text”, sondern aktuelle, auffindbare und wartbare Dokumentation.

Versionsverwaltung nutzen

Werkzeuge wie Git speichern den kompletten zeitlichen Verlauf einer Codebasis. Sie ermöglichen damit:

• Zusammenarbeit im Team
• Nachvollziehbare Änderungen
• Rückkehr zu früheren Ständen

Hinweis: Git ersetzt kein vollständiges Backup-Konzept.

Builds automatisieren & Abhängigkeiten verwalten

Moderne Anwendungen nutzen viele oft externe Bibliotheken. Package Manager wie cargo, npm oder gradle helfen bei einheitlichen Builds und reproduzierbaren Versionen. Ziel: Alle können jederzeit denselben Build erzeugen.

Zusätzlich braucht es klare Build Tools und ein belastbares Build System:

• standardisierte Build-Kommandos lokal und in CI
• reproduzierbare Artefakte über Umgebungen hinweg
• schnelle, stabile Pipelines mit klarer Fehlerdiagnose

IDE

Während beim reinen Programmieren ein einfacher Texteditor ausreichen kann, verwenden Softwareentwickler in der Praxis meist leistungsfähige IDEs.

Eine IDE bündelt zentrale Entwicklungsaufgaben in einem Werkzeug:

• Code schreiben mit Syntaxprüfung und Autovervollständigung
• Navigation durch große Codebasen (z. B. “Gehe zu Definition”)
• Refactoring mit geringem Fehlerrisiko
• Debugging mit Breakpoints und Variableninspektion
• Direkte Integration von Tests, Linter und Build-Prozessen
• Anbindung an Versionsverwaltung wie Git

Der eigentliche Nutzen liegt in der Produktivität und Qualität: Teams arbeiten schneller, konsistenter und machen weniger vermeidbare Fehler.

Issue Tracking – Arbeit transparent machen

Issues, Bugs und Aufgaben werden in einem Tracking-System verwaltet (z. B. Jira, YouTrack, GitHub Issues). So bleiben Prioritäten, Zuständigkeiten und Fortschritt nachvollziehbar.

Projektorganisation mit Scrum oder Kanban

Damit Teamarbeit planbar und transparent bleibt, wird Arbeit in kleine, priorisierte Einheiten aufgeteilt und sichtbar gemacht.

Bei Scrum erfolgt die Planung meist in festen Iterationen (Sprints), z. B. alle ein bis zwei Wochen:

• Ziele für den Sprint festlegen
• Aufgaben gemeinsam schätzen und zuschneiden
• Fortschritt täglich abstimmen
• Ergebnisse am Sprint-Ende überprüfen und verbessern

Bei Kanban steht der kontinuierliche Fluss im Vordergrund:

• Aufgaben visualisieren (z. B. To-do, In Arbeit, Erledigt)
• Parallelarbeit mit WIP-Limits begrenzen
• Engpässe früh erkennen und aktiv beseitigen

Beide Ansätze helfen, Lieferfähigkeit und Qualität im Alltag stabil zu halten.

Qualität absichern

Qualität entsteht nicht zufällig, sondern durch disziplinierte Routinen:

• Tests (Unit, Integration, End-to-End)
• TDD (Test-Driven Development)
• Debugging
• Logging
• Linting und statische Codeanalyse
• Code Reviews

TDD sinnvoll einsetzen

Bei TDD schreibst du zuerst einen fehlschlagenden Test, implementierst dann den minimal nötigen Code und verbesserst anschließend die Struktur (Red-Green-Refactor).

TDD ist besonders hilfreich bei:

• Geschäftslogik mit klaren Regeln
• APIs und Modulen mit stabilen Schnittstellen
• Codebereichen, die häufig geändert werden

So entsteht oft besser testbarer, klarer strukturierter Code und Regressionen werden früher erkannt.

Struktur schaffen mit Design Patterns

Design Patterns werden benötigt, weil in Softwareprojekten viele Probleme immer wieder auftreten. Statt jedes Mal eine neue, ungeprüfte Lösung zu bauen, nutzt du bewährte Strukturen.

Sie helfen konkret bei:

• Verständlichkeit: Andere Entwickler erkennen schneller, wie dein Code aufgebaut ist.
• Wartbarkeit: Änderungen sind einfacher, weil Verantwortlichkeiten klarer getrennt sind.
• Erweiterbarkeit: Neue Features lassen sich oft mit weniger Umbau integrieren.
• Teamkommunikation: Begriffe wie Factory, Observer oder Strategy sind eine gemeinsame Sprache.
• Risikoreduktion: Patterns sind praxiserprobt und vermeiden typische Architekturfehler.

Kurz: Design Patterns machen Code nicht “magisch besser”, aber sie machen komplexe Systeme robuster und für Teams beherrschbarer.

Software-Engineering – erfolgreich Großprojekte umsetzen

Sobald mehrere Teams parallel an einem Produkt arbeiten, reicht reine Softwareentwicklung nicht mehr aus. Spätestens bei Teamgrößen von etwa 8 bis 12 Personen (oder mehreren unabhängigen Feature-Teams) steigen Koordinationsaufwand, Integrationsrisiken und Betriebsverantwortung deutlich.

Dann geht es nicht nur um “Features bauen”, sondern auch um:

• einheitliche technische Leitplanken
• verlässliche Release- und Betriebsprozesse
• klare Verantwortlichkeiten zwischen Entwicklung, Produkt und Betrieb
• skalierbare Qualitätssicherung über Teamgrenzen hinweg

Genau hier beginnt der eigentliche Mehrwert von Software Engineering.

Neue Rollen

Mit wachsender Produkt- und Teamgröße entstehen zusätzliche Rollen, die Entwicklung strukturieren und skalierbar machen.

Projektleiter koordinieren Zeit, Budget, Abhängigkeiten und Risiken.
Sie sorgen dafür, dass Entscheidungen transparent sind und Teams in die gleiche Richtung arbeiten.

Requirements Engineers präzisieren Anforderungen und übersetzen fachliche Ziele in umsetzbare Spezifikationen.
Dadurch sinken Missverständnisse zwischen Fachseite, Produktmanagement und Entwicklung.

DevOps-Teams bauen die Brücke zwischen Entwicklung und Betrieb.
Sie verantworten u. a. CI/CD-Pipelines, Deployment-Prozesse, Monitoring und stabile Betriebsabläufe.

Wichtig ist das Zusammenspiel: Diese Rollen ersetzen nicht die Entwicklung, sondern schaffen den Rahmen, in dem Entwicklung zuverlässig liefern kann.

Architektur definieren

Architektur beschreibt die grobe Struktur und die Kommunikationswege eines Systems, z. B.:

• Frontend – Backend – Datenbank
• Schichtenarchitektur
• Event-basierte Systeme (Pub/Sub)
• Dependency-Injection-Frameworks

Sie legt die Leitplanken fest, nicht jedes Implementierungsdetail.

Software betreiben und ausliefern

Zum Engineering gehört auch der Betrieb:

• CI/CD (Continuous Integration / Continuous Deployment) für automatisches Bauen, Testen und Ausrollen
• Staging-Umgebungen vor Produktion
• Branching-Strategie (z. B. Trunk-Based oder Gitflow)
• Containerisierung mit Docker/Kubernetes
• Monitoring und Qualitätsmetriken
• Release Notes pro Version oder Deployment
• Artifact Mirror/Artifact Repository für kontrollierte Abhängigkeiten und Build-Artefakte

Quality Dashboards nutzen

Quality Dashboards machen Qualität messbar statt gefühlt. Typische Kennzahlen sind:

• Testabdeckung und Fehlerraten
• Build- und Deployment-Stabilität
• Laufzeitmetriken wie Latenz, Fehlerquote und Verfügbarkeit
• technische Schulden (z. B. statische Analyse, Duplikate, Komplexität)

Nicht jede Metrik passt für jedes Team. Entscheidend ist, wenige Kennzahlen konsequent zu nutzen und Trends zu beobachten.

Blindspots im Alltag

Einige Themen fehlen in vielen Teams anfangs, sind aber zentral für professionelles Software Engineering:

• Security by Design: Threat Modeling, Dependency-Scans, Secret-Management, Sicherheitsupdates
• Reliability Engineering: SLOs, Alerting, Runbooks, Incident- und Postmortem-Prozesse
• Wartbarkeit: technischer Schuldenabbau, regelmäßige Refactorings, klare Ownership
• Wissensverteilung: Onboarding, Pairing, Reviews und Dokumentation statt “Single Points of Failure”

Fazit

Software Engineering ist mehr als Programmieren. Es verbindet Technik, Prozesse und Zusammenarbeit, damit Software langfristig zuverlässig, wartbar und nutzbar bleibt.

Wie ich eingangs erwähnte: Dies ist ein gedankliches Modell. Die Grenzen zwischen den Bereichen sind fließend: Man kann natürlich von Anfang an Versionskontrolle einsetzen und ein CI/CD-System für ein einfaches „Hello World“-Programm einrichten. Mein Hauptanliegen ist es, das Bewusstsein dafür zu schärfen, dass Softwareentwicklung eine Vielzahl von Werkzeugen und Praktiken umfasst, deren Lernkurve steil ist, wenn man versucht, alles auf einmal zu beherrschen. Durch die Unterteilung des Fachgebiets in drei Ebenen lassen sich die Konzepte möglicherweise leichter schrittweise erfassen und die Fähigkeiten von innen nach außen entwickeln.

Links

Die Junior und die Senior-Rolle

Wie baue ich eine entwicklungsbegleitende Software-Qualitätssicherung auf?

Wie TDD die Welt rettet und deine Nerven schont

Pytest Tutorial

So verwendest du Google Test in deinem C++-Projekt

Alles was du über Scrum wissen musst

Writing as a complementary skill for your SW engineering career

Literatur

The Software Engineer’s Guidebook

Mein erster Kontakt mit TDD (old but gold) 

The post Was ist Software Engineering? Eine verständliche Einführung appeared first on Creatronix.

Eine einzelne Ubuntu-Maschine zu warten, ist noch überschaubar. Man loggt sich per SSH ein, installiert ein paar Pakete, macht ein Update – und dann läuft die Kiste wieder.

In der Robotik bleibt es aber selten bei einer Maschine. Sobald mehrere Roboter im Einsatz sind, sitzt man plötzlich vor einem kleinen Zoo aus Linux-Systemen.

Dann beginnt die klassische Runde:
SSH auf Rechner eins, Updates einspielen.
SSH auf Rechner zwei, dieselben Updates einspielen.
SSH auf Rechner drei – na, Du ahnst es schon.

Spätestens nach dem fünften Roboter merkt man: Das ist weniger Systemadministration und mehr Fleißarbeit mit Copy-Paste.

Genau hier kommt Ansible ins Spiel. Mit sogenannten Playbooks beschreibt man einfach den gewünschten Zustand der Systeme – welche Pakete installiert sein sollen, welche Konfigurationen gelten, welche Updates eingespielt werden. Ansible kümmert sich dann darum, diese Zustände automatisch auf allen Zielrechnern umzusetzen.

Gerade in Robotik-Umgebungen mit vielen verteilten Rechnern sorgt dieser Ansatz dafür, dass Wartung nicht mehr Handarbeit ist – sondern planbar, reproduzierbar und vor allem deutlich entspannter.

Ansible

Ansible wurde 2012 von Michael DeHaan entwickelt und als Open-Source-Projekt veröffentlicht. 2015 wurde das Unternehmen Ansible, Inc. von Red Hat übernommen, das wiederum seit 2019 zu IBM gehört.

Es ist ein agentenloses Automatisierungstool – das heißt, auf den Zielrechnern muss keine zusätzliche Software installiert werden. Ansible verbindet sich einfach per SSH und führt die gewünschten Aufgaben aus.

Setup

Für dieses Tutorial brauchst Du einen Ubuntu-PC und einen Raspberry Pi mit einem installierten Ubuntu. Auf deinem Control-Rechner (also deinem PC) läuft Ansible und der SSH Client, auf dem Raspberry (also dem Remote-Rechner) muss der SSH-Server aktiviert sein.

Installation

Auf deinem Control-Rechner installierst du Ansible wie folgt:

sudo apt update
sudo apt install ansible
sudo apt install sshpass

Jetzt kannst Du testen, ob die Installation geklappt hat:

ansible --version

SSH aktivieren

Damit Ansible funktioniert, muss auf dem Raspberry aka Remote-Rechner SSH eingerichtet sein.
Probier mal im Terminal deines Control-Rechners aus, dich mit dem Raspberry zu verbinden:

ssh pi@192.168.178.50

Falls das nicht klappt, musst du SSH auf dem Raspberry aktivieren. Das geht ganz einfach über die raspi-config:

sudo raspi-config

Dann navigierst du zu “Interfacing Options” -> “SSH” und aktivierst den SSH-Server.

Projektordner

Auf deinem Control-Rechner legst du dir z.B. einen Projektordner an:

mkdir ~/ansible
cd ansible
touch hosts
touch ansible.cfg
touch update_pi.yml

Die Ordnerstruktur soll nachher so aussehen:

ansible/
├── hosts
├── update_pi.yml
└── ansible.cfg

hosts-Datei anlegen

In der hosts-Datei stehen die Rechner und ihre IP-Adressen bzw. ihre A-Records.

[raspberry]
pi1 ansible_host=192.168.178.66 ansible_user=<username>

ansible.cfg

Die ansible.cfg Datei ist die Konfigurationsdatei für Ansible.
Hier kannst du verschiedene Einstellungen vornehmen, z.B. den Pfad zu deiner hosts-Datei.
Ein einfaches Beispiel sieht so aus

[defaults]
inventory = hosts

Playbooks

Playbooks sind die Ansible-Äquivalente zu Skripten, sie beschreiben die gewünschten Zustände der Zielrechner.
Ein einfaches Playbook für die Updates des Raspberrys könnte so aussehen:

update_pi.yml

---
- name: Update Raspberry Pi
  hosts: raspberry
  become: yes

  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes

    - name: Upgrade all packages
      apt:
        upgrade: dist

Im Detail

Ansible starten

Wenn du diese drei Dateien anegelegt hast, kann es auch schon losgehen

ping

Der ping-Befehl ist ein Testmodul von Ansible, das überprüft, ob der Host erreichbar und ausführbar ist.
Wenn du Passwort-Login benutzt musst du Ansible sagen, dass es nach einem SSH-Passwort fragen soll:
Das -k steht für –ask-pass

ansible -i hosts raspberry -m ping -k
SSH password:

Wenn alles funktioniert, solltest du folgenden Output sehen:

pi1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}

Playbook starten

Jetzt zum eigentlichen Task:

ansible-playbook -i hosts update_pi.yml -k -K

Da wir sudu apt update / upgrade machen wollen, müssen wir auch das root-PW übergeben. Das machen wir mit dem Flag -K.
-K steht für –ask-become-pass, damit wird Ansible nach dem sudo-Passwort fragen.

Zertifikat-Login

Da wir aber nicht permanent die
Ansible unterstützt auch die Authentifizierung mit Zertifikaten, was sicherer ist als die Passwort-Authentifizierung.
Dazu musst du auf deinem Control-Rechner ein SSH-Schlüsselpaar generieren und den öffentlichen Schlüssel auf den
Zielrechner kopieren.

ssh-keygen -t rsa -b 4096 -C "@ansible-controller"
ssh-copy-id @192.168.178.66

Danach kannst du Ansible ohne Passwort verwenden, indem du einfach den Hostnamen angibst:

ansible-playbook -i hosts update_pi.yml -K

Weitere Beispiele

Ubuntu-Pakete installieren

Man kann natürlich auch andere Pakete installieren, z.B. git:

tasks: 
- name: Install git 
  apt: 
    name: git 
    state: present 
    update_cache: yes

Git Repository klonen

Auch das Klonen eines Git-Repositories ist mit Ansible kein Problem:

tasks: 
- name: Clone Git repo 
    git:
      repo: https://github.com/user/meinprojekt.git 
      dest: /home/pi/meinprojekt 
      version: main

Fazit

Ansible ist ein mächtiges Werkzeug, um die Wartung von Robotern zu automatisieren. Es ermöglicht dir, den Zustand deiner
Systeme zu beschreiben und automatisch umzusetzen, ohne dich manuell auf jedem Rechner einzuloggen. Gerade in Umgebungen
mit vielen verteilten Rechnern spart das enorm viel Zeit und Nerven.

The post So verwaltest du deine Roboter mit Ansible appeared first on Creatronix.

SCRUM wurde von Ken Schwaber und Jeff Sutherland entwickelt und ist ein agiles Framework für die Softwareentwicklung.
Es hilft Teams, komplexe Projekte zu managen und schnell auf Veränderungen zu reagieren.
SCRUM fördert die Zusammenarbeit, Transparenz und kontinuierliche Verbesserung.

Werte

Commitment, Focus, Openness, Respect, and Courage

Vorgehensmodell

Interativ & Inkrementell

Entwicklungszeitraum wird in Sprints unterteilt

Sprints

Dauer: 2-4 Wochen
Ziel: funktionierende Software nach jedem Sprint mit neuen Features die den Geschäftswert des Produkte maximieren

Messen der Velocity

• Velocity = Anzahl der Story Points, die in einem Sprint abgeschlossen wurden
• hilft bei der Planung zukünftiger Sprints

Rollen

Product Owner

Stellvertreter des Kunden und der Stakeholder
Der Product Owner ist verantwortlich für:

• Produktvision und Strategie
• Product Backlog erstellen und priorisieren
• Anforderungen verstehen, übersetzen und priorisieren
• Wert für das Produkt maximieren
• Stakeholder koordinieren

Er ist die zentrale Entscheidungsinstanz für das Produkt.

Scrum Master

• coacht Teammitglieder und Organisation
• verwaltet impediment backlog
• löst impediments auf
• moderiert Meetings mit dem Ziel, die Effizienz des Teams zu verbessern
• schützt das Team vor äußeren Störungen
• fördert die Einhaltung von Scrum-Prinzipien und -Praktiken

Scrum Team

• schätzt User Stories
• setzt Stories um
• arbeitet selbstorganisiert
• cross-funktional (Entwickler, Tester, Designer etc.)
• verantwortlich für die Lieferung von Inkrementen am Ende jedes Sprints

Artefakte

Inkrement

Neue Software, die am Ende eines Sprints fertiggestellt und potenziell auslieferbar ist.

Product-Backlog

• enthält User Stories mit Definition of Done (DoD) und Akzeptanzkriterien
• priorisiert nach Business Value
• dynamisch, wird während des Projekts angepasst

Sprint-Backlog

• alle Items für den Sprint, inkl. DoD und Akzeptanzkriterien
• Burndown / Burnup Chart für Fortschrittsverfolgung

Impediment-Backlog

Für Hindernisse, die das Team daran hindern, die Sprint-Ziele zu erreichen
Beispiele:

• CI Pipeline funktioniert nicht
• Zugang zu Testdaten fehlt
• API Dokumentation unvollständig
• Fehlende Hardware für Tests

Termine

Backlog Refinement (früher Backlog Grooming)

Zeitpunkt: 1-2 mal pro Sprint, oft in der Mitte des Sprints
Dauer: 1-2 Stunden
Ziel: User Stories mit DoD, Akzeptanzkriterien und Story Points versehen, damit sie für die Sprintplanung bereit sind

Planning Poker

Wie geschätzt wird, lässt Scrum offen, aber Planning Poker ist beliebt.
Jeder Teilnehmer erhält Karten mit Zahlen (z.B. Fibonacci-Folge: 1, 2, 3, 5, 8, 13)

Die Zahlen stehen für die Komplexität der Aufgabe von 1 – sehr simpel bis 13 sehr komplex.
Der Product Owner liest eine User Story vor, und die Teilnehmer schätzen gleichzeitig, indem sie eine Karte mit ihrer Schätzung hochhalten
Nach der Schätzung diskutieren die Teilnehmer, um ein gemeinsames Verständnis zu erreichen.

Sprint Planning

Zeitpunkt: Am Anfang eines Sprints
Dauer: 4-8 Stunden (je nach Sprintlänge)
Ziel: Sprint-Ziele festlegen, User Stories auswählen, die im Sprint bearbeitet werden sollen, und Aufgaben planen

Daily Standup

Zeitpunkt: Täglich, meist morgens
Dauer: 15 Minuten
Ziel: Mini-Retro: Awareness für erledigte und aktuelle Tätigkeiten, Impediments an Scrum Master kommunizieren

Sprint Retro

Zeitpunkt: Am Sprint-Ende
Dauer: 1-2 Stunden
Ziel: Reflexion über den vergangenen Sprint, Identifikation von Verbesserungsmöglichkeiten, Maßnahmen für den nächsten Sprint planen

Scrum but – Antipatterns

Wenn Scrum nicht richtig umgesetzt wird, können verschiedene Probleme auftreten, z.B.:

• Scrum Master ist nur ein Titel, aber keine echte Rolle im Team
• Product Owner ist nicht verfügbar oder hat keine Entscheidungsbefugnis
• Team arbeitet nicht selbstorganisiert, sondern wird von außen gesteuert
• Sprints werden nicht eingehalten, sondern ständig verlängert oder verkürzt
• Meetings werden nicht effektiv genutzt, sondern sind reine Zeitverschwendung
• Keine klare Definition of Done, was zu unklaren Anforderungen und Qualitätsproblemen führt
• Keine regelmäßige Retrospektive, was zu fehlender kontinuierlicher Verbesserung führt
• Keine klare Priorisierung im Product Backlog, was zu ineffizienter Arbeit und fehlendem Fokus führt

Quellen

https://scrumguides.org/scrum-guide.html

The post Alles, was Du über SCRUM wissen musst appeared first on Creatronix.

In Robotik-Projekten wird in den meisten Fällen mit einer Linux-Distribution wie Ubuntu gearbeitet, deswegen ist es von Vorteil, sich auch auf der Linux-Konsole aka shell auszukennen.

Die Standard-Shell ist meistens Bash (Bourne Again Shell). Viele ROS-Tools erwarten explizit Bash:

source /opt/ros/humble/setup.bash

Informationen über Kommandos

Mit dem Kommando man kann man sich Infos zu den Kommandos geben lassen:

man ls

Eine moderne Alternative ist tldr:

tldr ls

Du kannst es unter Ubuntu mit

sudo snap install tldr

installieren.

Datei-Handling

Benutzer & Rechte

Linux-Pakete & Versionsinformationen

Prozesse

Netzwerke

USB

The post Linux Shell Kommandos Cheatsheet appeared first on Creatronix.

Tests sind ein zentraler Bestandteil moderner Entwicklung. Das Framework pytest macht das Schreiben, Organisieren und Ausführen von Tests einfach, flexibel und leistungsfähig.

Tests schreiben und ausführen

Installation

Zuerst installierst du pytest mit:

pip install pytest

pytest ist kompatibel mit unittest-Tests und erfordert keine Testklassen.

Namenskonventionen

Damit pytest Tests automatisch findet, müssen Dateien und Funktionen bestimmte Namen haben:

• Dateinamen haben test im Namen
• Funktionsnamen beginnen mit test_

Beispiel:

def test_example():
    x = 5
    assert x == 5

Mit pytest im Terminal führt pytest alle passenden Tests aus.

Testauswahl

Du kannst gezielt Tests ausführen:

pytest test_module.py::test_function
pytest -k "keyword"

Optionen wie -v (verbose), -x (bei Fehler abbrechen) oder -s (print-Ausgaben anzeigen) sind sehr praktisch.

Um Optionen nicht immer per Hand eingeben zu müssen, können diese auch in einer pytest.ini angegeben werden:

[pytest]
pythonpath = .
addopts = -x --durations=0 -vv

Fortgeschrittene pytest-Techniken

Fixtures

import pytest

@pytest.fixture(scope="function")
def simple_fixture():
    return 42

def test_function(simple_fixture):
    assert simple_fixture == 42

Fixture scopes

pytest-Fixtures haben einen Scope, der bestimmt, wie oft eine Fixture erzeugt und wiederverwendet wird.
Der Standard-Scope ist function, d. h. die Fixture wird für jeden Test neu ausgeführt.

Weitere Scopes sind:

• class – einmal pro Testklasse
• module – einmal pro Datei
• package – einmal pro Paket
• session – einmal pro gesamtem Testlauf

Größere Scopes verbessern die Performance, bergen aber das Risiko von geteiltem Zustand zwischen Tests.
Daher gilt: so klein wie möglich, so groß wie nötig.

Setup and teardown

Mit pytest können wir klassische setup / teardown Methoden mit fixtures nachbauen

import pytest

def test_setup_and_teardown():
    assert True

@pytest.fixture(autouse=True, scope="function")
def setup_and_teardown():
    print("SetUp")
    # setup code goes here
    yield
    print("TearDown")
    # teardown code goes here

Parametrisierung

Mit Parametrisierung lässt sich derselbe Test mit verschiedenen Daten ausführen. So umgehst du Duplikate:

import pytest

@pytest.mark.parametrize("data, expected", [
    ([1], 1),
    ([1, 2], 1.5),
    ([1, 2, 3], 2),
])
def test_calculate_mean(data, expected_mean):
    mean = calculate_mean(data)
    assert mean == expected_mean

def calculate_mean(data):
    return sum(data) / len(data)

Das definiert mehrere Testinstanzen automatisch.

Marker

Marker helfen, Gruppen von Tests zu steuern.
Marker eignen sich z. B. zur Gruppierung nach Plattform, Kategorie oder Dauer.

Es gibt drei eingebaute Marker:

• skip
• skipif
• xfail

import pytest
import sys

@pytest.mark.skip(reason="Feature not yet implemented")
def test_future():
    pass

@pytest.mark.skipif(sys.platform == "win32", reason="Linux only")
def test_linux_only():
    pass

@pytest.mark.xfail(reason="Bug #123")
def test_known_bug():
    pass

Eigene Marker

import pytest

@pytest.mark.slow
def test_slow():
    pass

In pytest.ini:

[pytest]
...
markers =
    slow: mark slow tests

Dann kannst du testen mit:

pytest -m slow

Oder alle nicht langsamen Tests laufen lassen:

pytest -m "not slow"

Nahezu gleiche Vergleiche

Für Fließkommazahlen ist ein exakter Vergleich oft ungeeignet. pytest bietet das approx-Feature:

assert 2.2 == pytest.approx(2.3, 0.1)

Erlaubt eine Toleranz statt exakter Übereinstimmung.

Exceptions testen

Mit pytest kannst du das Auftreten von Ausnahmen elegant testen:

def test_zero_division():
    with pytest.raises(ZeroDivisionError):
        1 / 0

Das prüft, ob ein Fehler erwartet korrekt geworfen wird.

Test-Reporting & Coverage

Testabdeckung mit pytest-cov

Mit dem Plugin pytest-cov lässt sich messen, wie viel deines Codes getestet wird:

pip install pytest-cov

pytest --cov=my_app 10_app_test

Ergebnis: Coverage-Statistiken zeigen an, wie viele Zeilen getestet wurden.

HTML-Reports

Du kannst mit demselben Plugin HTML-Berichte erzeugen:

pytest --cov=my_app --cov-report=html

Eine visuelle Übersicht über die Abdeckung hilft bei der Analyse.

Integration mit Werkzeugen

Coverage-Daten lassen sich in Tools wie SonarQube einbinden:

pytest --cov-report=xml:coverage.xml

Dadurch kannst du Metriken in CI/CD-Pipelines oder Dashboards verwenden.

Assertions mit Hamcrest (optional, aber mächtig)

Neben den eingebauten assert-Anweisungen von pytest kann man auch Hamcrest verwenden.
Hamcrest ist eine Matcher-Bibliothek, die Tests lesbarer und ausdrucksstärker machen kann – besonders bei komplexen Datenstrukturen.

Installation

pip install pyhamcrest

Import in Tests:

from hamcrest import assert_that, equal_to

Warum Hamcrest?

Vergleich:

def test_hamcrest_assert():
    result = 42
    assert_that(result, equal_to(42))

Der Vorteil zeigt sich bei komplexeren Assertions:

def test_hamcrest_start_with():
    name = "Max Mustermann"
    assert_that(name, starts_with("Max"))

def test_hamcrest_has_length():
    items: Sized = ['apple', 'banana', 'cherry']
    assert_that(items, has_length(3))

Tests lesen sich mehr wie Spezifikationen.

Listen & Collections

from hamcrest import assert_that, has_items
from collections.abc import Sequence

def test_compare_list_of_items():
    actual_list_of_items: Sequence[str] = ['apple', 'banana', 'cherry']
    assert_that(actual_list_of_items, has_items("apple", "banana"))

Fazit

pytest ist ein einfaches, doch mächtiges Framework zur Testautomatisierung in Python. Es kombiniert:

• geringe Einstiegshürde – einfache Tests schnell geschrieben
• hohe Flexibilität – Marker, Parameter, Coverage
• gute Tools-Integration – HTML-Reports oder CI-Coverage

Damit eignet es sich sowohl für Einsteiger als auch für professionelle Test-Pipelines.

Code

https://github.com/jboegeholz/pytest_tutorial

The post Pytest Tutorial appeared first on Creatronix.

Auf meiner Lernreise in die Welt der Robotik ist eines meiner Ziele, mein angestaubtes C++-Wissen aufzubessern.
Heute schauen wir uns den std::vector an. Der std::vector ist ein praktisches Hilfsmittel, um in C++ Daten zu verwalten.
Man kann ihn mit der Liste in Python vergleichen. Im Gegensatz zum std::array ist der std::vector eine dynamische Datenstruktur, die wächst, wenn neue Werte hinzugefügt werden und die bisherige Kapazität nicht mehr ausreicht.

Historie

Den std::vector gibt es bereits ab C++98, er wurde von Alexander Stepanov entwickelt. Seit C++11 sind einige interessante Neuerungen hinzugekommen.

Include

Um einen Vector zu benutzen, wird der Header vector eingebunden:

#include <vector>

Deklaration

Der std::vector ist eine Template-Datenstruktur, d.h. wir müssen ihn mit dem Datentyp parametrieren, der eingefügt werden soll:

TEST(VectorTest, VectorInitialSize) {
    const std::vector int_vector;
    EXPECT_EQ(int_vector.capacity(), 0);
    EXPECT_EQ(int_vector.size(), 0);
    EXPECT_EQ(int_vector.empty(), true);
}

Die Kapazität und die Größe sind am Anfang 0; empty() gibt true zurück

Daten einfügen

Die einfachste Art, Daten in den Vector zu packen, ist die push_back()-Methode. Sie hängt ein neues Element an das Ende des vectors

TEST(VectorTest, VectorPushBack) {
    std::vector int_vector;
    int_vector.push_back(1);
    int_vector.push_back(2);
    int_vector.push_back(3);
    EXPECT_EQ(int_vector.size(), 3);
}

Mit der Insert-Methode kann an einer beliebigen Stelle im Vector ein Element eingefügt werden:

TEST(VectorTest, VectorElementInsert) {
    std::vector int_vector = {1,2,3};
    int_vector.insert(int_vector.begin(), 0);
    EXPECT_EQ(int_vector.at(0), 0);
}

Allerdings werden dann Elemente um jeweils eine Stelle verschoben (kopiert) was zur Laufzeit in O(n) führt, also O(n²).
Bei vielen Elementen kann es sich lohnen push_back + std::sort zu verwenden, das ist dann in O(n log n)
Zu beachten ist hier zudem, dass die Stelle an der eingefügt werden soll, nicht durch einen Index, sondern durch einen Iterator angegeben wird.

Daten auslesen

Grundsätzlich unterstützt vector sowohl den Index-Operator als auch die at()-Methode:

TEST(VectorTest, VectorGetElement) {
    const std::vector int_vector = {1,2,3,4,5};
    EXPECT_EQ(int_vector[2], 3);
    EXPECT_EQ(int_vector.at(2), 3);
}

Die at()-Methode ist zu bevorzugen, weil sie eine Exception wirft, wenn der Index nicht verfügbar ist.

TEST(VectorTest, VectorGetElementException) {
    const std::vector int_vector = {1,2,3,4,5};
    EXPECT_THROW((void)int_vector.at(10), std::out_of_range);
}

Wenn man am ersten Element im Vektor interessiert ist, kann die front()-Methode benutzt werden. Das letzte Element kann mit back() abgefragt werden.
Aber Vorsicht: auch hier solltest du prüfen, ob der vector nicht leer ist.

TEST(VectorTest, VectorElementBackFront) {
    const std::vector int_vector = {1,2,3};
    if (!int_vector.empty())
    {
        EXPECT_EQ(int_vector.front(), 1);
        EXPECT_EQ(int_vector.back(), 3);
    }
}

Daten löschen

Mit der Methode pop_back() löschst du das letzte Element aus einem Vektor.

TEST(VectorTest, VectorElementPopBack) {
    std::vector int_vector = {1,2,3};
    int_vector.pop_back();
    EXPECT_EQ(int_vector.size(), 2);
}

Mit der Methode clear() kann der komplette Vektor geleert werden. Die Size ist danach auch wieder = bzw. empty wieder true

TEST(VectorTest, VectorClear) {
    std::vector int_vector = {1,2,3};
    int_vector.clear();
    EXPECT_EQ(int_vector.size(), 0);
}

Kapazität vs Größe

Die Kapazität ist die maximal mögliche Anzahl von Elementen, die Größe die wirkliche Anzahl.
Je nach Compiler wird der Vector unterschiedlich vergrößert:
Clang und der GCC verdoppeln die Größe eines Vectors, sobald die Kapazität nicht mehr ausreicht, um ein weiteres Element einzufügen.

MSVC erhöht die Kapazität um lediglich 50 %.

Das Verhalten kann mit folgendem Code überprüft werden:

TEST(VectorTest, VectorPushBack) {
    std::vector int_vector;
    int_vector.push_back(1);
    int_vector.push_back(2);
    int_vector.push_back(3);
    EXPECT_EQ(int_vector.size(), 3);

#if defined(_MSC_VER)
    EXPECT_EQ(int_vector.capacity(), 3);
#elif defined(__clang__) || defined(__GNUC__)
    EXPECT_EQ(int_vector.capacity(), 4);
#endif

    int_vector.push_back(4);
    EXPECT_EQ(int_vector.size(), 4);
    EXPECT_EQ(int_vector.capacity(), 4);

    int_vector.push_back(5);
    EXPECT_EQ(int_vector.size(), 5);

#if defined(_MSC_VER)
    EXPECT_EQ(int_vector.capacity(), 6);
#elif defined(__clang__) || defined(__GNUC__)
    EXPECT_EQ(int_vector.capacity(), 8);
#endif

}

Beide Strategien haben Vor- und Nachteile

Wenn du lieber von vornherein eine explizite Größe vorgeben möchtest, kannst du die reserve()-Funktion benutzen. Dann wird im Vector für die konkrete Kapazität Speicher allokiert.

TEST(VectorTest, VectorReserve) {
    std::vector int_vector;
    int_vector.reserve(100);
    EXPECT_EQ(int_vector.capacity(), 100);
}

emplace_back

Jetzt wird es spannend. Wir haben bisher das push_back auf einfache Datentypen angewendet.
Was passiert aber, wenn wir Objekte in den Vector pushen?

std::vector str_vector;
str_vector.push_back("Hello world");

Hier wird der string erst erzeugt und dann nochmal kopiert. Das ist natürlich ineffizient, weil das initiale Objekt außerhalb des Funktions-Aufrufes nicht verwendet wird. Deshalb sparen wir uns seit C++11 die Kopie, indem wir emplace_back() verwenden.

TEST(VectorTest, VectorEmplaceBackString) {
    std::vector my_vector;
    my_vector.emplace_back("Hello");
    my_vector.emplace_back("World");
    EXPECT_EQ(my_vector.at(0), "Hello");
}

Quellcode

https://github.com/jboegeholz/modern_cpp/blob/master/tests/04_test_vector.cpp

Further Reading

Electronic Arts hat ihre STL-Implementierung geopensourct
https://github.com/electronicarts/EASTL/blob/master/include/EASTL/vector.h

The post So verwendest Du den std::vector – Modernes C++ appeared first on Creatronix.

Auf meiner Lernreise in die Welt der Robotik ist eines meiner Ziele, mein angestaubtes C++-Wissen aufzubessern.
Heute schauen wir uns das Konzept von std::array an.

Wie war es früher?

Vor C++11 musste man C-Style-Arrays benutzen:

TEST(ArrayTest, CStyleArray) {
    int my_int_array[3] = {1, 2, 3};
    EXPECT_EQ(my_int_array[0], 1);
    EXPECT_EQ(my_int_array[1], 2);
    EXPECT_EQ(my_int_array[2], 3);
}

Das hat natürlich ein paar Nachteile:

Sizeof kompliziert

Die Funktion sizeof() kann eigentlich nicht direkt für Arrays verwendet werden, da sie die Größe einer Datenstruktur in Bytes angibt.
Das können wir in folgendem Beispiel sehen. Ein Int-Array der Größe drei ist 12 Byte groß ein.
Ein Double-Array der Größe drei hat 24 Byte.

TEST(ArrayTest, CStyleArraySize) {
    int my_int_array[3];
    double my_double_array[3];
    EXPECT_EQ(sizeof(my_int_array), 12);
    EXPECT_EQ(sizeof(my_double_array), 24);
}

Deswegen musste man das Ergebnis von sizeof des Arrays noch mal durch die Größe des Datentyp teilen.

Decaying

Pointer Decay ist ein weiteres Problem von C-Style-Arrays.

In diesem Beispiel sehen wir, dass ein paar Zeiger an eine Funktion übergeben ist, Array nur noch durch den Zeiger repräsentiert wird.
Sizeof von diesem Datentyp ist normalerweise acht, weil es sich um einen 64 Bit Zeiger handelt.

int get_size(const int *arr)
{
    return sizeof(arr);
}
TEST(ArrayTest, CStyleArrayPointerDecay) {
    int my_int_array[3];
    EXPECT_EQ(sizeof(my_int_array), 12);
    EXPECT_EQ(get_size(my_int_array), 8); // decays to 64bit pointer
}

Unsicherer Indexzugriff

Auch der Zugriff auf die Daten wie Index Operator ist nicht ungefährlich, weil nicht überprüft wird, ob es sich um einen gültigen Index handelt.

D.h. es fliegt keine Exception sondern das Programm stürzt normalerweise ab.
Wenn man folgenden Code ausführt:

TEST(ArrayTest, CStyleArrayIndex) {
    int my_int_array[3] = {1, 2, 3};
    my_int_array[4] = 1;
    EXPECT_EQ(my_int_array[4], 1);
}

Bekommt man:

Process finished with exit code 134 (interrupted by signal 6:SIGABRT)

std::array – modernes C++

Jetzt wollen wir uns mal anschauen, wie das std::array funktioniert.

Seit C++11 kann man den header <array> inkludieren und bekommt die Möglichkeit, ein array zu definieren,
dass dem C-Style-Array recht ähnlich sieht. Auch der Zugriff auf die Elemente mit dem Index Operator ist identisch:

TEST(ArrayTest, StdArray) {
    std::array<int, 3> my_std_array = {1, 2, 3};

    EXPECT_EQ(my_std_array[0], 1);
    EXPECT_EQ(my_std_array[1], 2);
    EXPECT_EQ(my_std_array[2], 3);

}

Was macht std::array besser?

size()-Funktion

std::array besitzt eine size()-Methode, die die korrekte Größe des Arrays ausgibt:

TEST(ArrayTest, StdArraySize) {
    std::array<int, 3> my_int_array{};
    std::array<int64_t, 3> my_int_64_array{};
    EXPECT_EQ(my_int_array.size(), 3);
    EXPECT_EQ(my_int_64_array.size(), 3);
}

at()-Funktion

Die at()-Methode greift wie der Index-Operator auf das n-te Element zu:

TEST(ArrayTest, StdArrayAt) {
    std::array<int, 3> my_std_array = {1, 2, 3};

    EXPECT_EQ(my_std_array.at(0), 1);
    EXPECT_EQ(my_std_array.at(1), 2);
    EXPECT_EQ(my_std_array.at(2), 3);
}

Auch das Setzen der Elemente geht über die at()-Methode:

TEST(ArrayTest, AddElementsToArrayWithAt) {
    std::array<int, 3> my_array{};
    my_array.at(0) = 1;
    my_array.at(1) = 2;
    my_array.at(2) = 3;
    EXPECT_EQ(my_array[0], 1);
    EXPECT_EQ(my_array[1], 2);
    EXPECT_EQ(my_array[2], 3);
}

Gut ist, dass sie eine Exception wirft, wenn der Zugriff außerhalb des Arrays erfolgt:
Die Exception kann dann über ein try/catch zur Laufzeit gefangen werden.

TEST(ArrayTest, ArrayTestCatchException) {
    std::array<int, 4> my_std_array = {8, 7, 6, 5};

    try
    {
        std::cout << "Element at postion 4: " << my_std_array.at(4) << std::endl;
    }
    catch (const std::out_of_range& ex)
    {
        std::cerr << ex.what() << '\n';
        EXPECT_NE(ex.what(), nullptr);
    }
}

Arrays als Funktionsparameter

void power2(std::span arr)
{
    for (int & i : arr) {
        i *= 2;
    }
}
TEST(ArrayTest, StdArrayFunctionCall) {
    std::array<int, 4> my_std_array = {8, 7, 6, 5};
    power2(my_std_array);
    EXPECT_EQ(my_std_array[0], 16);
}

sort

Da sich ein std::array wie ein normaler STL-Container verhält, lässt sich das array mit std::sort sortieren:

TEST(ArrayTest, StdArraySort) {
    std::array<int, 4> my_std_array = {8, 7, 6, 5};
    std::sort(my_std_array.begin(), my_std_array.end());
    EXPECT_EQ(my_std_array[0], 5);
}

TEST(ArrayTest, StdArraySortWithRanges) {
    std::array<int, 4> my_std_array = {8, 7, 6, 5};
    std::ranges::sort(my_std_array);
    EXPECT_EQ(my_std_array[0], 5);
}

Beispiel aus der Robotik

https://github.com/jboegeholz/udemy_ros2_for_beginners/blob/3c082c605043155b7f617471a50bc3dbf3fa9929/src/my_cpp_pkg/src/led_panel_server.cpp#L47

Kompletter Code

https://github.com/jboegeholz/modern_cpp/blob/master/tests/02_test_std_array.cpp

The post So verwendest du std::array – Modernes C++ appeared first on Creatronix.

So, auf geht’s! Test Driven Development für C++ Projekte.

Google Test (oft auch als gtest abgekürzt) ist ein Test Framework, das von Google entwickelt wurde. 2008 wurde es als Open Source veröffentlicht, seit 2015 findest du es auf github.

Voraussetzungen

Um Google Test in deinen Projekten verwenden zu können, musst du CMake installiert haben. Zudem empfiehlt es sich, dein Projekt mit git zu versionieren, weil du dann Google Test als git Submodul installieren kannst.

Installation

cd my_project
git submodule add https://github.com/google/googletest.git external/googletest
git submodule update --init --recursive

CMake

cmake_minimum_required(VERSION 3.14)
project(my_project)

set(CMAKE_CXX_STANDARD 17)

add_subdirectory(external/googletest)
include(GoogleTest)
enable_testing()

add_executable(google_test_examples tests/00_google_test.cpp)
target_link_libraries(google_test_examples gtest_main)
gtest_discover_tests(google_test_examples)

Code

#include <gtest/gtest.h>

Standard Vergleiche

Standardmäßig vergleicht man gerne auf Gleichheit beziehungsweise Ungleichheit.

TEST(GoogleTestExamples, EXPECT_EQ) {
    const int a = 10;
    const int b = 10;
    EXPECT_EQ(a, b);
}

TEST(GoogleTestExamples, EXPECT_NE) {
    const int a = 10;
    const int b = 11;
    EXPECT_NE(a, b);
}

Auch bool’sche Ausdrücke lassen sich vergleichen, auf true oder false. Das wäre aber auch schon mit dem eingebauten Assert direkt in C++ möglich. Deswegen schauen wir uns spannendere Testfälle an:

Float und double vergleichen

TEST(GoogleTestExamples, EXPECT_FLOAT_EQ) {
    const float a = 10.0;
    const float b = 10.000001;
    EXPECT_FLOAT_EQ(a, b);
}

TEST(GoogleTestExamples, EXPECT_DOUBLE_EQ) {
    const float a = 10.0;
    const float b = 10.0000001;
    EXPECT_DOUBLE_EQ(a, b);
}

Exceptions testen

Schön ist es, dass Google Test auch das Testen von Exceptions unterstützt:

TEST(GoogleTestExamples, ArrayException) {
    constexpr std::array<int, 3> my_array = {1,2,3};
    EXPECT_THROW((void)my_array.at(10), std::out_of_range);
}

SIGABRT testen

void double_unique_ptr() {
    auto * p = new int(10);
    const std::unique_ptr<int> ptr1 {p};
    const std::unique_ptr<int> ptr2 {p};
}
TEST(MyUniquePointer, DoubleUniquePointer) {
    EXPECT_DEATH(double_unique_ptr(), ".*");
}

std::out abfangen

Wenn wir Code schreiben, der auf std::out schreibt, können wir mit CaptureStdoutdie Ausgabe abfangen:

#include <span>
#include <iostream>
#include <gtest/gtest.h>

void print(const std::span<const int> values) {
    for (const int v : values) {
        std::cout << v << " ";
    }
}
TEST(SpanTest, StdPrintExtrapolation) {
    testing::internal::CaptureStdout();

    const int arr[] = {1, 2, 3, 4, 5};
    print(arr);

    const std::string output = testing::internal::GetCapturedStdout();
    EXPECT_EQ(output, "1 2 3 4 5 ");
}

Test Fixtures

Wenn man schon etwas Erfahrung mit dem Erstellen von Tests hat, genießt man Features wie Test Fixtures.

Ein Test Fixture ist eine Methode, wie man für eine Vielzahl von Tests die Startbedingungen festlegen kann. Variablen initialisieren und Objekte instantiieren beispielsweise.

In klassischen Testframeworks wie JUnit oder auch Python Unittest muss man dafür die Setup-Methode der Testklasse verwenden. In modernen Testframeworks wie pytest, sind fixtures freistehende Funktionen.

In Google Test besteht ein Fixture aus einer Klasse die von ::testing::Test erbt und die SetUp()-Methode überschreibt.

class TestFixture : public ::testing::Test {
protected:
    void SetUp() override {
        speed = 100;
    }

    int speed{};
};

Dann können wir mit dem Test-Makro TEST_F das Fixture verwenden:

TEST_F(TestFixture, IncreasesSpeed) {
    speed += 50;
    EXPECT_EQ(speed, 150);
}

TEST_F(TestFixture, DecreasesSpeed) {
    speed -= 30;
    EXPECT_EQ(speed, 70);
}

Parametrisierte Tests

Parametrisierung Tests sind ein sehr wertvolles Werkzeug, gerade wenn man TDD benutzt, um seine Programme zu schreiben.
Bei the Rule of three führt man normalerweise eine Optimierung durch, sobald man dreimal das Gleiche getan hat.
Oft ist das der Aufruf einer neuen Funktion mit einem dritten Parameter.

Deshalb könnte dann hier ein parametrisierter Test drei Testfälle ersetzen.

class AbsTest : public ::testing::TestWithParam<std::pair<int, int>> {
    // no setup needed
};

TEST_P(AbsTest, ComputesAbsoluteValue) {
    int input = GetParam().first;
    int expected = GetParam().second;

    EXPECT_EQ(std::abs(input), expected);
}

INSTANTIATE_TEST_SUITE_P(
    AbsValues,
    AbsTest,
    ::testing::Values(
        std::make_pair(-3, 3),
        std::make_pair(-1, 1),
        std::make_pair(0, 0),
        std::make_pair(2, 2)
    )
);

Tests ausführen

Um die Tests auszuführen, wechseln wir in das Build-Verzeichnis und starten die Tests über ctest:

cd cmake-build-debug
ctest

Test Reports erstellen

In größeren Projekten wird gerne für die Weiterverarbeitung ein Report in HTML oder XML erwartet,
der sich zum Beispiel für den Import in ein Quality Gate Tool wie Sonar Cube eignet.
In Google Test erreicht man dies, in dem man ctest so ausführt:

ctest --output-junit test-report.xml

Übersicht Test Makros

Fazit

Google Test ist ein angenehmes Test-Framework mit einer entspannten Lernkurve.
Die Integration in moderne IDEs wie Jetbrains CLion ist ein weiterer Pluspunkt.
Den gesamten Code findest du hier: https://github.com/jboegeholz/modern_cpp/blob/master/tests/00_google_test.cpp

Weiterführende Links

https://creatronix.de/software-testing-concepts/
https://creatronix.de/wie-tdd-die-welt-rettet-und-deine-nerven-schont/
https://creatronix.de/wie-baue-ich-eine-entwicklungsbegleitende-software-qualitatssicherung-auf/

The post So verwendest du Google Test in deinem C++-Projekt appeared first on Creatronix.