Jusqu’au mois de mai 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Et si l'on scénarisait nos fixtures ? Les fixtures sont souvent utilisées pour générer des données, servant ainsi de fondation pour les tests fonctionnels et le développement. Il est possible de générer les objets un à un. Cependant, qu'en est-il lorsqu'on a un système complexe utilisant une machine à état, de nombreux fichiers et de l'envoi de mail ? Pourquoi ne pas exploiter ce mécanisme pour initier nos objets et les faire évoluer au sein de l'application ? Cette présentation proposera un retour d'expérience sur un parcours complet, allant de l'outillage de génération de données à l'écriture de scénarios applicatifs, sans négliger aucune étape pour maîtriser vos données.

Bordeaux Ynov Campus 22/05/2026 16:40-17:20

Quelles sont les principes ou patterns qui t’aident le plus dans la génération de données ?

Au départ, je n’avais pas de pattern précis et j’ai fait un peu comme je le sentais.

Mon objectif était de générer des données pour coder un écran sans perdre trois heures dans l’interface pour obtenir les données nécessaires en entrée de l’écran.
En me documentant, j’ai découvert le principe d’Object Mother, une sorte de factory qui facilite (ou pas) la création d’objets pour un ensemble donné.
Un autre principe que j’ai découvert en préparant cette conférence est le Context Driven Test.
En effet, les tests dépendent du contexte, qui permet une prédictibilité des résultats.
Le contexte est d’ailleurs la base de tout projet :

• Pourquoi cette architecture ? À cause du contexte.
• Pourquoi cette implémentation ? À cause du contexte.
• Je m’attends à tel résultat ? Oui, mais dans quel contexte ?
• Claude « Dessine moi un mouton » ? Oui, mais dans quel contexte ?

Dirais-tu que cette approche a réduit la charge de maintenance et d’évolution de tes fixtures ?

Absolument. On commence par poser les bases, puis c’est l’application elle-même qui fait évoluer nos données.
Bien sûr, certaines données ou principes nécessitent une maintenance, mais l’évolution des entités est déléguée aux services ou aux commandes de l’application.
Tant que les interfaces d’entrée ne changent pas, les fixtures n’ont (presque) pas besoin d’être mises à jour.

On passe plus de temps à ajouter des cas de test ou des fonctionnalités aux fixtures qu’à gérer les impacts des évolutions de l’application sur les fixtures.

Est-ce que les fixtures et le pattern AAA (Arrange act assert) dans les tests sont compatibles ?

Les fixtures que l’on met en place font du AAA sans totalement faire le dernier A (Assert).
Les fixtures que nous mettons en place s’inscrivent dans une logique AAA, mais sans toujours couvrir entièrement la phase d’Assert.
Par exemple, lorsqu’une entité évolue dans une machine à états, l’étape N-1 est validée par la possibilité de passer à l’étape N.
L’assertion est partielle, car on ne vérifie pas d’autres données.

Le but premier de ces fixtures est de fournir un contexte, que ce soit pour des tests (manuels ou automatisés), la reproduction de bugs, un cas de test précis pour un écran, ou encore des cas de test invariants pour une application tierce.

Une conférence présentée par

Nicolas GUÉRINET

Après dix ans de chefferie de projet, Nicolas a opéré un changement de carrière il y a 6 ans pour embrasser des sujets techniques en tant que Lead Dev backend et l'architecture.

Autres interviews