Strategia di test

La validazione delle release di WebBlocks CMS dovrebbe basarsi sul rischio. La suite completa resta disponibile, ma le correzioni di routine dovrebbero partire dallo script più piccolo e mirato che protegge la superficie modificata.

Usate i comandi nativi di Composer:

composer test:release-fast
composer test:package
composer test:update
composer test:install
composer test:artifacts
composer test:admin-smoke
composer test:full

Script di Composer

  • composer test:release-fast: il gate aggregato predefinito per piccole correzioni native da pacchetto. Campiona intenzionalmente il routing delle migrazioni di aggiornamento del pacchetto, l'estrazione del pacchetto, il comportamento attuale di System Updates, il comportamento del comando di installazione del pacchetto, il bootstrap del provider del pacchetto e i confini degli artefatti di release con radice nel pacchetto.
  • composer test:package: copertura mirata del runtime del pacchetto e del confine di autorità del codice sorgente. Usatelo per il provider del pacchetto, le porzioni di rotte/viste del pacchetto, la pulizia del wrapper, i metadati Composer o la diagnostica dello stato del pacchetto. Usate invece test:artifacts per la forma dello ZIP di release e i controlli sull'archivio degli asset pubblici del pacchetto, e test:install per il comportamento di un'installazione consumer nuova.
  • composer test:update: copertura mirata dell'updater nativo da pacchetto. Usatelo per System Updates, il parsing del client del server di aggiornamento, il comportamento del runner delle migrazioni, la persistenza della versione installata, la preparazione del backup, l'estrazione del pacchetto o le migrazioni di aggiornamento del pacchetto.
  • composer test:install: copertura mirata dell'installazione consumer nuova via Composer. Usatelo per webblocks:install, lo schema di installazione nuova, la configurazione del primo amministratore, l'autenticazione consumer e gli smoke test delle rotte admin/pubbliche dopo l'installazione.
  • composer test:artifacts: copertura mirata dell'archivio del pacchetto di release e del confine del checkout dei sorgenti. Usatelo ogni volta che cambiano .gitattributes, gli asset pubblici del pacchetto, i metadati composer del pacchetto, i file di supporto dell'updater, gli script nativi di release o la forma del pacchetto del publisher.
  • composer test:admin-smoke: copertura smoke leggera di rotte/layout dell'amministrazione. Usatelo per modifiche al layout admin condiviso, alla sidebar, allo shell fisso del brand CMS e ai partial admin condivisi.
  • composer test:legacy-bridge: copertura d'archivio manuale per il percorso bridge gestito dalla radice ormai ritirato 1.31.53 -> 1.32.33. Non usatelo come gate di release di routine per il modello nativo da pacchetto.
  • composer test:full: la suite nativa da pacchetto completa, esclusi i test manuali del bridge legacy. Usatelo prima delle release maggiori, per modifiche trasversali estese o quando i risultati mirati indicano un rischio più ampio.

Controlli di formattazione

Usate composer format:changed come gate di formattazione predefinito per piccole correzioni mirate. Confronta i file modificati con origin/main...HEAD quando disponibile, aggiunge le modifiche in staging e nel working tree, esegue Pint solo sui file PHP modificati ed esegue il guard di indentazione del progetto sui file PHP o Blade modificati. Quando non ci sono file PHP o Blade modificati, stampa un messaggio chiaro di nessuna operazione ed esce con successo.

Usate composer format:test per la baseline di formattazione dell'intero repository quando una modifica è ampia, critica per la release o tocca gli strumenti di formattazione. Esegue Laravel Pint per lo stile PHP non legato all'indentazione e scripts/check-php-indentation.php per la regola di indentazione PHP a 2 spazi propria del progetto sulle radici mantenute di sorgenti, pacchetto, rotte, viste, script e test. I fixer di indentazione di Pint sono disattivati in pint.json affinché il guard personalizzato a 2 spazi resti l'autorità.

Critico per la release

Test rappresentativi:

  • 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

Eseguite composer test:release-fast per piccole correzioni native da pacchetto. Aggiungete composer test:full quando la release modifica comportamenti estesi di amministrazione/contenuto, contratti di schema, portabilità di import/export o il rendering pubblico.

test:release-fast è volutamente un gate aggregato, quindi si sovrappone leggermente a test:update, test:install e test:artifacts. Durante l'implementazione sono preferibili gli script mirati elencati di seguito, quando la superficie modificata è più ristretta.

Critico per l'installazione del pacchetto

