bg_image
header

PEST

PEST ist ein moderner Testing-Framework für PHP, das vor allem durch seine lesbare Syntax, Expressivität und enge Integration mit PHPUnit besticht.

📌 PEST = "PHP Testing for Humans"
Es richtet sich an Entwickler, die saubere, lesbare und schnelle Tests schreiben wollen – ohne viel Boilerplate.


🚀 Warum PEST statt PHPUnit?

PEST basiert auf PHPUnit, aber es:

  • bietet eine minimalistische, expressive Syntax

  • entfernt unnötigen Overhead

  • unterstützt funktionalen, verhaltensbasierten Teststil

  • lässt sich optional mit einer klassischen PHPUnit-Struktur kombinieren


🔍 Beispiel – PHPUnit vs. PEST

PHPUnit:

class UserTest extends TestCase
{
    public function test_user_has_name()
    {
        $user = new User('John');
        $this->assertEquals('John', $user->name);
    }
}

PEST:

it('has a name', function () {
    $user = new User('John');
    expect($user->name)->toBe('John');
});

👉 Deutlich kürzer, besser lesbar – besonders bei vielen Tests.


🧩 Features von PEST

  • ✅ Elegante Syntax (ähnlich wie Jest oder Mocha in JavaScript)

  • 🧪 Unterstützt unit, feature, API, browser-based Tests

  • 🧱 Datengetriebene Tests (with([...]))

  • 🧬 Test-Hooks wie beforeEach() / afterEach()

  • 🎨 Erweiterbar über Plugins & eigene Expectations

  • 🔄 Kompatibel mit PHPUnit (du kannst PHPUnit-Tests weiter nutzen)


🛠️ Installation

In einem Laravel- oder Composer-Projekt:

composer require pestphp/pest --dev
php artisan pest:install  # (für Laravel-Projekte)

Dann kannst du direkt loslegen:

./vendor/bin/pest

🧠 Fazit

PEST ist ideal, wenn du:

  • Tests schreiben willst, die Spaß machen

  • sauberen, modernen Code bevorzugst

  • bereits PHPUnit nutzt, aber Lust auf mehr Expressivität hast

💡 Viele moderne Laravel-Entwickler steigen auf PEST um, weil es sich perfekt in Laravel-Apps integriert und das Testen „menschlich“ macht – wie der Slogan schon sagt.


GitHub Actions

GitHub Actions ist ein Feature von GitHub, mit dem du automatisierte Workflows für deine Softwareprojekte erstellen kannst – direkt im GitHub-Repository.


🛠️ Was kann man mit GitHub Actions machen?

Du kannst CI/CD-Pipelines (Continuous Integration / Continuous Deployment) aufbauen, z. B.:

  • Code automatisch testen (z. B. mit PHPUnit, Jest, Pytest)

  • 🛠️ Code bei jedem Push oder Pull Request builden

  • 🚀 Software automatisch deployen (z. B. auf einen Webserver, in die Cloud, zu DockerHub)

  • 📦 Releases erstellen (z. B. ZIP-Dateien, Versionstags)

  • 🔄 Cronjobs oder geplante Tasks laufen lassen


🧱 Wie funktioniert es?

GitHub Actions basiert auf sogenannten Workflows, die du in einer Datei definierst:

  • Die Datei heißt z. B. .github/workflows/ci.yml

  • Sie ist im YAML-Format

  • Du definierst Events (z. B. push, pull_request) und Jobs (z. B. build, test)

  • Jobs bestehen aus Steps, die Befehle oder Aktionen ausführen

Beispiel: Einfacher CI-Workflow für Node.js

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '20'
      - run: npm install
      - run: npm test

🧩 Was sind "Actions"?

Eine Action ist ein einzelner Schritt, den man in einem Workflow ausführt. Es gibt:

  • Vorgefertigte Actions (z. B. actions/checkout, setup-node, upload-artifact)

  • Eigene Actions (z. B. Shell-Skripte oder Docker-Container)

Du kannst Actions im GitHub Marketplace finden und nutzen.


💡 Warum ist das nützlich?

  • Spart manuelle Arbeit

  • Verbessert Codequalität (durch automatisierte Tests)

  • Macht Deployments reproduzierbar

  • Alles direkt in GitHub – kein externer CI-Dienst nötig (wie Jenkins oder Travis CI)


Happy Path

Der "Happy Path" (auch "Happy Flow" genannt) bezeichnet in der Softwareentwicklung oder im Testing den idealen Ablauf eines Prozesses oder Programms, bei dem alles wie geplant funktioniert, keine Fehler auftreten und alle Eingaben gültig sind.

