Une seule suite de tests qui s'exécute en mémoire pour des tests rapides et en "end-to-end" pour des conditions plus réelle : c'est possible ?
Oui ! Grâce à une petite abstraction sous forme de DSL 👇
Les tests d'acceptation sont des tests permettant de vérifier que le comportement de notre logiciel est "acceptable".
En gros, si on a bien fait notre job quoi 💪
Lorsque l'on commence à bosser sur une nouvelle fonctionnalité, il est toujours très important de se poser deux minutes et réfléchir à ce que l'on doit faire.
C'est le meilleur moment pour rédiger ce que l'on appelle une "spécification exécutable".
📝 spécification : ça représente un scénario d'utilisation avec certaines conditions d'acceptation
💻 exécutable : elle doit pouvoir s'exécuter automatiquement et être auto-vérifiable, c'est-à-dire qu'en l'exécutant, on doit directement savoir si la spécification est implémentée correctement ou non.
Une très bonne façon de faire est donc tout simplement de rédiger un test !
On ne s'occupe pas du tout de l'implémentation, on cherche finalement juste à comprendre ce que l'on a en entrée du système, sur quoi on interagit, et ce qu'on attend en sortie.
Il n'y pas une seule manière de faire, mais écrire des phrases lisibles et compréhensibles par n'importe qui du projet, directement dans le code, est une méthode qui fonctionne bien !
Ce faisant, notre test répond à l'acronyme D.A.M.P : Descriptive And Meaningful Phrases.
Et ça, c'est notre DSL (Domain Specific Language) qui naît sous nos yeux ébahis !
Ce genre de spécifications exécutables peut tout à fait être utilisé pour guider notre développement, dans le cadre d'une approche TDD par exemple.
On utilisera alors principalement des dépendances "in-memory" pour garder des tests très rapides et déterministes.
Cette spécification peut aussi servir de test d'acceptation plus large ! En partant directement de l'API par exemple (si le projet est une API). Ici, on garde les vraies dépendances. Ces tests seront donc plus longs, mais non moins importants.
Voici un exemple :
Évidemment, je n'écris pas tous mes tests de cette façon, si j'ai besoin d'être plus granulaire dans mes tests unitaires, je vais utiliser des tests plus fins, sans DSL.
Partagez ce post
des tests d'acceptation "en mémoire" et "end-to-end"
Partagez ce post
Hello !
Une seule suite de tests qui s'exécute en mémoire pour des tests rapides et en "end-to-end" pour des conditions plus réelle : c'est possible ?
Oui ! Grâce à une petite abstraction sous forme de DSL 👇
Les tests d'acceptation sont des tests permettant de vérifier que le comportement de notre logiciel est "acceptable".
En gros, si on a bien fait notre job quoi 💪
Lorsque l'on commence à bosser sur une nouvelle fonctionnalité, il est toujours très important de se poser deux minutes et réfléchir à ce que l'on doit faire.
C'est le meilleur moment pour rédiger ce que l'on appelle une "spécification exécutable".
📝 spécification : ça représente un scénario d'utilisation avec certaines conditions d'acceptation
💻 exécutable : elle doit pouvoir s'exécuter automatiquement et être auto-vérifiable, c'est-à-dire qu'en l'exécutant, on doit directement savoir si la spécification est implémentée correctement ou non.
Une très bonne façon de faire est donc tout simplement de rédiger un test !
On ne s'occupe pas du tout de l'implémentation, on cherche finalement juste à comprendre ce que l'on a en entrée du système, sur quoi on interagit, et ce qu'on attend en sortie.
Il n'y pas une seule manière de faire, mais écrire des phrases lisibles et compréhensibles par n'importe qui du projet, directement dans le code, est une méthode qui fonctionne bien !
Ce faisant, notre test répond à l'acronyme D.A.M.P : Descriptive And Meaningful Phrases.
Et ça, c'est notre DSL (Domain Specific Language) qui naît sous nos yeux ébahis !
Ce genre de spécifications exécutables peut tout à fait être utilisé pour guider notre développement, dans le cadre d'une approche TDD par exemple.
On utilisera alors principalement des dépendances "in-memory" pour garder des tests très rapides et déterministes.
Cette spécification peut aussi servir de test d'acceptation plus large ! En partant directement de l'API par exemple (si le projet est une API). Ici, on garde les vraies dépendances. Ces tests seront donc plus longs, mais non moins importants.
Voici un exemple :
Évidemment, je n'écris pas tous mes tests de cette façon, si j'ai besoin d'être plus granulaire dans mes tests unitaires, je vais utiliser des tests plus fins, sans DSL.
Happy Coding !
Pierre.