Forem: Manon Carbonnel

Tester son interface efficacement : des patterns pour des tests d’UI robustes

Manon Carbonnel — Thu, 13 Mar 2025 17:13:35 +0000

Article co-écrit avec @singebob

Tester l’interface (UI) est un défi : les tests doivent être fiables, lisibles et maintenables dans le temps, tout en restant suffisamment souples pour suivre les évolutions du produit. Malheureusement, l’UI est amenée à évoluer régulièrement, et ces tests sont souvent fragiles et difficiles à faire évoluer si leur conception n’est pas rigoureuse. Nous voulons également des tests cohérents avec des parcours réalistes.

Cet article explore des patterns éprouvés pour améliorer la qualité des tests d’UI. Ces tests sont aussi l’occasion de se mettre à la place des utilisateur·ices de nos applications.

User Facing Attributes

Ce pattern propose d’utiliser des sélecteurs basés sur des attributs ou propriétés visibles par l’utilisateur·ice (rôles accessibles, labels, textes, etc.) pour identifier et interagir avec les éléments de l'interface. Cela permet de rendre les tests plus intuitifs et orientés vers l'expérience réelle de l'utilisateur·ice, en étant moins dépendants de CSS, tout en favorisant des pratiques de développement prenant en compte l’accessibilité.

💡 C’est aujourd’hui l’approche préconisée par la majorité des outils d’automatisation de navigateur comme Playwright.

Si vous utilisez Cypress, bien que la documentation évoque Testing Library, elle préconise l’utilisation de data-test-id.

Mais nous ne sommes pas d’accord avec cette recommandation :D.
Dans la même idée, utiliser des locators basés sur le CSS ou le XPath ne sont pas recommandés, car le DOM peut souvent changer, ce qui conduit à des tests non résilients.

Exemples de code pour accéder aux éléments du DOM d’une page web

Exemple d’utilisation avec Testing Library

// tests/homepage.spec.ts
import { describe, it, expect } from 'vitest';
import { screen } from '@testing-library/dom';

describe('HomePage - User Facing Attributes', () => {
  it('devrait afficher un titre contenant "Playwright" et un lien "Get started" visible', () => {
    await this.page.goto('https://playwright.dev/');

    // Sélection basée sur des attributs exposés à l'utilisateur·ice
    const header = screen.getByRole('heading', { level: 1, name: /Playwright/i });
    expect(header).toBeInTheDocument();

    const getStartedLink = screen.getByRole('link', { name: /Get started/i });
    expect(getStartedLink).toBeVisible();
  });
});

Exemple d’utilisation avec Playwright

// tests/homepage.spec.ts
import { test, expect, Page, Locator } from '@playwright/test';
import { PlaywrightHomePage } from '../pages/PlaywrightHomePage';

test.describe('Test du site Playwright via User Facing Attributes', () => {
  test('Vérifier que le titre principal contient "Playwright" et que le lien "Get started" est visible', async ({ page }) => {
    await this.page.goto('https://playwright.dev/');

    // Sélection basée sur des attributs exposés à l'utilisateur·ice
    const header = this.page.getByRole('heading', { level: 1 });
    const getStartedLink = this.page.getByRole('link', { name: /Get started/i });

    await expect(header).toContainText('Playwright');
    await expect(getStartedLink).toBeVisible();
  });
});

Avantages

