Teststrategie

Die Release-Validierung von WebBlocks CMS sollte risikobasiert erfolgen. Die vollständige Testsuite bleibt verfügbar, aber routinemäßige Hotfixes sollten mit dem kleinsten fokussierten Skript beginnen, das die geänderte Oberfläche absichert.

Verwenden Sie die nativen Composer-Befehle:

• composer test:release-fast: das Standard-Sammelgate für kleine paketnative Hotfixes. Es prüft bewusst stichprobenartig das Routing von Paket-Update-Migrationen, die Paketextraktion, das aktuelle Verhalten von System Updates, das Verhalten des Paketinstallationsbefehls, den Bootstrap des Paket-Providers und die paketbasierten Grenzen der Release-Artefakte.
• composer test:package: fokussierte Abdeckung der Paketlaufzeit und der Quellautoritätsgrenzen. Verwenden Sie es für den Paket-Provider, Paket-Routen-/View-Ausschnitte, Wrapper-Bereinigung, Composer-Metadaten oder Paketstatus-Diagnosen. Verwenden Sie stattdessen test:artifacts für die Form des Release-ZIPs und die Prüfungen des öffentlichen Paket-Asset-Archivs sowie test:install für das Verhalten frischer Consumer-Installationen.
• composer test:update: fokussierte Abdeckung des paketnativen Updaters. Verwenden Sie es für System Updates, das Parsen des Update-Server-Clients, das Verhalten des Migrationsrunners, die Persistenz der installierten Version, die Backup-Bereitschaft, die Paketextraktion oder Paket-Update-Migrationen.
• composer test:install: fokussierte Abdeckung frischer Composer-Consumer-Installationen. Verwenden Sie es für webblocks:install, das Schema frischer Installationen, die Ersteinrichtung des ersten Administrators, die Consumer-Authentifizierung und den Smoke-Test der Admin-/öffentlichen Routen nach der Installation.
• composer test:artifacts: fokussierte Abdeckung der Grenzen von Release-Paketarchiv und Quell-Checkout. Verwenden Sie es, wenn sich .gitattributes, öffentliche Paket-Assets, Paket-Composer-Metadaten, Updater-Unterstützungsdateien, native Release-Skripte oder die Publisher-Paketform ändern.
• composer test:admin-smoke: leichtgewichtige Smoke-Abdeckung der Admin-Routen und -Layouts. Verwenden Sie es für Änderungen am gemeinsamen Admin-Layout, an der Seitenleiste, an der festen CMS-Marken-Shell und an gemeinsamen Admin-Partials.
• composer test:legacy-bridge: manuelle Archiv-Abdeckung für den stillgelegten root-verwalteten Bridge-Pfad 1.31.53 -> 1.32.33. Verwenden Sie dies nicht als routinemäßiges paketnatives Release-Gate.
• composer test:full: die vollständige paketnative Suite, ohne manuelle Legacy-Bridge-Tests. Verwenden Sie sie vor größeren Releases, großen übergreifenden Änderungen oder wenn fokussierte Ergebnisse auf ein breiteres Risiko hindeuten.

Verwenden Sie composer format:changed als Standard-Formatierungsgate für kleine fokussierte Hotfixes. Es vergleicht geänderte Dateien, sofern verfügbar, mit origin/main...HEAD, ergänzt gestagete und Working-Tree-Änderungen, führt Pint nur für geänderte PHP-Dateien aus und wendet den Einrückungs-Guard des Projekts auf geänderte PHP- oder Blade-Dateien an. Sind keine geänderten PHP- oder Blade-Dateien vorhanden, gibt es eine klare No-Op-Meldung aus und beendet sich erfolgreich.

Verwenden Sie composer format:test für die vollständige Formatierungs-Baseline des Repositorys, wenn eine Änderung umfangreich oder release-kritisch ist oder das Formatierungs-Tooling betrifft. Es führt Laravel Pint für den PHP-Stil ohne Einrückung aus sowie scripts/check-php-indentation.php für die projektspezifische Regel der 2-Leerzeichen-PHP-Einrückung über die gepflegten Quell-, Paket-, Routen-, View-, Skript- und Test-Wurzelverzeichnisse. Die einrückungsspezifischen Fixer von Pint sind in pint.json deaktiviert, damit der eigene 2-Leerzeichen-Guard maßgeblich bleibt.

Repräsentative Tests:

• tests/Feature/ReleasePackageBoundaryTest.php
• tests/Feature/ComposerPackageMetadataTest.php
• tests/Feature/PackageServiceProviderBootstrapTest.php
• tests/Feature/PackageConsumerInstallCommandTest.php
• tests/Feature/Admin/SystemUpdatesTest.php
• tests/Unit/System/Updates/UpdateMigrationRunnerTest.php
• tests/Unit/System/Updates/UpdatePackageExtractorTest.php