Beispiel:

Wenn du z. B. ein Online-Formular zur Registrierung entwickelst, sieht der Happy Path so aus:

  1. Der Benutzer gibt alle Daten korrekt ein (z. B. gültige E-Mail, sicheres Passwort).

  2. Er klickt auf „Registrieren“.

  3. Das System erstellt erfolgreich einen Account.

  4. Der Benutzer wird zur Willkommensseite weitergeleitet.

➡️ Keine Validierungsfehler, keine Serverprobleme, kein unerwartetes Verhalten.


Wozu dient der Happy Path?

  • Erstes Testziel: Beim Entwickeln oder Testen schaut man sich oft zuerst den Happy Path an, um sicherzugehen, dass das Grundgerüst funktioniert.

  • Basis für Use Cases: In der Dokumentation von Anforderungen oder Prozessen ist der Happy Path oft der zentrale Anwendungsfall, bevor man Sonderfälle beschreibt.

  • Abgrenzung zu Edge Cases / Error Paths: Alles, was vom Happy Path abweicht (z. B. leeres Passwortfeld, Serverfehler), gehört zu den „unhappy paths“ oder „alternate flows“.

 


Partial Mock

Ein Partial Mock (teilweises Mocking) ist eine Technik beim Testen von Software, bei der nur ein Teil eines Objekts durch ein Mock ersetzt wird, während der Rest der echten Implementierung erhalten bleibt. Dies ist besonders nützlich, wenn du nur bestimmte Methoden eines Objekts stubben oder mocken möchtest, während andere Methoden normal ausgeführt werden.

Wann wird ein Partial Mock verwendet?

  • Wenn du eine Klasse testen möchtest, aber bestimmte Methoden von ihr isolieren musst.

  • Wenn einige Methoden schwer zu testen sind (z. B. weil sie externe Abhängigkeiten haben), aber andere weiterhin mit ihrer echten Logik arbeiten sollen.

  • Wenn du nur einige Methoden stubben möchtest, um den Testablauf zu steuern.

Beispiel in PHP mit PHPUnit

Angenommen, du hast eine Klasse Calculator, aber möchtest die Methode multiply() mocken, während add() normal funktioniert.

class Calculator {
    public function add($a, $b) {
        return $a + $b;
    }

    public function multiply($a, $b) {
        return $a * $b;
    }
}

// PHPUnit Test mit Partial Mock
class CalculatorTest extends \PHPUnit\Framework\TestCase {
    public function testPartialMock() {
        // Partial Mock von Calculator
        $calculator = $this->getMockBuilder(Calculator::class)
                           ->onlyMethods(['multiply']) // Nur diese Methode mocken
                           ->getMock();

        // Definiere Verhalten für multiply()
        $calculator->method('multiply')->willReturn(10);

        // Teste echte Methode add()
        $this->assertEquals(5, $calculator->add(2, 3));

        // Teste gemockte Methode multiply()
        $this->assertEquals(10, $calculator->multiply(2, 3));
    }
}

Hier bleibt add() unverändert und arbeitet mit der echten Implementierung, während multiply() immer 10 zurückgibt.

Fazit

Partial Mocks sind nützlich, wenn du Teile einer Klasse isolieren möchtest, ohne sie vollständig zu ersetzen. Sie helfen, Tests stabiler und effizienter zu machen, indem nur bestimmte Methoden gemockt werden.


System Under Test - SUT

Ein SUT (System Under Test) ist das System oder die Komponente, die in einem Testprozess geprüft wird. Der Begriff wird häufig in der Softwareentwicklung und Qualitätssicherung verwendet.

Bedeutung und Anwendung:

  • In Softwaretests bezeichnet der SUT das gesamte Programm, ein einzelnes Modul oder eine spezifische Funktion, die getestet wird.
  • In Hardwaretests kann der SUT ein elektronisches Gerät oder eine Maschine sein, die überprüft wird.
  • In automatisierten Tests wird der SUT oft mit Testframeworks und Tools getestet, um Fehler oder unerwartetes Verhalten zu identifizieren.

Ein typischer Testprozess umfasst:

  1. Definition der Testfälle basierend auf den Anforderungen.
  2. Ausführung der Tests auf dem SUT.
  3. Überprüfung der Testergebnisse und Abgleich mit den erwarteten Werten.

 


Jest

Jest ist ein JavaScript-Testing-Framework, das von Meta (Facebook) entwickelt wurde. Es wird hauptsächlich zum Testen von JavaScript- und TypeScript-Anwendungen verwendet, insbesondere für React-Anwendungen, eignet sich aber auch für Node.js-Backends.