Test rappresentativi:

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

Eseguite composer test:install per l'installazione consumer nuova via Composer, lo schema nuovo, il bootstrap delle rotte del pacchetto, la configurazione del primo amministratore e le modifiche agli smoke test di autenticazione o rotte admin/pubbliche dopo l'installazione. Usate composer test:package quando la modifica tocca anche l'autorità dei sorgenti del pacchetto, oppure composer test:artifacts quando tocca la forma degli artefatti di release.

Critico per l'aggiornamento del pacchetto

Test rappresentativi:

  • 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

Eseguite composer test:update per il parsing del client dell'updater, l'estrazione dell'archivio del pacchetto, l'esecuzione delle migrazioni native da pacchetto, il preflight del backup, la persistenza della versione installata e le modifiche alle migrazioni di aggiornamento del pacchetto.

Quando aggiungete una tabella o una colonna usata dall'amministrazione, dall'API, dal rendering pubblico, dai comandi, dal middleware o da qualsiasi percorso di codice a runtime, aggiungete o aggiornate un test di regressione della migrazione di aggiornamento del pacchetto. Usate test mirati simili a tests/Feature/CmsApiTokensUpdateMigrationTest.php per le aggiunte di schema native da pacchetto ed eseguite esattamente quella classe di test insieme a composer test:update. La sola copertura dello schema di installazione nuova non basta, perché System Updates nativo da pacchetto non esegue le migrazioni host/root.

Critico per migrazione / backup / ripristino

Test rappresentativi:

  • tests/Feature/PageTranslationParentKeyUpdateMigrationTest.php
  • test delle migrazioni di aggiornamento del pacchetto come 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

Eseguite l'esatta classe di test della migrazione per una correzione che riguarda solo la migrazione, poi composer test:update se la migrazione passa da System Updates. Aggiungete le classi di backup e ripristino per modifiche al formato dell'archivio, al dump del database, al ripristino o al backup pre-aggiornamento.

Per lo schema che il nuovo codice si aspetta subito, la validazione deve dimostrare entrambi i lati della matrice di installazione: schema di installazione nuova/consumer del pacchetto e migrazione di aggiornamento nativa da pacchetto sulle installazioni esistenti. Aggiungete inoltre copertura mirata di amministrazione/API/runtime dove manca, in modo che uno schema assente produca una guida controllata di configurazione/aggiornamento anziché un'eccezione grezza del database.

Confini degli artefatti di release

Test rappresentativi:

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

Eseguite composer test:artifacts per il contenuto attuale del pacchetto di release nativo, la disposizione dello ZIP con radice nel pacchetto, l'inclusione degli asset di public/cms, l'esclusione di project/, il comportamento dell'archivio nel workflow GitHub e i confini della pulizia del wrapper del pacchetto. Questo gate non valida intenzionalmente la forma dell'archivio del bridge gestito dalla radice ormai ritirato.

Smoke dell'amministrazione

Test rappresentativi:

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

Eseguite composer test:admin-smoke per modifiche a layout, sidebar, partial admin condivisi, bootstrap delle rotte admin del pacchetto e per la copertura smoke di rotte/link dell'anteprima admin. Aggiungete test specifici delle funzionalità admin quando l'area modificata va oltre lo smoke di rotte/layout.

Rendering pubblico / contenuti

Test rappresentativi:

  • 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

Eseguite classi mirate o filtri di metodo per modifiche al rendering dei blocchi, allo shell pubblico, ai media, al rich text, agli shared slot, all'integrità delle traduzioni, al rendering dell'anteprima admin o al page builder. Il lavoro sull'anteprima deve dimostrare che l'anteprima admin autenticata può renderizzare pagine in bozza, in revisione e pubblicate senza modificare il comportamento delle rotte pubbliche, la reportistica sui visitatori, lo stato di pubblicazione o le ipotesi su ricerca/indicizzazione.

Bridge legacy / gestito dalla radice (ritirato)

Test d'archivio manuali:

  • tests/Unit/System/Updates/LegacyRootManagedUpdateCompatibilityTest.php
  • comportamento dell'archivio bridge coperto da scripts/build-root-managed-bridge-archive.sh

Il vecchio percorso bridge gestito dalla radice esiste solo per la validazione storica/manuale della transizione ormai completata 1.31.53 -> 1.32.33 bridge -> 1.32.34+ package-rooted. La politica attuale del progetto è che non restano vecchie installazioni gestite dalla radice da supportare nella validazione di release di routine.