Robustesse des tests :
Les tests sont moins susceptibles de casser lors de modifications techniques (comme des changements d'attributs CSS ou ordre des balises dans le DOM).
Alignement avec l'UX :
Les sélecteurs utilisés correspondent à ce que voit et utilise réellement l'utilisateur·ice, améliorant ainsi la pertinence des tests.
Promotion des bonnes pratiques d'accessibilité :
Toutes les interfaces ne sont pas toujours dotées d'attributs ou de rôles pertinents, ce pattern incite donc développer des interfaces accessibles et bien structurées.
Lisibilité et clarté :
Les tests sont plus explicites, car ils décrivent les éléments de l'interface tels qu'une personne les perçoit.

Inconvénients

Dépendance au contenu textuel :
Les tests peuvent devenir fragiles si les libellés ou textes changent fréquemment, même si la fonctionnalité reste correcte.
Moins de contrôle sur des sélecteurs complexes :
Pour certaines interactions spécifiques ou des éléments très dynamiques (comme un élément dans un tableau ou une liste de données), il peut être nécessaire d'utiliser des sélecteurs techniques en complément ou remplacement.

Page Object Model

Son objectif principal est de séparer la logique de test (les scénarios et assertions) de la logique d'interaction avec l'interface.

Exemples de code avec Playwright

// pages/PlaywrightHomePage.ts
import { Page, Locator } from '@playwright/test';

export class PlaywrightHomePage {
  readonly page: Page;
  readonly header: Locator;

  constructor(page: Page) {
    this.page = page;

    // On cible ici le titre principal de la page (par exemple, l'élément h1)
    this.header = page.locator('h1');
  }

  // Méthode pour naviguer vers la page d'accueil
  async navigate(): Promise<void> {
    await this.page.goto('https://playwright.dev/');
  }

  // Méthode pour récupérer le texte du titre
  async getHeaderText(): Promise<string | null> {
    return this.header.textContent();
  }
}

Exemple d’utilisation

// tests/homepage.spec.ts
import { test, expect } from '@playwright/test';
import { PlaywrightHomePage } from '../pages/PlaywrightHomePage';

test.describe('Test du site Playwright', () => {
  test('Vérifier que le titre principal contient "Playwright"', async ({ page }) => {
    // Instanciation de la page via notre Page Object
    const homePage = new PlaywrightHomePage(page);
    await homePage.navigate();

    const headerText = await homePage.getHeaderText();

    expect(headerText).toContain('Playwright');
  });
});

Avantages

Séparation des responsabilités :
Le POM sépare la logique de test de l’implémentation de l’interface. Cela permet aux tests de se concentrer sur la validation du comportement métier.
Modularité et évolutivité :
Chaque page ou composant est représenté par une classe spécifique, facilitant ainsi l’organisation et l’évolution de la suite de tests.
Maintenance facilitée :
Lorsqu'une modification est apportée à l'interface (changement de sélecteur, structure HTML modifiée…), il suffit de mettre à jour la classe correspondante, sans toucher aux tests eux-mêmes.
Réutilisabilité :
Les méthodes et sélecteurs encapsulés dans un objet peuvent être réutilisés dans plusieurs tests, réduisant ainsi la duplication de code.
Lisibilité et clarté des tests :
En déléguant les interactions à des objets dédiés, les scénarios de tests restent concis et lisibles. On peut ainsi comprendre rapidement l’intention du test sans se perdre dans les détails d’implémentation.

Inconvénients

Risque de duplication si mal structuré :
Sans une bonne conception, on peut se retrouver avec des classes qui dupliquent des comportements similaires pour des composants récurrents, au lieu d’extraire des composants communs. Dans le cas où on trouverait plusieurs fois le même composant sur une page, il suffit d’y accéder en précisant le bloc parent dans le sélecteur.
Couplage si contenu dans une librairie à part :
Conserver le POM dans un repository / une librairie à part entraîne des problèmes d’alignement des sélecteurs lors de mise à jour des pages.

Screenplay Pattern : alternative au POM

Le Screenplay Pattern est une approche pour structurer les tests d'UI en mettant l'accent sur les actions et les intentions des utilisateur·ices, plutôt que sur la structure technique des pages. Particulièrement utile pour des suites de tests larges et évolutives.

Au lieu de manipuler directement les éléments de l’UI via un Page Object Model (POM), il introduit des "acteur·ices" qui interagissent avec l'interface en utilisant des "tâches" et des "questions".

Exemples de code avec Playwright

import { Page } from '@playwright/test';

// Définition des intéractions
export class EnterText {
  static into(selector: string, text: string) {
    return async (page: Page) => {
      await page.fill(selector, text);
    };
  }
}

export class Click {
  static on(selector: string) {
    return async (page: Page) => {
      await page.click(selector);
    };
  }
}

// Définition des tâches
export class Login {
  static withCredentials(username: string, password: string) {
    return async (page: Page) => {
      await EnterText.into('#username', username)(page);
      await EnterText.into('#password', password)(page);
      await Click.on('#login-button')(page);
    };
  }
}

// Définition des questions
export class IsLoggedIn {
  static async answeredBy(page: Page) {
    return await page.locator('#welcome-message').isVisible();
  }
}

Exemple d’utilisation

// tests/login.spec.ts
import { test, expect } from '@playwright/test';
import { Login, IsLoggedIn } from './login-screenplay';

test('Alice peut se connecter', async ({ page }) => {
  await page.goto('https://example.com/login');

  // L'utilisateur·ice joue le rôle d'un·e acteur·ice réalisant une tâche
  await Login.withCredentials('alice', 'securepassword')(page);

  // Vérification de la connexion
  const loggedIn = await IsLoggedIn.answeredBy(page);
  expect(loggedIn).toBe(true);
});

Avantages

Modularité :
Les interactions et tâches sont réutilisables.
Lisibilité :
Le code ressemble plus à un scénario utilisateur.
Maintenance facilitée :
Modifier l’implémentation d’une interaction ne casse pas toute la suite de tests.
Scalabilité :
Facilite l’ajout de nouvelles tâches sans dupliquer du code.

Inconvénients

Complexité initiale :
Plus de fichiers et d'abstraction qu'un simple Page Object Model qui est parfois suffisant pour de petits tests simple.
Courbe d’apprentissage :
Nécessite de bien comprendre la séparation entre acteurs, tâches et interactions.

Outils et bibliothèques populaires pour des test d’UI

Testing Library

Testing library est une solution légère pour tester des UI en interagissant avec le DOM de manière similaire à une personne. Son approche repose sur la recherche et l'interaction avec les éléments via leurs user-facing attributes.

Playwright

Playwright est un outil d'automatisation de navigateurs conçu pour offrir une developer experience confortable et puissante. Il prend en charge plusieurs langages (TypeScript, JavaScript, Python, C#, Java) et permet de tester des applications sur différents navigateurs (Chromium, Firefox, WebKit) et plateformes (Windows, Linux, macOS).

Son API facilite la manipulation du DOM et intègre nativement les user-facing attributes pour interagir avec les éléments. Playwright se distingue également par ses fonctionnalités avancées comme le record & replay, les tests en parallèle, et le debugging interactif avec des outils visuels comme le trace viewer.

Mieux tester en optimisant la génération de données de test : Panorama des patterns

Manon Carbonnel — Thu, 13 Mar 2025 16:36:41 +0000

Article co-écrit avec @singebob

Écrire des tests automatisés efficaces ne se résume pas à vérifier que notre code fonctionne : il faut aussi que les tests soient lisibles, maintenables et rapides à écrire. Pour cela, la manière dont on génère les données de test joue un rôle clé.

Les patterns que nous vous présentons permettent d’éviter de la duplication, de rendre les tests plus clairs et de mieux maîtriser la complexité des objets manipulés.

Dans cet article, nous allons explorer différentes approches, leurs avantages et leurs limites, et cibler la stratégie à adopter selon le contexte.

Pourquoi faire varier ses jeux de données ?

Pour certains tests, il est primordial de rendre visible la variation des données afin d'expliciter la règle métier sous-jacente.

Par exemple, pour déterminer si un utilisateur est majeur, vous devez modifier son âge dans vos tests et créer deux fixtures. Cependant, ce qui vous intéresse réellement, c'est de voir la règle métier apparaître clairement dans vos tests. Il est crucial de bien mettre en évidence l'âge que vous attribuez.

💡 Ces patterns ne sont pas spécifiques au langage TypeScript que nous avons choisi dans nos exemples, et sont implémentables avec n’importe quel langage généraliste.

Utilisation des Fixtures

Les Fixtures sont des ensembles de données préconfigurées utilisées pour initialiser l'état d'un test. Elles permettent de définir des conditions de test spécifiques et de garantir que les tests sont reproductibles.

Exemples de code pour créer et utiliser des Fixtures en TypeScript

// personaFixtures.ts
export const johnDoe: User = {
  id: 1,
  name: 'John Doe',
  email: 'john.doe@example.com'
  // ... your full Persona caracteristics, to be used in several tests
};

// test.ts
import { johnDoe } from './personaFixtures';

test('should create a user', () => {
  const user = createUser(johnDoe);
  // ...code
  expect(user).toEqual(johnDoe);
});

Avantages

Simplicité et facilité d'utilisation.
Reproductibilité des tests.
Utilisation des persona UX

Inconvénients

Peuvent devenir difficiles à gérer pour des ensembles de données complexes.
Moins flexibles pour des variations de données.

Utilisation des Object Mother

Le pattern Object Mother consiste à créer des objets complexes à partir de méthodes de fabrication centralisées. Cela permet de simplifier la création d'objets de test et de garantir la cohérence des données.

Exemples de code pour créer des objets complexes avec des Object Mothers en TypeScript

// objectMother.ts
export class UserMother {
  static create(): User {
    return {
      id: 1,
      name: 'John Doe',
      email: 'john.doe@example.com'
    };
  }
}

// test.ts
import { UserMother } from './objectMother';

test('should create a user', () => {
  const user = UserMother.create();
  expect(user).toEqual({
    id: 1,
    name: 'John Doe',
    email: 'john.doe@example.com'
  });
});

Avec un objet plus complexe :

Les types

// interfaces.ts
export interface Item {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

export interface Order {
  id: number;
  customerName: string;
  items: Item[];
  total: number;
}

Object Mother pour Order

// orderMother.ts
import {Order} from "./interface";

export class OrderMother {
    static with2Items(): Order {
        const items = [{id: 2, name: 'A very specific item', price: 10, quantity: 2}, {id: 3, name: "Another specific item", price: 300, quantity: 1}];
        return {
            id: 25,
            customerName: "Rich customer",
            items: items,
            total: items.reduce((previousValue, currentValue) => previousValue + (currentValue.price * currentValue.quantity), 0)
        }
    }

    static withoutItems(): Order {
        return {
            id: 25,
            customerName: "Poor customer",
            items: [],
            total: 0
        }
    }

    static johnDoeBuysATable(): Order {
        const items = [{id: 1, name: 'Table', price: 500, quantity: 1}];
        return {
            id: 25,
            customerName: "John Doe",
            items: items,
            total: items.reduce((previousValue, currentValue) => previousValue + (currentValue.price * currentValue.quantity), 0)
        }
    }
}

Exemple d’utilisation

// test.ts
import {OrderMother} from "./orderMother";

describe("Order Mother", () => {
    it('should create an order with items', () => {
        const order = OrderMother.with2Items();
        expect(order.items).toHaveLength(2)
        expect(order.total).toBe(320)
    });

    it('should create an order without items', () => {
        const order = OrderMother.withoutItems();
        expect(order.items).toHaveLength(0)
        expect(order.total).toBe(0)
    });
});

Avantages

Centralisation de la création d'objets.
Facilité de maintenance.

Inconvénients

Peut devenir complexe pour des objets très variés.
Moins flexible pour des variations spécifiques.

Utilisation des Factory Functions

Les Factory Functions sont des fonctions qui retournent des objets. Elles sont simples à utiliser et permettent de créer des objets de manière concise.

Exemples de code pour créer des objets avec des Factory Functions en TypeScript

💡 En TypeScript, l'utilisation du type Partial offre un avantage supplémentaire. Le type Partial permet de créer des objets partiels, ce qui signifie que vous pouvez définir uniquement les propriétés nécessaires pour un test spécifique. Cela rend les tests plus lisibles et plus faciles à maintenir. Vous pouvez déstructurer votre type pour rendre votre test plus lisible et explicite.

type User = {
  id: number;
  name: string;
  email: string;
};

export function createUser({ id = 1, name = 'Jane Doe', email = 'jane.doe@example.com' }: Partial<User>): User {
  return {
    id,
    name,
    email,
  };
}

test('should create a user', () => {
    const user = createUser({ name: 'Jonh Doe', email: 'john.doe@example.com' });
    expect(user).toEqual({
      id: 1,
      name: 'Jonh Doe',
      email: 'john.doe@example.com',
    });
  });

Avantages

Simplicité et facilité d'utilisation.
Flexibilité pour créer des objets avec des variations spécifiques.

Inconvénients

Moins adapté pour des objets très complexes.
Peut devenir difficile à gérer pour des ensembles de données importants.

Utilisation des Test Data Builders / Builders

Le pattern Builder permet de construire des objets complexes de manière incrémentale. Il est particulièrement utile pour créer des objets avec des variations spécifiques.

Exemples de code pour créer des objets complexes avec des builders en TypeScript

// userBuilder.ts
export class UserBuilder {
  private user: User = {
    id: 1,
    name: 'John Doe',
    email: 'john.doe@example.com'
  };

  withName(name: string): UserBuilder {
    this.user.name = name;
    return this;
  }

  withEmail(email: string): UserBuilder {
    this.user.email = email;
    return this;
  }

  build(): User {
    return this.user;
  }
}

// test.ts
import { UserBuilder } from './userBuilder';

test('should create a user with custom name', () => {
  const user = new UserBuilder().withName('Jane Doe').build();
  expect(user).toEqual({
    id: 1,
    name: 'Jane Doe',
    email: 'john.doe@example.com'
  });
});

Avec un objet plus complexe:

Les types

// interfaces.ts
export interface Item {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

export interface Order {
  id: number;
  customerName: string;
  items: Item[];
  total: number;
}

Test Data Builder pour Order

// ItemBuilder.ts
import {Item} from "./interface";

export class ItemBuilder {
    private readonly item: Item

    constructor() {
        this.item = {id: 1, name: 'Default Item', price: 100, quantity: 1}
    }

    public withName(name: string): this {
        this.item.name = name
        return this
    }

    public withId(id: number): this {
        this.item.id = id
        return this
    }

    public withPrice(price: number): this {
        this.item.price = price
        return this
    }

    public withQuantity(quantity: number): this {
        this.item.quantity = quantity
        return this
    }

    public build(): Item {
        return this.item
    }
}

import {Item, Order} from "./interface";
import {ItemBuilder} from "./itemBuilder";

export class OrderBuilder {
    private readonly order: Order

    constructor() {
        this.order = {id: 1, items: [new ItemBuilder().withPrice(20).build()], total: 20, customerName: "Alice"}
    }

    public withCustomerName(name: string): this {
        this.order.customerName = name
        return this
    }

    public withItems(...items: Item[]): this {
        this.order.items = items
        this.order.total = items.reduce((previousValue, currentValue) => previousValue + (currentValue.price * currentValue.quantity), 0)
        return this
    }

    public build(): Order {
        return this.order
    }
}

Exemple d’utilisation

describe("Simple test", () => {
    it('should create an order with default builder', () => {
        const order = new OrderBuilder().build()
        expect(order.items).toHaveLength(1)
        expect(order.total).toBe(20)
    });

    it('should create an order with 2 items', () => {
        const order = new OrderBuilder().withItems(
            new ItemBuilder().withPrice(100).build(),
            new ItemBuilder().withPrice(10).withQuantity(5).withId(2).build()
        ).build();
        expect(order.items).toHaveLength(2)
        expect(order.total).toBe(150)
    });

    it("should create a John Doe's order", () => {
        const order = new OrderBuilder().withCustomerName("John Doe").build();
        expect(order.customerName).toBe("John Doe")
    });
});

Avantages

Flexibilité pour créer des objets avec des variations spécifiques.
Facilité de lecture et de maintenance.

💡 Vous pouvez également créer des builders avec des valeurs par défaut. C'est ce que recommande le livre "Growing Object-Oriented Software, Guided by Tests". Vous aurez ainsi une ou plusieurs méthodes statiques qui vous permettront de configurer vos tests à partir de personas ou de cas métiers spécifiques.

Inconvénients

Peut devenir verbeux pour des objets simples.
Nécessite une configuration initiale.

Nos préférences pour la création de jeu de données

Pour nous, ce qui est important, c'est d'avoir une série de tests qui soit lisible et facile à écrire. C'est pourquoi nous mettons en avant trois critères pour choisir le pattern que nous voulons utiliser :

Visibilité des Variations de Données
API Fluide et Lisibilité
Simplicité et Flexibilité

C’est pour cela que nous préférons les patterns Factory Function et Test Data Builder.

💡 Nous avons des préférences pour ces patterns, mais parfois nous allons utiliser une fixture ou un object mother, car le nommage métier peut être plus explicite que la simple variation des données, etc.

Pourquoi le pattern Factory Function ?

Pour des objets simples et sans profondeur, le pattern Factory Function est une approche efficace. Elle permet de créer des objets de manière concise.

L'utilisation du type Partial en TypeScript facilite la création d'objets partiels, ce qui est particulièrement utile pour les tests.

Pourquoi le pattern Test Data Builder ?

Le pattern Builder est particulièrement adapté pour les objets avec plusieurs niveaux de profondeur. Il permet de construire des objets complexes de manière incrémentale, en chaînant des méthodes pour définir les différentes propriétés de l'objet. Cette approche offre une grande flexibilité et permet de voir facilement les variations de données, ce qui est crucial pour valider les tests.

Outils et bibliothèques populaires pour la création de jeux de données

faker.js

Génération de données fictives réalistes.
Idéal pour tester des scénarios avec des données variées.

factory.ts

Création structurée d'objets de test.
Idéal pour des objets complexes et des variations spécifiques.

faker.js

faker.js est une bibliothèque populaire pour générer des données fictives. Elle permet de créer des données réalistes pour les tests.

// fakerExample.ts
import faker from 'faker';
import type { Email } from "./email.js";

test('should generate a fake user', () => {
  const user = {
    id: 1,
    name: faker.name.findName(),
    email: faker.internet.email()
  };
  expect(user).toEqual({
    id: 1,
    name: expect.any(String),
    email: expect.any(Email)
  });
});

factory.ts

factory.ts est une bibliothèque TypeScript pour créer des objets de test de manière structurée.

// factoryExample.ts
import { Factory } from 'factory.ts';

interface User {
  id: number;
  name: string;
  email: string;
}

const userFactory = Factory.Sync.makeFactory<User>({
  id: Factory.each((i) => i),
  name: 'John Doe',
  email: 'john.doe@example.com'
});

test('should create a user with factory.ts', () => {
  const user = userFactory.build();
  expect(user).toEqual({
    id: expect.any(Number),
    name: 'John Doe',
    email: 'john.doe@example.com'
  });
});

Conclusion

À partir de quoi faire varier les données ?

Nous vous recommandons fortement de faire varier vos données à partir de personas UX ou de cas métiers bien identifiés. Ces éléments définiront vos valeurs par défaut pour la plupart des patterns décrits ci-dessus. L'objectif d'avoir ces valeurs par défaut (personas UX ou cas métiers) est de rendre vos tests lisibles et de les utiliser comme documentation.

Où ranger ces patterns dans le code ?

Ces fichiers servant uniquement aux tests, ils ont leur place à leurs côtés. Vous pouvez l’utiliser à côté du test qui l’utilise, mais s’il y a de la réutilisation ailleurs, il faudra créer un dossier et fichier dédié.

/test
    /order
        /order.ts
    /dataBuilders
        /orderBuilder.ts

La création de jeux de données pour les tests est essentielle pour garantir la qualité et la fiabilité du code. Chaque méthode a ses forces et ses limites, et le choix du bon pattern dépend de la complexité des éléments à générer.

Il n’existe pas de solution universelle : la clé réside dans une réflexion collective et des décisions alignées avec les besoins de votre projet.

Forem: Manon Carbonnel

Tester son interface efficacement : des patterns pour des tests d’UI robustes

User Facing Attributes

Exemples de code pour accéder aux éléments du DOM d’une page web

Avantages

Inconvénients

Page Object Model

Exemples de code avec Playwright

Avantages

Inconvénients

Screenplay Pattern : alternative au POM

Exemples de code avec Playwright

Avantages

Inconvénients

Outils et bibliothèques populaires pour des test d’UI

Testing Library

Playwright

Mieux tester en optimisant la génération de données de test : Panorama des patterns

Pourquoi faire varier ses jeux de données ?

Utilisation des Fixtures

Exemples de code pour créer et utiliser des Fixtures en TypeScript

Avantages

Inconvénients

Utilisation des Object Mother

Exemples de code pour créer des objets complexes avec des Object Mothers en TypeScript

Avantages

Inconvénients

Utilisation des Factory Functions

Exemples de code pour créer des objets avec des Factory Functions en TypeScript

Avantages

Inconvénients

Utilisation des Test Data Builders / Builders

Exemples de code pour créer des objets complexes avec des builders en TypeScript

Avantages

Inconvénients

Nos préférences pour la création de jeu de données

Pourquoi le pattern Factory Function ?

Pourquoi le pattern Test Data Builder ?

Outils et bibliothèques populaires pour la création de jeux de données

faker.js

factory.ts

faker.js

factory.ts

Conclusion

À partir de quoi faire varier les données ?

Où ranger ces patterns dans le code ?

Pour aller plus loin