Hauptmerkmale von Jest:

  • Einfache Konfiguration: Jest funktioniert oft "out of the box", ohne komplizierte Einrichtung.
  • Schnelligkeit: Es verwendet Parallelisierung und intelligentes Caching, um Tests schnell auszuführen.
  • Snapshot-Tests: Ideal für UI-Tests, um sicherzustellen, dass sich die Darstellung nicht unerwartet ändert.
  • Mocking & Spying: Ermöglicht das Ersetzen von Abhängigkeiten durch Mock-Funktionen.
  • Code-Coverage-Berichte: Zeigt an, wie viel Code durch Tests abgedeckt ist.

Beispiel für einen einfachen Test mit Jest:

// sum.js
function sum(a, b) {
  return a + b;
}
module.exports = sum;

// sum.test.js
const sum = require('./sum');

test('addiert 1 + 2 und ergibt 3', () => {
  expect(sum(1, 2)).toBe(3);
});

Um den Test auszuführen, nutzt du:

jest

Oder falls du es in einem Projekt installiert hast:

npx jest

Pyramid Web Framework

Das Pyramid Web Framework ist ein leichtgewichtiges, flexibles und skalierbares Web-Framework für Python. Es gehört zur Pylons-Projektfamilie und ist besonders für Entwickler geeignet, die eine minimalistische, aber dennoch leistungsfähige Lösung für Webanwendungen suchen.

Hauptmerkmale von Pyramid:

  1. Minimalistisch, aber erweiterbar

    • Pyramid bietet eine schlanke Kernarchitektur, die nur grundlegende Funktionen enthält. Erweiterungen können bei Bedarf hinzugefügt werden.
  2. Flexibel

    • Es unterstützt verschiedene Datenbanken, Authentifizierungssysteme und Templates (z. B. Jinja2, Chameleon, Mako).
  3. Traversal und URL Mapping

    • Pyramid erlaubt sowohl herkömmliches URL-Routing (ähnlich Flask/Django) als auch ein leistungsfähiges Traversal-System, das sich besonders für hierarchische Datenstrukturen eignet.
  4. Leistungsstark und effizient

    • Dank seiner modularen Struktur ist Pyramid auch für große Projekte geeignet, bleibt aber ressourcenschonend.
  5. First-Class Testing Support

    • Pyramid ist auf Testbarkeit ausgelegt und enthält eingebaute Unterstützung für Unit- und Integrationstests.
  6. Gute Dokumentation und Community-Support

    • Die offizielle Dokumentation ist umfassend, und es gibt eine aktive Community.

Wann sollte man Pyramid verwenden?

  • Wenn man ein leichtgewichtiges, aber dennoch skalierbares Framework sucht.
  • Wenn man volle Kontrolle über die Architektur der Anwendung haben möchte.
  • Wenn man ein Projekt mit komplexen URL-Strukturen oder hierarchischen Daten entwickelt.
  • Wenn man Django zu groß und Flask zu einfach findet.

Vergleich mit anderen Frameworks:

Feature Pyramid Flask Django
Architektur Minimalistisch & modular Minimalistisch & leicht Monolithisch & feature-reich
Routing URL Mapping & Traversal URL Mapping URL Mapping
Skalierbarkeit Hoch Mittel Hoch
Built-in Features Wenige, aber erweiterbar Sehr wenige Viele (ORM, Admin, Auth, etc.)
Lernkurve Mittel Einfach Höher

Fazit

Pyramid ist eine großartige Wahl für Entwickler, die eine Balance zwischen Minimalismus und Leistungsfähigkeit suchen. Es eignet sich besonders für mittelgroße bis große Webprojekte, bei denen Skalierbarkeit, Flexibilität und eine gute Testbarkeit wichtig sind.


A B Testing

A/B-Testing ist eine Methode im Marketing, Webdesign und Softwareentwicklung, um die Wirkung von zwei oder mehr Varianten eines Elements miteinander zu vergleichen, um herauszufinden, welche besser funktioniert.

Wie funktioniert A/B-Testing?

  1. Aufteilung der Zielgruppe: Die Zielgruppe wird in zwei (oder mehr) Gruppen aufgeteilt. Eine Gruppe (Gruppe A) sieht die ursprüngliche Version (Kontrollgruppe), während die andere Gruppe (Gruppe B) eine alternative Version (Testgruppe) sieht.

  2. Änderungen testen: Es wird jeweils nur eine bestimmte Variable geändert, z. B. die Farbe eines Buttons, die Überschrift, der Preis oder das Layout.

  3. Messung der Ergebnisse: Das Verhalten der Nutzer wird analysiert, z. B. Klickrate, Conversion-Rate oder Verweildauer. Das Ziel ist es, herauszufinden, welche Version zu besseren Ergebnissen führt.

  4. Datenanalyse: Die Ergebnisse werden statistisch ausgewertet, um sicherzustellen, dass die Unterschiede signifikant sind und nicht zufällig.

