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 objektorientiertes Datenbanksystem (OODBMS) ist ein Datenbanksystem, das die Prinzipien der objektorientierten Programmierung (OOP) mit den Funktionalitäten einer Datenbank kombiniert. Es ermöglicht das Speichern, Abrufen und Verwalten von Daten in Form von Objekten, wie sie in objektorientierten Programmiersprachen (z. B. Java, Python oder C++) definiert werden.
Objektmodell:
Klassen und Vererbung:
Kapselung:
Persistenz:
Identität:
Komplexe Datentypen:
Objektorientierte Datenbanken sind besonders nützlich, wenn es darum geht, mit komplexen, hierarchischen oder verschachtelten Datenstrukturen zu arbeiten, wie sie in vielen modernen Softwareprojekten vorkommen.
Duplicate Code (auf Deutsch: "doppelter Code" oder "Code-Duplizierung") bezeichnet das mehrfache Vorhandensein identischer oder sehr ähnlicher Codeabschnitte in einem Programm. Es wird als schlechte Praxis angesehen, weil es zu Problemen in der Wartbarkeit, Lesbarkeit und Fehleranfälligkeit des Codes führen kann.
1. Exakter Duplikat: Der Code ist vollständig identisch. Dies tritt häufig auf, wenn ein Entwickler denselben Code kopiert und an mehreren Stellen einfügt.
Beispiel:
def calculate_area_circle(radius):
return 3.14 * radius * radius
def calculate_area_sphere(radius):
return 3.14 * radius * radius # Identischer Code2. Strukturelle Duplikate: Der Code ist nicht exakt gleich, aber in seiner Struktur und Funktionalität ähnlich. Lediglich Variablen oder Namen wurden geändert.
Beispiel:
def calculate_area_circle(radius):
return 3.14 * radius * radius
def calculate_area_square(side):
return side * side # Ähnlich strukturiert3. Logische Duplikate: Der Code macht funktional das Gleiche, sieht aber syntaktisch unterschiedlich aus.
Beispiel:
def calculate_area_circle(radius):
return 3.14 * radius ** 2
def calculate_area_circle_alt(radius):
return 3.14 * radius * radius # Funktional gleich, aber anderer Stil1. Refactoring: Ähnlichen oder identischen Code in eine gemeinsame Funktion oder Methode auslagern.
Beispiel:
def calculate_area(shape, dimension):
if shape == 'circle':
return 3.14 * dimension * dimension
elif shape == 'square':
return dimension * dimension2. Modularisierung: Funktionen und Klassen verwenden, um Wiederholungen zu reduzieren.
3. DRY-Prinzip anwenden: "Don't Repeat Yourself" – Entwickle so, dass keine Information oder Logik doppelt implementiert wird.
4. Tools verwenden: Tools wie SonarQube oder CodeClimate können Duplicate Code automatisch erkennen.
Duplicate Code zu reduzieren, verbessert die Codequalität, erleichtert die Wartung und minimiert das Risiko von Fehlern in der Software.
PSR-12 ist ein Standard der PHP-Fig (PHP Framework Interoperability Group), der Coding-Style-Guidelines für PHP definiert. Es baut auf PSR-1 (Basic Coding Standard) und PSR-2 (Coding Style Guide) auf und erweitert diese, um modernere Anforderungen und Best Practices zu berücksichtigen.
PSR-12 zielt darauf ab, einen einheitlichen und lesbaren Code-Stil für PHP-Projekte zu schaffen. Dies erleichtert die Zusammenarbeit zwischen Entwicklern und sorgt für Konsistenz in der Codebasis.
namespace-Deklaration muss eine Leerzeile stehen.use-Anweisungen werden nach der namespace-Deklaration gruppiert.namespace App\Controller;
use App\Service\MyService;
use Psr\Log\LoggerInterface;{ einer Klasse oder Methode steht in der nächsten Zeile.public, protected, private) sind bei allen Methoden und Eigenschaften zwingend erforderlich.class MyClass
{
private string $property;
public function myMethod(): void
{
// code
}
}public function myFunction(
int $param1,
string $param2
): string {
return 'example';
}{ muss in derselben Zeile wie die Kontrollstruktur stehen.if ($condition) {
// code
} elseif ($otherCondition) {
// code
} else {
// code
}[]) geschrieben werden.$array = [
'first' => 'value1',
'second' => 'value2',
];? vor dem Typ deklariert.public function getValue(?int $id): ?string
{
return $id !== null ? (string) $id : null;
}<?php-Tag beginnen und dürfen kein schließendes ?>-Tag enthalten.PSR-12 erweitert PSR-2 um:
PSR-12 ist der Standard für modernen und konsistenten PHP-Code. Es bringt Klarheit und Struktur in PHP-Projekte, besonders bei Teams, die gemeinsam an einer Codebasis arbeiten. Mit Tools wie PHP_CodeSniffer oder PHP-CS-Fixer kannst du PSR-12 problemlos einhalten.
PSR-4 ist eine PHP-Standard-Empfehlung für das Autoloading von Klassen basierend auf Namespaces und Dateipfaden. Dieser Standard wurde von der PHP-FIG (PHP Framework Interop Group) entwickelt und beschreibt, wie vollständig qualifizierte Klassennamen zu den entsprechenden Dateipfaden gemappt werden. Dadurch kann PHP Klassen automatisch finden und laden, ohne dass manuelle require- oder include-Anweisungen nötig sind.
Namespace-Zuordnung: PSR-4 verlangt, dass der Namespace und Klassenname mit der Verzeichnisstruktur und dem Dateinamen übereinstimmen. Jeder Namespace-Präfix wird mit einem Basisverzeichnis verknüpft, und innerhalb dieses Verzeichnisses entspricht die Verzeichnisstruktur dem Namespace.
Basisverzeichnis: Für jeden Namespace-Präfix wird ein Basisverzeichnis definiert, und die Klassen werden in Unterverzeichnissen des Basisverzeichnisses entsprechend ihrer Namespace-Struktur abgelegt. Zum Beispiel:
App\Controllers ist, sollte die Datei in einem Verzeichnis wie /path/to/project/src/Controllers liegen.Dateibenennung: Der Klassenname muss genau mit dem Dateinamen übereinstimmen und mit .php enden.
Kompatibilität mit Autoloadern: Die Implementierung von PSR-4 gewährleistet Kompatibilität mit modernen Autoloadern wie dem von Composer, wodurch PHP Klassen automatisch ohne manuelle Einbindung findet.
Angenommen, Sie haben die Klasse App\Controllers\UserController, so sollte die Verzeichnisstruktur wie folgt aussehen:
/path/to/project/src/Controllers/UserController.php
In der composer.json von Composer wird diese Zuordnung wie folgt angegeben:
{
"autoload": {
"psr-4": {
"App\\": "src/"
}
}
}Dies weist Composer an, die Klassen im App-Namespace aus dem src/-Verzeichnis zu laden. Wenn Sie composer dump-autoload ausführen, wird Composer das Autoloading gemäß dem PSR-4-Standard konfigurieren.
PSR-4 hat den älteren PSR-0-Standard abgelöst und ist nun der bevorzugte Autoloading-Standard für moderne PHP-Projekte.
Monolog ist eine weit verbreitete Logging-Bibliothek für PHP, die das PSR-3-Standardinterface für Logs implementiert und so kompatibel mit PSR-3-konformen Frameworks und Anwendungen ist. Monolog bietet eine einfache und flexible Möglichkeit, Logs in verschiedenen Zielsystemen zu speichern und zu verwalten. Entwickler können damit Fehler, Warnungen oder allgemeine Informationen in PHP-Anwendungen protokollieren und so das Debugging und die Wartung ihrer Anwendungen verbessern.
Logger Instanz: Monolog erstellt einen Logger über die Logger-Klasse. Die Logger-Instanz unterstützt verschiedene Log-Level (z. B. debug, info, warning, error), die in PHP-Programmen genutzt werden können, um verschiedene Schweregrade von Log-Nachrichten zu erfassen.
Handler: Ein Herzstück von Monolog ist das Konzept der Handler. Handler steuern, wohin und wie die Log-Einträge gespeichert werden. Monolog unterstützt zahlreiche Handler, darunter:
Formatter: Handler können mit Formatters kombiniert werden, um den Inhalt der Logs anzupassen. Monolog bietet verschiedene Formatierer, die z. B. die Logs im JSON-Format ausgeben können oder einfach nur die grundlegende Textausgabe formatieren.
Processor: Neben Handlern und Formattern erlaubt Monolog auch den Einsatz von Prozessoren, die zusätzliche Daten an die Log-Einträge anhängen, z. B. Kontextinformationen wie User-Daten oder die aktuelle IP-Adresse.
Hier ein einfaches Beispiel zur Initialisierung und Nutzung eines Monolog-Loggers:
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
$logger = new Logger('name');
$logger->pushHandler(new StreamHandler(__DIR__.'/app.log', Logger::WARNING));
// Log-Meldung erstellen
$logger->warning('Dies ist eine Warnung');
$logger->error('Dies ist ein Fehler');Monolog ist eine der am häufigsten eingesetzten Logging-Bibliotheken in PHP, vor allem in Kombination mit Symfony, Laravel und anderen PHP-Frameworks.
PSR-2 ist eine Richtlinie für den Programmierstil in PHP, die von der PHP-Fig (Framework Interop Group) als Empfehlung erstellt wurde. Die Abkürzung „PSR“ steht für „PHP Standards Recommendation“. PSR-2 wurde speziell entwickelt, um den Code lesbarer und einheitlicher zu machen, sodass verschiedene Entwicklerteams besser zusammenarbeiten können.
{ für Klassen und Methoden gehört in die nächste Zeile, die für Kontrollstrukturen wie if oder for in dieselbe Zeile.=, +, etc., wird ein Leerzeichen verwendet.Hier ist ein einfaches Beispiel, das die Richtlinien zeigt:
<?php
namespace Vendor\Package;
class ExampleClass
{
public function exampleMethod($arg1, $arg2 = null)
{
if ($arg1 === $arg2) {
throw new \Exception('Arguments cannot be equal');
}
return $arg1;
}
}PSR-2 wurde inzwischen von PSR-12 erweitert und ersetzt, das zusätzliche Regeln zur Verbesserung der Code-Konsistenz einführt.
PSR-1 ist eine PHP-Standards-Empfehlung (PHP Standards Recommendation), die von der PHP-FIG (Framework Interop Group) erstellt wurde. Sie definiert grundlegende Codierungsstandards für PHP, um die Interoperabilität zwischen verschiedenen PHP-Projekten und -Frameworks zu gewährleisten. Das Ziel von PSR-1, auch als "Basic Coding Standard" bezeichnet, ist es, eine konsistente Grundlage für PHP-Code zu schaffen, was die Lesbarkeit und Zusammenarbeit bei Projekten im PHP-Ökosystem erleichtert. Die Hauptpunkte von PSR-1 umfassen:
Dateiformatierung:
<?php oder <?= Tags verwenden.Namensräume und Klassennamen:
StudlyCaps-Stil (PascalCase) deklariert werden.Konstanten-, Eigenschaften- und Methodennamen:
CONST_VALUE).camelCase-Stil geschrieben werden.Autoloading:
include- oder require-Anweisungen zu vermeiden.PSR-1 gilt als grundlegender Standard und ergänzt PSR-2 und PSR-12, die detailliertere Codeformatierungsrichtlinien festlegen. Zusammen verbessern diese Standards die Lesbarkeit und Konsistenz von PHP-Projekten.
Eine Entity ist ein zentrales Konzept im Bereich der Softwareentwicklung, insbesondere im Domain-Driven Design (DDD). Es beschreibt ein Objekt oder einen Datensatz, der eine eindeutige Identität besitzt und im Laufe der Zeit seinen Zustand ändern kann. Die Identität einer Entity bleibt dabei immer bestehen, unabhängig davon, wie sich die Eigenschaften der Entity verändern.
Eindeutige Identität: Jede Entity hat eine eindeutige Kennung (z.B. eine ID), die sie von anderen Entities unterscheidet. Diese Identität ist das primäre Unterscheidungsmerkmal und bleibt über den gesamten Lebenszyklus der Entity gleich.
Veränderlicher Zustand: Im Gegensatz zu einem Value Object kann sich der Zustand einer Entity ändern. Zum Beispiel können sich die Eigenschaften eines Kunden (Name, Adresse) ändern, aber der Kunde bleibt durch seine Identität immer derselbe.
Geschäftslogik: Entities enthalten oft Geschäftslogik, die mit ihrem Verhalten und Zustand in der Domäne zusammenhängt.
Stellen wir uns eine Kunden-Entity in einem E-Commerce-System vor. Diese Entity könnte folgende Eigenschaften haben:
Wenn sich die Adresse oder der Name des Kunden ändert, bleibt die Entity durch ihre ID immer derselbe Kunde. Das ist der wesentliche Unterschied zu einem Value Object, das keine dauerhafte Identität hat.
Entities werden oft in Datenbanken durch Tabellen abgebildet, wobei die eindeutige Identität in Form eines Primärschlüssels gespeichert wird. In einem Objektmodell einer Programmiersprache wird die Entity durch eine Klasse oder ein Objekt dargestellt, das die Logik und den Zustand dieser Entität verwaltet.
Exakat ist ein statisches Analyse-Tool für PHP, das speziell entwickelt wurde, um die Codequalität zu verbessern und Best Practices in PHP-Projekten sicherzustellen. Ähnlich wie Psalm konzentriert es sich auf die Analyse von PHP-Code, bietet jedoch einige einzigartige Funktionen und Analysen, um Entwicklern zu helfen, Fehler zu erkennen und ihre Anwendungen effizienter und sicherer zu machen.
Hier sind einige der Hauptfunktionen von Exakat:
Exakat kann als eigenständiges Tool oder in eine Continuous Integration (CI)-Pipeline integriert werden, um sicherzustellen, dass Code kontinuierlich auf Qualität und Sicherheit überprüft wird. Es ist ein vielseitiges Werkzeug für PHP-Entwickler, die ihren Code verbessern und auf einem hohen Standard halten möchten.
jQuery
