Ajouter`.only`au test que vous souhaitez exécuter:
```js
test.only('should login', async ({ page }) => {
// ...
})
```
```bash
pnpm run test
```
## Concepts
### Tests indépendants
* Tous les tests sont indépendants les uns des autres.
* Chaque test commence par un nouveau projet avec une nouvelle base de données sakila (l'option de ne pas utiliser sakila db est également disponible).
* Chaque test crée un nouvel utilisateur (e-mail comme`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 nodejs 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 une affirmation, utilisez toujours`expect`depuis`@playwright/test`bibliothèque. Cette bibliothèque fournit de nombreuses assertions utiles, qui intègrent également une logique de nouvelle tentative.
## Objets de page
* Les objets de page sont utilisés pour résumer les composants/la page. Cela rend les tests plus lisibles et maintenables.
* Tous les objets de la page sont dans`tests/playwright/pages`dossier.
* Tout le code lié au test doit être dans des objets de page.
* Les méthodes doivent être aussi fines que possible et il est préférable d'avoir plusieurs méthodes plutôt qu'une grande méthode, ce qui améliore 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 tester la fonctionnalité du filtre.
Pour simplifier, nous aurons`DashboardPage`implémenté, qui aura toutes les méthodes liées à la page du tableau de bord ainsi que ses composants enfants comme Grid, etc.
### Créer une suite de tests
Créer un nouveau fichier`filter.spec.ts`dans`tests/playwright/tests`dossier et utilisation`setup`méthode pour créer un nouveau projet et un nouveau 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 }) => {
// ...
});
});
```
### Créer un objet de page
Étant donné que le filtre est limité, du point de vue de l'interface utilisateur, à un`Toolbar`, nous ajouterons un objet de page de filtre à`ToolbarPage`objet de page.
Nous allons créer`ToolbarFilterPage`objet page, qui aura toutes les méthodes liées au filtre.
```js
export class ToolbarFilterPage extends BasePage {
readonly toolbar: ToolbarPage;
constructor(toolbar: ToolbarPage) {
super(toolbar.rootPage);
this.toolbar = toolbar;
}
}
```
Ici`BasePage`est une classe abstraite, utilisée pour appliquer la structure à tous les objets de page. Ainsi tous les objets de page*devrait*hériter`BasePage`.
* Helper methods like `waitForResponse`et`getClipboardText`(cela peut être accessible sur n'importe quel objet de page, avec`this.waitForResponse`)
* Fournit une structure pour les objets de page, impose à tous les objets de page d'avoir`rootPage`propriété, qui est l’objet de page créé dans la configuration du test.
* Oblige toutes les pages à avoir un`get`méthode qui renverra le localisateur du conteneur principal de cette page, nous pouvons donc avoir une sélection dom ciblée, c'est-à-dire
```js
// This will only select the button inside the container of the concerned page
await this.get().querySelector('button').count();
```
### Ecrire une méthode d'action
C'est une méthode qui réinitialisera/effacera tous les filtres. Puisqu'il s'agit d'une méthode d'action, elle attendra également le`delete`filtrer l'API à retourner. Ignorer cet appel d'API entraînera des problèmes dans le test, sur toute la ligne.
* 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.
* 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
* 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é.
* 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.
Anbarasu
3 months ago
committed by
GitHub