Beispiele für A/B-Tests:

  • Websites: Testen von zwei verschiedenen Landing Pages, um herauszufinden, welche mehr Leads generiert.
  • E-Mails: Vergleich von Betreffzeilen, um zu sehen, welche zu mehr Öffnungen führt.
  • Apps: Änderungen in der Benutzeroberfläche (UI) testen, um die Benutzerfreundlichkeit zu verbessern.

Vorteile:

  • Liefert datenbasierte Entscheidungen.
  • Minimiert Risiken bei Design- oder Funktionsänderungen.
  • Steigert Conversion-Rates und Effizienz.

Nachteile:

  • Kann zeitaufwändig sein, wenn Daten nicht schnell gesammelt werden.
  • Ergebnisse sind nicht immer eindeutig, besonders bei kleinen Stichproben.
  • Der Test kann durch externe Faktoren beeinflusst werden.

 


Zyklomatische Komplexitaet

Die zyklomatische Komplexität ist eine Kennzahl zur Bewertung der Komplexität eines Programmcodes oder eines Softwaremoduls. Sie misst die Anzahl der unabhängigen Ausführungspfade in einem Programm, basierend auf seiner Kontrollflussstruktur. Diese Metrik wurde von Thomas J. McCabe entwickelt und hilft, die Testbarkeit, Wartbarkeit und Fehleranfälligkeit eines Programms einzuschätzen.

Berechnung der Zyklomatischen Komplexität

Die zyklomatische Komplexität V(G)V(G) lässt sich mithilfe des Kontrollflussgraphen eines Programms berechnen. Dieser Graph besteht aus Knoten (für Anweisungen oder Blöcke) und Kanten (für die Kontrollflusswege zwischen den Blöcken). Die Formel lautet:

V(G)=E−N+2PV(G) = E - N + 2P

  • EE: Anzahl der Kanten im Graphen.
  • NN: Anzahl der Knoten im Graphen.
  • PP: Anzahl der verbundenen Komponenten (in einem zusammenhängenden Graphen ist P=1P = 1).

In der Praxis wird oft eine vereinfachte Berechnung verwendet, bei der die Anzahl der Verzweigungspunkte (wie If-, While-, For-Schleifen) addiert wird.

Interpretation der zyklomatischen Komplexität

Die zyklomatische Komplexität gibt Auskunft darüber, wie viele Testfälle mindestens nötig sind, um jeden Pfad im Programm einmal zu durchlaufen. Eine höhere zyklomatische Komplexität deutet auf einen komplexeren und möglicherweise fehleranfälligeren Code hin.

Typische Wertebereiche und deren Bedeutung:

  • 1-10: Geringe Komplexität, gut testbar und wartbar.
  • 11-20: Moderate Komplexität, der Code wird schwieriger zu verstehen und zu testen.
  • 21-50: Hohe Komplexität, der Code ist schwer zu testen und fehleranfällig.
  • 50+: Sehr hohe Komplexität, starker Hinweis auf einen notwendigen Code-Refactoring-Prozess.

Nutzen der zyklomatischen Komplexität

Durch die Messung der zyklomatischen Komplexität können Entwickler frühzeitig potenzielle Wartungsprobleme identifizieren und gezielt Bereiche des Codes für Vereinfachung und Refactoring auswählen.

 


Captain Hook

CaptainHook ist ein Git-Hook-Manager für PHP, der es Entwicklern ermöglicht, automatisierte Aufgaben im Zusammenhang mit Git-Repositories durchzuführen. Es erleichtert das Einrichten und Verwalten von Git-Hooks, also Skripten, die zu bestimmten Zeitpunkten im Git-Workflow automatisch ausgeführt werden (z. B. vor dem Committen oder Pushen von Code). Dies ist besonders nützlich, um Codestandards durchzusetzen, Tests laufen zu lassen, Commit-Nachrichten zu überprüfen oder fehlerhaften Code zu verhindern.

CaptainHook lässt sich einfach über Composer in Projekte integrieren und bietet Flexibilität, um benutzerdefinierte Hooks und Plugins zu erstellen. Es unterstützt verschiedene PHP-Versionen, wobei die neueste Version PHP 8.0 erfordert​.