Réduire les Tests Poshi

Un playbook pour réduire la suite de tests Poshi d'un composant Liferay avant de migrer les tests vers Playwright, l'intégration Java, ou la couche unitaire. Résultat typique : un fichier avec ~27 tests se termine avec ~8, en ~24 petits commits examinables.

Préconditions

L'arborescence de travail est propre. Abandonner et demander à l'utilisateur de faire un commit ou stash d'abord en cas de modifications.

Entrée

Nom du Composant

L'annotation @component-name, passée en tant que ${ARGUMENTS} (par ex. portal-analytics-cloud, portal-commerce, portal-content-management). Lorsque ${ARGUMENTS} est vide, scanner les fichiers .testcase sous portal-web/test/functional/com/liferay/portalweb/tests/enduser, lister les valeurs @component-name distinctes trouvées, et demander à l'utilisateur d'en choisir une. Ne pas deviner.

Vérifier le composant en énumérant, sous portal-web/test/functional/com/liferay/portalweb/tests/enduser, tous les fichiers .testcase dont @component-name correspond ; abandonner si aucun fichier ne correspond. Cette même énumération alimente le Plan de Réduction : par fichier, capturer le chemin, la valeur testray.main.component.name, et le nombre de blocs de test.

Sortie Attendue

Plan de Réduction

Construire le plan via le mode plan (EnterPlanMode) en utilisant ce format :

## Inventaire

| Fichier | Nombre de Tests | testray.main.component.name |
| --- | --- | --- |
| <chemin> | <N> | <composant> |

## Fichiers à Traiter

### <chemin du fichier> (N → M)

> **Groupe A — <Nom du contexte>** (N → 1) :
>
> - Renommer `<Gardien>` → `<NomFinal>` (commit 1)
> - Fusionner `<Source2>` → ajoute `<assertion>` (commit 2)
> - Fusionner `<Source3>` → ajoute `<assertion>` (commit 3)
> - … etc

### <prochain chemin de fichier> (N → M)

…

Trier l'inventaire par ordre croissant du nombre de tests afin que les petits fichiers (gains faciles) apparaissent en premier. Éviter les fichiers ayant 40+ tests lors du premier passage.

Choisir le gardien pour chaque groupe : le test avec les assertions les plus complètes, même si son nom est maladroit — le gardien ne doit pas conserver son nom. Le nom final décrit le comportement combiné (par ex. ContentPerformancePanelInBlogDisplayPage, LanguageDropdownInContentPage) et est généralement différent du nom original du gardien.

Signaux courants dignes de fusion — motifs classiques des noms de tests Liferay :

Plusieurs tests AuthorNotShowIn<Context> — généralement un par contexte de panneau suffit.
Plusieurs tests MetricsIconVisibleIn<Context> + PanelInformationIn<Context> — le premier vérifie titre+trafic, le second titre+URL+langue — énorme chevauchement entre les deux.
CheckAllInfo* ou tests similaires fourre-tout qui dupliquent des tests de champs spécifiques.
Tests qui partagent le setUp complet + les N premières tâches (naviguer, créer blog, ouvrir panneau) et diffèrent uniquement dans l'assertion finale.

Signaux de Fusion — À FAIRE

Même setup + même surface UI + assertion différente → un test avec N tâches d'assertion.
Tests ne différant que par le type d'actif (blog vs document vs widget vs page de contenu) lorsque le comportement du panneau affirmé est identique — un représentant suffit généralement ; proposer la suppression pour les autres plutôt que fusionner quatre tests en quatre.
Tests dont l'assertion de la source est déjà entièrement couverte dans la cible — le commit a toujours lieu — il supprime simplement la source.

Signaux de Fusion — À NE PAS FAIRE

Tests ayant des remplacements de propriétés au niveau du test qui diffèrent : property portal.upstream = "quarantine", property test.liferay.virtual.instance = "false", property test.run.type = "single" (s'ils ne sont pas hérités).
Tests avec setup spécial (URLs localisées, traductions de fragments, modifications de paramètres système, création de page supplémentaire).
Tests ayant les annotations @ignore / @skip.

Fichiers de Tests Réduits

Après que ExitPlanMode retourne l'approbation de l'utilisateur, appliquer chaque opération dans l'ordre où elle apparaît dans le plan et faire un commit après chacune — un commit par opération, jamais écrasés. La granularité par fusion est exactement ce qui rend le diff examinable.

Renommer — changer test <AncienNom> du gardien en test <NomFinal> sans autres modifications. Message de commit : <TICKET> Rename test <Gardien> to <NomFinal>.
Fusionner — supprimer le bloc test <Source> { ... } de la source et incorporer ses assertions uniques dans la cible en tant que nouveaux blocs task. Lorsque les assertions de la source sont déjà entièrement couvertes par la cible, supprimer simplement la source. Lorsque la même condition est affirmée à différents niveaux (par ex. AssertTextEquals.assertPartialText("web/<site-path>") vs le plus faible AssertVisible value1="http://"), conserver le plus fort. Message de commit : <TICKET> Merge test <Source> into <NomFinal>.

Lorsque la convention du fichier maintient les tests en ordre alphabétique, ajouter un commit <TICKET> Alphabetic order final après toutes les fusions.

Résumé

Après réduction du fichier, signaler :

Le fichier réduit et son testray.main.component.name.
Nombre de tests avant/après.
Total des commits effectués (renommages + fusions + nettoyages optionnels).
Tests conservés intacts et la raison (setup spécial, propriétés différentes, @ignore).

poshi-shrink