I gate di routine nativi da pacchetto escludono il gruppo PHPUnit legacy e non dipendono da LegacyRootManagedUpdateCompatibilityTest. Eseguite composer test:legacy-bridge solo quando verificate intenzionalmente lo script bridge archiviato, modificate la documentazione storica sugli aggiornamenti o indagate uno scenario di recupero antecedente al modello nativo da pacchetto. Non bloccate le normali release native da pacchetto per questa copertura del bridge ritirato.

Candidati lenti / solo per la suite completa

Queste classi sono di grande valore ma ampie, costose o ricche di contenuti. Durante l'implementazione preferite filtri di metodo mirati e includetele nella suite completa o nella validazione dell'area funzionale quando pertinenti:

  • tests/Feature/Admin/PageBuilderExperienceTest.php: copertura molto estesa del page builder e del flusso di gestione dei contenuti.
  • tests/Feature/SiteExportImportTest.php: flussi completi di ricostruzione e portabilità di export/import.
  • tests/Feature/ContactFormModuleTest.php: comportamento esteso di form di contatto, posta, impostazioni e notifiche.
  • tests/Feature/PublicSharedSlotRenderingTest.php: rendering degli shared slot e comportamento di cambio sulle pagine pubbliche.
  • tests/Feature/MediaVisualBlockContractsTest.php: contratti dei blocchi e comportamento di rendering con forte uso di media.
  • tests/Feature/Admin/MediaManagementTest.php: flussi di lavoro dei media in amministrazione.
  • tests/Feature/Admin/PageEditorialWorkflowTest.php: comportamento degli stati del flusso di lavoro editoriale.

Candidati alla pulizia

File di test Perché può essere obsoleto o duplicato Copertura più recente per lo stesso rischio Azione consigliata
tests/Unit/System/Updates/LegacyRootManagedUpdateCompatibilityTest.php Protegge il vecchio comportamento dell'updater gestito dalla radice di 1.31.53. Non restano vecchie installazioni gestite dalla radice da supportare. Copertura degli aggiornamenti nativi da pacchetto in SystemUpdatesTest, UpdateMigrationRunnerTest, UpdatePackageExtractorTest e ReleasePackageBoundaryTest. Mantenuto solo nel gruppo legacy e in composer test:legacy-bridge; escluso dai gate di routine nativi da pacchetto.
Asserzioni sul bridge in tests/Feature/ReleasePackageBoundaryTest.php Il test sugli artefatti di release mescolava i confini attuali con radice nel pacchetto con le asserzioni sullo script bridge gestito dalla radice. La forma della release con radice nel pacchetto è coperta dalla stessa classe; il comportamento del bridge è storico. Spostate in LegacyRootManagedUpdateCompatibilityTest affinché ReleasePackageBoundaryTest resti nativo da pacchetto.
L'abitudine di validare la release con un ampio --filter=Package Esegue test non correlati con "Package" nel nome e ripete costosi controlli di archivio/installazione. composer test:package nomina esplicitamente il gate di pacchetto previsto. Sostituire l'uso di routine con gate basati su script.
tests/Feature/PackageConsumerInstallAuthTest.php insieme a PackageConsumerInstallCommandTest.php Entrambi esercitano lo stato di installazione nuova; uno si concentra sulla baseline del comando, l'altro sullo smoke di rotte/autenticazione. Insieme restano utili per le release che toccano l'installazione, ora sotto composer test:install. Mantenere entrambi per ora; valutare la riduzione della matrice di rotte se la validazione dell'installazione diventa troppo lenta.
tests/Feature/PackageServiceProviderBootstrapTest.php Le ampie asserzioni sull'autorità dei sorgenti del pacchetto possono sovrapporsi ai test di pulizia del wrapper e di stato del pacchetto. PackageWrapperCleanupTest e PackageStatusCommandTest coprono porzioni più ristrette. Mantenere come critico per la release finché la transizione al pacchetto è recente; rivalutare quando il modello nativo da pacchetto si sarà stabilizzato.

Gruppi PHPUnit

La suite usa attualmente un ristretto gruppo PHPUnit legacy solo per la copertura del bridge gestito dalla radice ormai ritirato. Gli script composer di routine escludono quel gruppo, mentre composer test:legacy-bridge lo esegue deliberatamente. Gruppi più ampi come package, update, release, artifact, admin-smoke e slow potranno essere aggiunti in seguito, una volta consolidati i confini degli script.