Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Hier je discutais avec Xavier Knopp et il nous parlait de son expérience,
de comment il était rentré à la découverte d'un nouveau SDK qu'il découvrait justement.
C'est un SDK qui travaille sur une blockchain et qui lui permet de faciliter le travail
dans justement l'interaction avec cette blockchain.
Sauf qu'à un moment donné il est obligé de rentrer dans les couches basses
et donc il utilise les tests pour partir à la découverte de ce SDK.
Il a quelques déconvenus avec les tests et une en particulier qui m'intéresse,
il dit le dernier test qu'il doit faire passer, c'est un test qui nécessite
à un moment donné une vraie blockchain.
Et en fait c'est quoi ce test là ? Probablement c'est un test un tout un test
c'est à dire qu'à un moment donné oui il faut s'appuyer sur une vraie blockchain
ce qui n'est pas quand même complètement délirant
quand tu parles dans un SDK qui travaille avec la blockchain.
Et finalement c'est une bonne pratique à un moment donné d'avoir un test un tout un
et je trouve même que le fait de n'en avoir qu'un dans toute la batterie test
c'est plutôt un bon signe parce qu'en fait ça veut dire tout simplement
qu'ils ont bien abstrait toute une partie, enfin tous les autres tests sont bien abstrés
de cette blockchain sauf qu'à un moment donné ben oui
il te faut bien un vrai test un tout un.
Ça c'est un point d'alerte je te mets en garde, les tests unitaires c'est très bien
ça permet d'aller vite parce qu'il s'exécute facilement mais n'oublie pas à un moment donné quand même
d'avoir aussi des tests qui vérifient de bout en bout que l'ensemble fonctionne
parce que sinon tu te retrouves avec un système
où les tests, les composants sont bien isolément testés
mais tient rien qui vérifie que l'ensemble fonctionne correctement.
Alors là ce que j'avais envie de partager avec toi aujourd'hui
c'est une bonne pratique justement pour gérer ces tests là
qui vont avoir un fonctionnement différent
ou en tout cas des exigences différentes selon l'environnement dans lequel ils sont lancés
parce que des bons tests sont indépendants normalement de l'environnement dans lequel ils sont
et nous ce qu'on fait en ce moment on travaille sur un projet qui manipule les données sensibles
ce qu'on fait tout simplement c'est qu'on utilise les tags
tu n'es pas obligé à chaque fois d'exécuter tous les tests
tu peux avoir une stratégie de test qui s'appuie sur les tags
et c'est très pratique parce que du coup tu peux taguer tes différents tests
tu peux par exemple taguer tes tests qui sont lents
tu vas taguer tes tests qui dépendent justement d'éléments
ou tu n'es pas sûr de l'avoir au moment où tu run ton test
et comme ça tu peux modifier ta ligne de commande
configurer ta ligne de commande pour exclure par défaut ces tests là
et du coup quand tu lances ces tests tu ne lances que ceux dont tu es sûr qu'ils fonctionnent
voilà j'espère que cette astuce te sera utile
et te donnera envie d'aller creuser un petit peu plus la doc d'API de ta bibliothèque de test
et puis bah écoute je te remercie d'avoir écouté ce podcast jusqu'au bout
dis moi si ça t'a été utile tu peux m'envoyer un feedback à benoîtarobaseartisandeveloper.fr
si tu utilises déjà les tags je suis très curieux de savoir comment tu configures ta stratégie de test
comment tu les utilises, quelle tag tu utilises
et puis je te donne rendez vous à demain sur le podcast