Führen Sie für kleine paketnative Hotfixes composer test:release-fast aus. Ergänzen Sie composer test:full, wenn das Release umfangreiches Admin-/Inhaltsverhalten, Schemaverträge, Import-/Export-Portabilität oder das öffentliche Rendering ändert.

test:release-fast ist bewusst ein Sammelgate und überschneidet sich daher leicht mit test:update, test:install und test:artifacts. Die fokussierten Skripte unten werden während der Implementierung bevorzugt, wenn die geänderte Oberfläche enger begrenzt ist.

Repräsentative Tests:

• tests/Feature/PackageConsumerInstallCommandTest.php
• tests/Feature/PackageConsumerInstallAuthTest.php
• tests/Feature/PackageFreshInstallMigrationTest.php

Führen Sie composer test:install aus für frische Composer-Consumer-Installationen, frisches Schema, den Bootstrap der Paketrouten, die Einrichtung des ersten Administrators sowie Änderungen an der Authentifizierung oder am Admin-/öffentlichen Smoke-Test nach der Installation. Verwenden Sie composer test:package, wenn die Änderung zusätzlich die Quellautorität des Pakets betrifft, oder composer test:artifacts, wenn sie die Form der Release-Artefakte betrifft.

Repräsentative Tests:

• tests/Feature/Admin/SystemUpdatesTest.php
• tests/Unit/System/Updates/UpdateMigrationRunnerTest.php
• tests/Unit/System/Updates/UpdatePackageExtractorTest.php
• tests/Unit/System/Updates/UpdateServerClientTest.php
• tests/Unit/System/InstalledVersionStoreTest.php
• tests/Feature/PageTranslationParentKeyUpdateMigrationTest.php

Führen Sie composer test:update aus für das Parsen des Updater-Clients, die Extraktion des Paketarchivs, die paketnative Migrationsausführung, den Backup-Preflight, die Persistenz der installierten Version und Änderungen an Paket-Update-Migrationen.

Wenn Sie eine Tabelle oder Spalte hinzufügen, die von Admin, API, öffentlichem Rendering, Befehlen, Middleware oder einem beliebigen Laufzeit-Codepfad verwendet wird, fügen Sie einen Regressionstest für die Paket-Update-Migration hinzu oder aktualisieren Sie ihn. Verwenden Sie für paketnative Schemaerweiterungen fokussierte Tests ähnlich tests/Feature/CmsApiTokensUpdateMigrationTest.php und führen Sie genau diese Testklasse plus composer test:update aus. Die Schemaabdeckung frischer Installationen allein reicht nicht aus, da paketnative System Updates keine Host-/Root-Migrationen ausführen.

Repräsentative Tests:

• tests/Feature/PageTranslationParentKeyUpdateMigrationTest.php
• Paket-Update-Migrationstests wie tests/Feature/CmsApiTokensUpdateMigrationTest.php
• tests/Feature/Admin/SystemBackupsTest.php
• tests/Feature/System/SystemBackupRestoreManagerTest.php
• tests/Feature/Console/SystemBackupRestoreCommandTest.php
• tests/Unit/System/BackupRestoreArchiveInspectorTest.php
• tests/Unit/System/DatabaseRestoreRunnerMysqlTest.php
• tests/Unit/System/DatabaseRestoreRunnerSqliteTest.php

Führen Sie für einen reinen Migrations-Hotfix genau die betreffende Migrationstestklasse aus, danach composer test:update, wenn die Migration über System Updates läuft. Ergänzen Sie Backup- und Restore-Klassen bei Änderungen am Archivformat, am Datenbank-Dump, an der Wiederherstellung oder am Backup vor dem Update.

Für Schemata, die neuer Laufzeitcode unmittelbar erwartet, muss die Validierung beide Seiten der Installationsmatrix nachweisen: das Schema der frischen/Paket-Consumer-Installation und die bestehende paketnative Update-Migration. Ergänzen Sie außerdem fokussierte Admin-/API-/Laufzeitabdeckung, wenn ein fehlendes Schema zu einer kontrollierten Setup-/Update-Anleitung statt zu einer rohen Datenbank-Exception führen soll.

Repräsentative Tests:

• tests/Feature/ReleasePackageBoundaryTest.php
• tests/Feature/CoreProjectBoundaryTest.php
• tests/Feature/PackageWrapperCleanupTest.php
• tests/Feature/Console/PackageStatusCommandTest.php

Führen Sie composer test:artifacts aus für den aktuellen paketnativen Release-Paketinhalt, das paketbasierte ZIP-Layout, die Einbeziehung der public/cms-Assets, den Ausschluss von project/, das Archivverhalten des GitHub-Workflows und die Grenzen der Paket-Wrapper-Bereinigung. Dieses Gate validiert bewusst nicht die Archivform der stillgelegten root-verwalteten Bridge.

