Testabdeckung als Sicherheitsnetz: warum wir vor dem Major-Upgrade Tests nachzogen

Christopher Zechendorf

15.06.2026

Share:

Wie wir vor einem TYPO3-Major-Upgrade fehlende Tests nachzogen und die Test-Infrastruktur auf CSV-Fixtures und DI-Container modernisierten.

Solides Engineering beginnt bei der Absicherung, nicht beim Feature

Ein Major-Upgrade – etwa von TYPO3 v12 auf v13 – ist kein kosmetischer Versionssprung. Es fasst die Datenbankabstraktion an, tauscht zentrale APIs aus und verschiebt Verhalten an Stellen, die im Alltag niemand bewusst ansteuert. Wer eine solche Umstellung ohne automatisierte Tests angeht, migriert blind: Jede Anpassung ist eine Wette darauf, dass nichts Unsichtbares zerbricht.

Bevor und während wir das Magazin-Portal von VINUM.eu auf TYPO3 v13 gehoben haben, haben wir deshalb zuerst das Sicherheitsnetz gespannt: fehlende Unit- und Functional-Tests systematisch nachgezogen und die in die Jahre gekommene Test-Infrastruktur modernisiert. Erst dieses Netz machte die inkrementelle Migration ohne böse Überraschungen möglich.

Die Herausforderung

Beim Einstieg in die Migration trafen zwei Probleme aufeinander:

• Echte Abdeckungslücken. Zahlreiche Controller, Commands und Indexer hatten weder Unit- noch Functional-Tests. Genau die Klassen, die ein Upgrade anfasst – Repositories, Middleware, die XML-Sitemap-Provider – liefen ungetestet mit.
• Tests, die selbst veraltet waren. Die vorhandenen Functional-Tests bauten auf APIs des TYPO3-v12-Testing-Frameworks, die in v13 entfernt wurden. importDataSet() mit XML-Fixtures existiert nicht mehr und führt zum Fatal Error. Der Zugriff auf Repositories lief über GeneralUtility::makeInstance() bzw. den entfernten ObjectManager – der Extbase-PersistenceManager wird so nie injiziert, der Aufruf endet in einer ServiceNotFoundException.

Die Konsequenz war tückisch: Neue Functional-Tests im alten Stil zu schreiben, hätte keine funktionierende Abdeckung erzeugt, sondern nur weitere kaputte Tests. Das betraf nicht einzelne Klassen, sondern die gesamte Repository- und Controller-Test-Suite. Ohne einen Umbau am Fundament war jede zusätzliche Zeile Testcode verlorene Mühe.

Unsere Lösung

1. Lücken sichtbar machen, statt sie zu schätzen

Wir haben die Abdeckung nicht nach Gefühl beurteilt, sondern pro Klasse erfasst: Welche Controller, Repositories und Services haben einen erwarteten Unit- bzw. Functional-Test – und welche nicht? Aus dieser Inventur wurde eine nachvollziehbare Liste konkreter Lücken (u. a. rund um Veranstaltungen, die Weindatenbank, Winzerprofile, Degustationen und die Suche), die gezielt und einzeln geschlossen wurden, statt in einem unkontrollierten Rundumschlag.

2. Das Test-Fundament auf den v13-Stand heben

Damit überhaupt belastbar getestet werden konnte, haben wir die Infrastruktur auf das aktuelle TYPO3-Testing-Framework umgestellt – mit zwei Bausteinen:

• CSV-Fixtures statt XML. Die entfernten importDataSet()-Aufrufe wurden durch importCSVDataSet() ersetzt und die Fixtures entsprechend von XML nach CSV überführt – das ist der unterstützte Mechanismus im aktuellen Framework.
• Repositories über den DI-Container. Statt makeInstance() werden Repositories im Test über den Dependency-Injection-Container bezogen ($this->get(SomeRepository::class)), sodass der Extbase-PersistenceManager korrekt verdrahtet ist. Dafür sorgt eine reine Test-Fixture-Extension, die ausschließlich die zu testenden Klassen als öffentliche Test-Services deklariert – ohne irgendeinen Eingriff in die produktive DI-Konfiguration.

Wichtig war uns, diesen Weg nicht nur einmalig anzuwenden, sondern als wiederverwendbares Muster zu dokumentieren. So konnten die folgenden Arbeitspakete der Migration neue Tests ergänzen, ohne das Vorgehen jedes Mal neu zu erarbeiten.

3. Abdeckung dort nachziehen, wo das Upgrade zuschlägt

Auf diesem Fundament haben wir Functional-Tests für genau die Klassen ergänzt, die das Upgrade berührt hat – die migrierten Repositories, die AJAX-Middleware und die Sitemap-Provider. Mindestens auf Smoke-Test-Niveau, das beweist, dass die migrierten Doctrine-DBAL-Abfragen gegen eine echte Datenbank durchlaufen. Aus „der Code kompiliert” wurde „der Code tut nachweislich das Richtige”.

4. Pflege statt Karteileichen

Veraltete Tests haben wir nicht stillgelegt, sondern aufgeräumt. Ein Suite-Scan brachte elf Testdateien zutage, die wegen entfernter Framework-APIs gar nicht mehr liefen, sowie zwei Unit-Tests, die gegen längst refaktorierte Anwendungs-APIs prüften. Diese wurden migriert bzw. an die aktuelle API angepasst – und nur dort entfernt, wo das geprüfte Verhalten tatsächlich nicht mehr existierte. Ein deaktivierter Test ist schlimmer als kein Test: Er suggeriert Sicherheit, die es nicht gibt.

Das Ergebnis

• Ein dokumentiertes, wiederverwendbares Muster für Functional-Tests (CSV-Fixtures plus DI-Container-Zugriff), auf dem alle weiteren Migrationsschritte aufsetzen konnten.
• Die zuvor ungetesteten, vom Upgrade berührten Klassen laufen jetzt grün – ohne Regressionen in der Suite.
• Vor allem aber ein Sicherheitsnetz, das die TYPO3-v13-Umstellung in kleinen, überprüfbaren Schritten erlaubte, statt in einem großen, riskanten Sprung.

Bemerkenswert ist dabei der Reihenfolge-Effekt: Hätten wir mit der eigentlichen Migration begonnen und die Tests „später” nachziehen wollen, wäre dieses Später nie risikoarm gekommen. Erst das Netz, dann der Drahtseilakt – und alles bleibt dual-kompatibel, lief also sowohl auf der alten als auch auf der neuen Version.

Fazit: Tests sind die Voraussetzung, nicht der Nachgedanke

Ein gutes Major-Upgrade erkennt man nicht daran, dass es spektakulär verläuft, sondern daran, dass es unspektakulär bleibt. Diese Ruhe entsteht nicht durch Glück, sondern durch Coverage: Tests, die vor der Umstellung stehen, fangen die Fehler ab, die sich sonst still in die Produktion schleichen. Solides Engineering endet eben nicht beim Feature – es beginnt bei der Absicherung.

Steht bei Ihnen ein TYPO3-Upgrade an, oder tragen Sie eine gewachsene Anwendung, deren Testabdeckung mit den Jahren ausgedünnt ist? Wir analysieren den Ist-Zustand, schließen die kritischen Lücken zuerst und modernisieren die Test-Infrastruktur so, dass Ihr nächstes Upgrade ein kontrollierter Schritt wird statt eines Sprungs ins Ungewisse.

Kontakt aufnehmen