Mcube333/playwright-java-test-writer

Playwright Java Test Writer

Transformez des cas de test manuels en tests Playwright Java maintenables qui semblent avoir été écrits par un expert du framework : parallel-safe, sans attentes instables, pages objets qui masquent les localisateurs, et rapports Allure qui remontent aux identifiants des cas de test d'origine.

Workflow

1. Analyser les cas de test manuels

Extrayez pour chaque cas : ID, titre, priorité/gravité, préconditions, données de test, étapes, résultat attendu par étape. Les entrées varient (lignes Excel, exportations Jira, Gherkin, texte libre), normalisez-les sous cette forme avant d'écrire du code.

Si un cas n'est pas automatisable tel qu'écrit (nécessite un OTP d'un vrai téléphone, un jugement visuel comme "a l'air correct", un paiement tiers avec de l'argent réel), ne le simulez pas. Listez-le sous Non automatisé dans la sortie avec la raison et une suggestion (simuler l'API, utiliser un OTP de test, comparaison de captures d'écran).

2. Détecter d'abord les conventions du framework existant

Si l'utilisateur partage des fichiers du dépôt (BaseTest, une classe de page, testng.xml, pom.xml), reproduisez-les exactement : noms de packages, noms de classes de base, style de nommage, style d'assertion, mode de lecture de la configuration. La cohérence avec leur codebase prime sur le style de référence ci-dessous.

Si rien n'est partagé, utilisez le scaffold dans references/framework-scaffold.md. Ne générez les fichiers scaffold (BaseTest, PlaywrightFactory, BasePage, config) que lorsque l'utilisateur demande un framework ou n'en a clairement pas ; sinon, supposez qu'ils existent et générez uniquement les pages objets et les tests.

3. Concevoir les pages objets

• Une classe par page ou composant réutilisable (header, tiroir de panier, panneau de filtre). Les composants ont leur propre classe et sont composés dans les pages.
• Les localisateurs sont des champs private final Locator initialisés dans le constructeur. Les tests n'appellent jamais page.locator(...) directement.
• Les méthodes de page décrivent l'intention utilisateur (login(user, pass), addToCart(productName)), pas la mécanique (clickButton2). Annotez-les avec Allure @Step("...") en utilisant des espaces réservés pour les paramètres, afin que le rapport ressemble au cas manuel.
• Les actions qui naviguent retournent l'objet de page suivant (flux fluide). Les méthodes qui restent sur la page retournent this ou void.
• Réutilisez les méthodes de page existantes avant d'en ajouter de nouvelles. Si deux étapes correspondent à la même intention, utilisez une seule méthode.
• Exposez l'état pour les assertions via des getters nommés par intention retournant Locator (par exemple errorMessage()), afin que les tests puissent utiliser des assertions web-first.

Priorité des localisateurs (du plus stable au moins stable) :

1. getByTestId (configurez le nom de l'attribut une fois si l'application utilise data-test, data-qa, etc.)
2. getByRole avec nom accessible
3. getByLabel / getByPlaceholder / getByText pour le texte visible par l'utilisateur
4. CSS sur des attributs stables
5. XPath, seulement en dernier recours, avec un commentaire expliquant pourquoi

Si l'utilisateur n'a fourni aucun DOM, HTML ou capture d'écran, vous devinez les localisateurs. Écrivez la meilleure estimation et marquez-la // TODO-VERIFY locator afin que rien ne soit livré silencieusement avec des sélecteurs inventés. Mentionnez le nombre de localisateurs non vérifiés dans le résumé.

4. Écrire les tests

• Une méthode @Test par cas manuel. Nom de la méthode = comportement (shouldShowErrorForLockedUser), pas l'ID.
• Traçabilité : mettez l'ID du cas dans @TmsLink("TC-012") et dans description. Ajoutez @Epic, @Feature, @Story, @Severity mappés depuis la priorité du cas (P0/Critique → BLOCKER/CRITICAL, P1 → NORMAL, P2+ → MINOR).
• Chaque résultat attendu devient une assertion. Une étape sans assertion signifie que la vérification manuelle a été supprimée, donc vérifiez avant de terminer.
• Les préconditions vont dans des helpers de configuration ou des appels API, pas dans de longues chaînes de clics UI, lorsqu'une API ou un lien profond existe. Pour les préconditions de connexion (surtout OTP/SSO), préférez une connexion API unique et réutilisez-la via context.storageState() / Browser.NewContextOptions().setStorageStatePath(...).
• Cas répétés avec des données différentes → un test avec un @DataProvider TestNG. @TmsLink est statique, donc passez l'ID du cas comme première colonne de données et appelez Allure.link(caseId, "tms", caseId) dans le test pour conserver la traçabilité par ligne. Gardez les données de test hors du corps du test (data provider, JSON ou classe de constantes). Jamais de données réelles de clients.
• Les tests doivent être indépendants : pas de dépendance sur l'ordre d'exécution, nouveau contexte par test, nettoyez tout ce qui est créé.

5. Attentes : conditionnelles uniquement

C'est la principale source d'instabilité, donc traitez-la comme une règle stricte :

• N'utilisez jamais Thread.sleep ou page.waitForTimeout.
• Préférez les assertions web-first : assertThat(locator).isVisible(), hasText, hasCount, assertThat(page).hasURL(...). Elles se réessayent automatiquement.
• Les actions attendent déjà automatiquement l'actionnabilité ; n'ajoutez pas d'attentes redondantes avant click()/fill().
• Lorsqu'une action déclenche un appel réseau dont le résultat est important, encapsulez-la : page.waitForResponse(r -> r.url().contains("/cart") && r.ok(), () -> addButton.click()).
• Pour les spinners/loaders : assertThat(loader).isHidden().
• Pour la navigation : page.waitForURL("**/checkout**").
• Les timeouts personnalisés proviennent de la configuration, jamais de nombres magiques en ligne.

Voir references/framework-scaffold.md → "Wait patterns" pour des extraits.

6. Sécurité parallèle

Tous les objets Playwright (Playwright, Browser, BrowserContext, Page) vivent dans des ThreadLocal gérés par la classe de base/factory et sont créés et fermés par méthode de test. Ne les stockez jamais dans des champs statiques et ne partagez pas une Page entre les tests. Les pages objets reçoivent la Page via le constructeur. L'état statique dans les pages objets n'est pas autorisé.

Format de sortie

Répondez avec, dans cet ordre :

1. Fichiers : chaque fichier dans son propre bloc de code avec son chemin complet en titre (par exemple src/test/java/com/example/pages/LoginPage.java). Fichiers complets et compilables avec importations, pas de fragments, sauf si l'utilisateur a demandé un extrait. Si plus de ~3 fichiers ou si l'utilisateur veut les télécharger, écrivez-les également sur disque dans un dossier de projet.
2. Tableau de traçabilité : ID du cas | Méthode de test | Étapes automatisées | Notes.
3. Non automatisé / lacunes : cas ou étapes ignorés et pourquoi.
4. Nécessite vérification : nombre et liste des localisateurs TODO-VERIFY, hypothèses sur les données de test ou l'environnement.

Gardez le texte court ; le code est la livraison.

Confidentialité

Lorsque l'utilisateur construit un portfolio public ou que la demande mentionne une application de démonstration publique, gardez tout générique : package com.example (ou ce qu'ils spécifient), pas de noms d'entreprise, d'URL internes, de points de terminaison internes, de données utilisateur réelles ou de noms d'événements propriétaires. Si les cas manuels collés en contiennent, remplacez-les par des équivalents neutres et dites-le en une ligne.

Fichiers de référence

• references/framework-scaffold.md : dépendances pom.xml, PlaywrightFactory avec ThreadLocals, BaseTest avec tracing et pièces jointes Allure en cas d'échec, BasePage, ConfigReader, testng.xml pour exécutions parallèles, extraits de motifs d'attente. Lisez-le lors du scaffolding ou lorsque vous avez besoin de la forme exacte de l'API.
• references/example-saucedemo.md : un exemple complet (cas manuels → pages objets → tests → tableau de traçabilité) sur l'application publique saucedemo.com. Lisez-le pour calibrer le style de sortie.