* Certaines choses sont partagées avec les utilisateurs, les plugins, etc. Soyez donc prudent lorsque vous écrivez des tests à ce sujet. Un correctif pour cela est en préparation.
* Lors du test, nous préfixons l'e-mail et le projet avec l'identifiant du test, qui sera supprimé une fois le test terminé.
### Que tester
* Vérification de l'interface utilisateur. Cela inclut la vérification de l'état de l'élément de l'interface utilisateur, c'est-à-dire si l'élément est visible, si l'élément a un texte particulier, etc.
* Le test doit vérifier tous les flux d’utilisateurs. Un test a un délai d'expiration par défaut de 60 secondes. Si un test dure plus de 60 secondes, c’est le signe que le test doit être divisé en tests plus petits.
* Le test doit également vérifier tous les effets secondaires de la fonctionnalité (c'est-à-dire lors de l'ajout d'un nouveau type de champ, il doit également vérifier la suppression du champ), ainsi que les cas d'erreur.
* Le nom du test doit être descriptif. Il devrait être facile de comprendre ce que fait le test en lisant simplement le nom du test.
* Pour chaque test, un nouveau contexte de navigateur est créé. Cela signifie que chaque test s'exécute dans une nouvelle fenêtre de navigation privée.
* Les méthodes doivent être aussi granulaires que possible, privilégiant plusieurs petites méthodes à une seule grande méthode pour améliorer la réutilisabilité.
Les méthodes d'un objet page peuvent être classées en 2 catégories :
* Actions: effectue des actions d'interface utilisateur telles que cliquer, taper, sélectionner, etc. Est également responsable d'attendre que l'élément soit prêt et que l'action soit effectuée. Cela incluait l'attente de la fin des appels d'API.
* Assertions: Asserts the state of the UI element, i.e if the element is visible, if the element has a particular text etc. Use `expect`depuis`@playwright/test`et sinon, utilisez`expect.poll`attendre que l'affirmation passe.
Pour simplifier, nous supposerons que `DashboardPage` est implémenté, contenant toutes les méthodes relatives à la page du tableau de bord et à ses composants enfants, tels que Grid, etc.
Créez un nouveau fichier `filter.spec.ts` dans le dossier `tests/playwright/tests` et utilisez la méthode `setup` pour créer un nouveau projet et un nouvel utilisateur.
* Si une action de l'interface utilisateur entraîne un appel d'API ou un changement d'état de l'interface utilisateur, assurez-vous d'attendre la fin de cet appel d'API ou le changement d'état de l'interface utilisateur.
* Ce qu'il convient d'attendre peut varier selon la situation, mais en général, il est préférable d'attendre que l'état final soit atteint.
* Si une action de l'interface utilisateur provoque un appel d'API ou un changement d'état de l'interface utilisateur, attendez que cet appel d'API se termine ou que l'état de l'interface utilisateur change.
* Ce qu'il faut attendre peut être spécifique à la situation, mais en général, il est préférable d'attendre que l'état final soit atteint, c'est-à-dire dans le cas de la création d'un filtre, alors qu'il semble qu'attendre que l'API du filtre se termine soit suffisant, mais après son retournez, les enregistrements de la table sont rechargés et l'état de l'interface utilisateur change, il est donc préférable d'attendre que les enregistrements de la table soient rechargés.
## Accéder au rapport du dramaturge dans le CI
* Ouvrir`Summary`dans le workflow CI dans les actions github.
* Faites défiler jusqu'à`Artifacts`section.
* Accédez aux rapports comportant le suffixe du type de base de données et du numéro de partition (correspondant au nom du flux de travail CI). c'est à dire`playwright-report-mysql-2`est pour`playwright-mysql-2`flux de travail.
* Téléchargez-le et exécutez`pnpm install -D @playwright/test&& npx playwright show-report ./`dans le dossier téléchargé.