Merge pull request #8087 from Neet-hu/patch-1

Update fr-050.playwright.md

scripts/docs/fr/150.engineering/fr-050.playwright.md

@@ -0,0 +1,127 @@
+***
+
+titre : "Tests Playwright E2E"
+description: "Aperçu des tests e2e basés sur Playwright"
+tags : ['Ingénierie']
+-------------------------
+
+## Comment exécuter des tests
+
+Tous les tests résident dans le dossier `tests/playwright`.
+
+Assurez-vous d'installer les dépendances (dans le dossier playwright) :
+
+```bash
+pnpm --filter=playwright install
+pnpm exec playwright install --with-deps chromium
+
+Pour configurer MySQL (sakila) :
+
+```bash
+docker-compose -f ./tests/playwright/scripts/docker-compose-mysql-playwright.yml  up -d
+```
+
+Pour configurer postgres (sakila):
+
+```bash
+docker-compose -f ./tests/playwright/scripts/docker-compose-playwright-pg.yml 
+```
+
+### Exécution de tests individuels
+
+Ajouter`.only`au test que vous souhaitez exécuter :
+
+```js
+test.only('should login', async ({ page }) => {
+  // ...
+})
+```
+
+```bash
+pnpm run test
+```
+
+## Concepts
+
+### Tests indépendants
+
+* Chaque test est indépendant des autres.
+* Chaque test démarre avec un nouveau projet et une nouvelle base de données sakila (une option permet également de ne pas utiliser sakila db).
+* Chaque test crée un nouvel utilisateur (par exemple, l'e-mail `user@nocodb.com`) et se connecte avec cet utilisateur au tableau de bord.
+
+Mises en garde :
+
+* 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.
+
+### Dramaturge
+
+* Playwright est une bibliothèque Node.js pour automatiser Chrome, Firefox et WebKit.
+* 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.
+* Pour les assertions, utilisez toujours `expect` de la bibliothèque `@playwright/test`.
+## Objets de page
+
+* Les objets de page servent à encapsuler les interactions avec les composants/la page, rendant les tests plus lisibles et maintenables.
+* Tous les objets de page se trouvent dans le dossier `tests/playwright/pages`.
+* Tout le code lié au test doit être dans des objets de page.
+* 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.
+
+## Écrire un test
+
+Écrivons un test pour vérifier la fonctionnalité de filtrage.
+
+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éer une suite de tests
+
+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.
+
+```js
+import { test, expect } from '@playwright/test';
+import setup, { NcContext } from '../setup';
+
+test.describe('Filter', () => {
+  let context: NcContext;
+
+  test.beforeEach(async ({ page }) => {
+    context = await setup({ page });
+  })
+
+  test('should filter', async ({ page }) => {
+    // ...
+  });
+});
+
+## Conseils pour éviter les desquamations
+
+* 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.
+
+## Accéder au rapport du dramaturge dans le CI
+
+* Ouvrez `Summary` dans le workflow CI des actions GitHub.
+* Faites défiler jusqu'à la section `Artifacts`.
+* Accédez aux rapports portant le suffixe du type de base de données et du numéro de partition (correspondant au nom du workflow CI).
+* Téléchargez-le et exécutez `pnpm install -D @playwright/test && npx playwright show-report ./` dans le dossier téléchargé.
+
+* 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é.