Unit Tests sind in Shopware-Projekten kein Selbstzweck. Sie sind vor allem ein Schutz gegen leise Regressionen. Gerade bei Plugins, individuellen Regeln und späteren Updates wird schnell teuer, was heute ohne Tests scheinbar schneller gebaut wurde. Deshalb ist die wichtigere Frage nicht, ob du testest, sondern was du in deinem Plugin sinnvoll als Unit Test absicherst.

Warum Unit Tests in Shopware besonders viel Ärger sparen

Plugins wachsen oft schrittweise. Erst eine kleine Anpassung, dann mehrere Sonderregeln, danach noch eine Schnittstelle. Ohne Tests wird aus so einem Plugin schnell ein Bereich, den niemand mehr gern anfasst.

Unit Tests helfen dir vor allem dabei:

  • Geschäftslogik stabil zu halten
  • Refactorings mit weniger Risiko umzusetzen
  • Fehler früh vor dem Livebetrieb zu entdecken
  • Plugin-Updates kontrollierter auszurollen

Welche Teile du in Shopware gut mit Unit Tests abdecken kannst

Am besten testbar sind Klassen mit klarer fachlicher Verantwortung, zum Beispiel:

  • Calculator- und Pricing-Logik
  • Mapper und Transformer
  • Validatoren und Regelprüfungen
  • kleine Services mit klaren Ein- und Ausgaben

Sobald du Logik sauber aus Framework-Randbereichen herausziehst, werden Tests fast automatisch einfacher.

Was kein guter Unit Test ist

Nicht alles, was unter PHPUnit läuft, ist automatisch ein guter Unit Test. Problematisch wird es, wenn ein Test:

  • die gesamte Shopware-Umgebung bootet
  • echte Datenbankzugriffe braucht
  • mehrere technische Schichten gleichzeitig prüft
  • nur Implementation Details statt Verhalten absichert

Dann bewegst du dich eher Richtung Integrations- oder Systemtest. Das ist nicht falsch, aber eben etwas anderes.

Ein kleines Beispiel für einen testbaren Service

Je kleiner und klarer die Klasse, desto sauberer der Test:

namespace SwagExample\Service;

final class DiscountCalculator
{
    public function calculateGross(float $price, float $discountPercent): float
    {
        return $price - ($price * $discountPercent / 100);
    }
}

Dazu passt ein einfacher Unit Test:

namespace SwagExample\Tests\Service;

use PHPUnit\Framework\TestCase;
use SwagExample\Service\DiscountCalculator;

final class DiscountCalculatorTest extends TestCase
{
    public function testCalculateGross(): void
    {
        $calculator = new DiscountCalculator();

        self::assertSame(80.0, $calculator->calculateGross(100.0, 20.0));
    }
}

Das wirkt simpel, zeigt aber genau den Punkt: Fachlogik sollte so gebaut sein, dass sie ohne Container, Datenbank und Seiteneffekte testbar bleibt.

Wo Mocks sinnvoll sind und wo nicht

Mocks sind hilfreich, wenn du externe Abhängigkeiten isolieren willst. Sie werden problematisch, wenn du damit unklare Architektur kaschierst.

Sinnvoll sind Mocks zum Beispiel für:

  • Logger
  • Repository-Abstraktionen
  • API-Clients
  • technische Hilfsdienste

Weniger sinnvoll sind sie, wenn du am Ende zehn Mocks brauchst, nur um eine einzige Methode zu testen. Dann ist meist nicht der Test das Problem, sondern die Klasse selbst.

Unit Tests, OOP und Dependency Injection gehören zusammen

In Shopware entstehen gut testbare Klassen fast nie zufällig. Sie sind meist das Ergebnis von sauberem objektorientiertem PHP und sinnvoller Dependency Injection.

Wenn Tests schwer sind, lohnt es sich deshalb oft zuerst die Struktur zu verbessern, statt nur mehr Testcode zu schreiben.

Wann du zusätzlich Integrationstests brauchst

Unit Tests decken nicht alles ab. Sobald es um DAL, Events, Container-Konfiguration, Checkout-Prozesse oder Zusammenspiel mit Shopware-Core-Komponenten geht, brauchst du ergänzend Integrations- oder funktionale Tests.

Die gute Nachricht: Je besser deine Business-Logik per Unit Test abgesichert ist, desto fokussierter können diese schwereren Tests bleiben.

Wann strukturierte Plugin-Qualität besonders wichtig wird

Wenn ein Plugin Umsatz, Checkout, Preise, Verfügbarkeiten oder SEO-relevante Logik beeinflusst, solltest du Testbarkeit nicht als Luxus behandeln. In solchen Fällen lohnt sich saubere Shopware Plugin-Entwicklung meistens deutlich mehr als nachträgliches Bugfixing im Live-Shop.

Fazit

Unit Testing in Shopware heißt nicht, alles zu testen. Es heißt, die richtigen Teile sauber abzusichern. Wenn du fachliche Logik aus schwergewichtigen Framework-Bereichen herausziehst und Klassen klar strukturierst, werden Tests einfacher, nützlicher und langfristig günstiger.

FAQ

Was sollte ich in einem Shopware-Plugin zuerst mit Unit Tests absichern?

Vor allem fachliche Logik wie Berechnungen, Regeln, Validierungen und Mapper. Diese Teile profitieren am stärksten von schnellen, isolierten Tests.

Ersetzen Unit Tests Integrations- oder Funktionstests?

Nein. Sie ergänzen sie. Unit Tests sichern einzelne Bausteine ab, während Integrations- und Funktionstests das Zusammenspiel mit Shopware prüfen.

Warum sind meine Unit Tests in Shopware oft so schwer zu schreiben?

Meist liegt das an zu stark gekoppeltem Code. Wenn Klassen zu viel Verantwortung tragen oder direkt vom Framework abhängen, werden Tests automatisch aufwendiger.