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.
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
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.
✅ 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)
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
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 ist ein Feature von GitHub, mit dem du automatisierte Workflows für deine Softwareprojekte erstellen kannst – direkt im GitHub-Repository.
Du kannst CI/CD-Pipelines (Continuous Integration / Continuous Deployment) aufbauen, z. B.:
🛠️ 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
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
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
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.
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)
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.
Wenn du z. B. ein Online-Formular zur Registrierung entwickelst, sieht der Happy Path so aus:
Der Benutzer gibt alle Daten korrekt ein (z. B. gültige E-Mail, sicheres Passwort).
Er klickt auf „Registrieren“.
Das System erstellt erfolgreich einen Account.
Der Benutzer wird zur Willkommensseite weitergeleitet.
➡️ Keine Validierungsfehler, keine Serverprobleme, kein unerwartetes Verhalten.
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“.
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.
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.
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.
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.
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.
Ein typischer Testprozess umfasst:
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.
// 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 jestDas 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.
Minimalistisch, aber erweiterbar
Flexibel
Traversal und URL Mapping
Leistungsstark und effizient
First-Class Testing Support
Gute Dokumentation und Community-Support
| 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 |
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 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.
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.
Änderungen testen: Es wird jeweils nur eine bestimmte Variable geändert, z. B. die Farbe eines Buttons, die Überschrift, der Preis oder das Layout.
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.
Datenanalyse: Die Ergebnisse werden statistisch ausgewertet, um sicherzustellen, dass die Unterschiede signifikant sind und nicht zufällig.
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.
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
In der Praxis wird oft eine vereinfachte Berechnung verwendet, bei der die Anzahl der Verzweigungspunkte (wie If-, While-, For-Schleifen) addiert wird.
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.
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.
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.