Repräsentative Tests:

• tests/Feature/Admin/AdminDashboardRouteTest.php
• tests/Feature/Admin/AdminSidebarNavigationTest.php
• tests/Feature/Admin/SharedAdminPartialPackageViewTest.php
• tests/Feature/Admin/PagePreviewTest.php

Führen Sie composer test:admin-smoke aus für Layout, Seitenleiste, gemeinsame Admin-Partials, Änderungen am Bootstrap der Paket-Admin-Routen sowie Smoke-Abdeckung der Admin-Vorschaurouten und -links. Ergänzen Sie spezifische Admin-Feature-Tests, wenn der geänderte Bereich tiefer geht als ein Routen-/Layout-Smoke-Test.

Repräsentative Tests:

• tests/Feature/PublicEditorialBlocksRenderingTest.php
• tests/Feature/PublicMediaBlocksTest.php
• tests/Feature/PublicSharedSlotRenderingTest.php
• tests/Feature/PublicRichContentTest.php
• tests/Feature/MediaVisualBlockContractsTest.php
• tests/Feature/BlockTypePhaseThreeContractsTest.php
• tests/Feature/Integrity/BlockTranslationIntegrityTest.php
• tests/Feature/Admin/PageBuilderExperienceTest.php
• tests/Feature/Admin/PagePreviewTest.php

Führen Sie fokussierte Klassen oder Methodenfilter aus für Block-Rendering, öffentliche Shell, Medien, Rich Text, Shared Slots, Übersetzungsintegrität, Admin-Vorschau-Rendering oder Page-Builder-Änderungen. Vorschau-Arbeiten müssen nachweisen, dass die authentifizierte Admin-Vorschau Seiten im Status Entwurf/in Prüfung/veröffentlicht rendern kann, ohne das Verhalten öffentlicher Routen, die Besucherstatistik, den Veröffentlichungsstatus oder die Such-/Indexierungsannahmen zu verändern.

Manuelle Archivtests:

• tests/Unit/System/Updates/LegacyRootManagedUpdateCompatibilityTest.php
• Bridge-Archivverhalten, abgedeckt durch scripts/build-root-managed-bridge-archive.sh

Der alte root-verwaltete Bridge-Pfad existiert nur für die historische/manuelle Validierung des abgeschlossenen Übergangs 1.31.53 -> 1.32.33 bridge -> 1.32.34+ package-rooted. Die aktuelle Projektrichtlinie besagt, dass in der routinemäßigen Release-Validierung keine alten root-verwalteten Installationen mehr zu unterstützen sind.

Routinemäßige paketnative Gates schließen die PHPUnit-Gruppe legacy aus und hängen nicht von LegacyRootManagedUpdateCompatibilityTest ab. Führen Sie composer test:legacy-bridge nur aus, wenn Sie das archivierte Bridge-Skript gezielt prüfen, historische Update-Dokumentation ändern oder ein Wiederherstellungsszenario aus der Zeit vor der Paketnativität untersuchen. Blockieren Sie normale paketnative Releases nicht mit dieser stillgelegten Bridge-Abdeckung.

Diese Klassen sind sehr wertvoll, aber breit, teuer oder inhaltsintensiv. Bevorzugen Sie während der Implementierung fokussierte Methodenfilter und beziehen Sie sie bei Bedarf in die Validierung der vollständigen Suite oder des Funktionsbereichs ein:

• tests/Feature/Admin/PageBuilderExperienceTest.php: sehr umfangreiche Abdeckung der Page-Builder- und Content-Management-Workflows.
• tests/Feature/SiteExportImportTest.php: vollständige Export-/Import-Rekonstruktions- und Portabilitätsabläufe.
• tests/Feature/ContactFormModuleTest.php: breites Verhalten von Kontaktformular, Mail, Einstellungen und Benachrichtigungen.
• tests/Feature/PublicSharedSlotRenderingTest.php: Rendering- und Umschaltverhalten von Shared Slots über öffentliche Seiten hinweg.
• tests/Feature/MediaVisualBlockContractsTest.php: medienintensive Blockverträge und Rendering-Verhalten.
• tests/Feature/Admin/MediaManagementTest.php: Admin-Medien-Workflows.
• tests/Feature/Admin/PageEditorialWorkflowTest.php: Statusverhalten des redaktionellen Workflows.

Die Suite verwendet derzeit nur eine schmale PHPUnit-Gruppe legacy für die stillgelegte root-verwaltete Bridge-Abdeckung. Routinemäßige Composer-Skripte schließen diese Gruppe aus, während composer test:legacy-bridge sie gezielt ausführt. Breitere Gruppen wie package, update, release, artifact, admin-smoke und slow können später noch hinzugefügt werden, sobald sich die Skriptgrenzen gefestigt haben.