Julien Braure
Delia Technologies - CTO
Delia Technologies - CTO
Nantes, France
Actions
Julien est LeadTech, ayant plus de 15 ans d'experience, il evolue dans des stack tant en PHP que Java. Julien aime les choses simples et bien faites. Depuis 2015, il profite de la douceur de vivre nantaise en vélo biporteur.
Julien est LeadTech, ayant plus de 15 ans d'experience, il evolue dans des stack tant en PHP que Java. Julien aime les choses simples et bien faites. Depuis 2015, il profite de la douceur de vivre nantaise en vélo biporteur.
Area of Expertise
Topics
Mutation Testing
Manual testing, on a fait mieux... Automated Unit Testing, un bon début. Integration Testing, un cran plus haut. Et après ?
Lors de nos procédures de tests, le code-coverage est (trop) souvent la metric reine mise en avant. Cependant, c'est plutôt le nombre d'assertions qui prime. Le code-coverage étant surtout le nombre de lignes ayant été exécutées durant les tests.
En poussant à l'extrême, on peut facilement imaginer un code 100% "couvert" par les tests, mais avec 0 assertion... Ces tests "blancs" passeront donc quelques soient les entrées et n'apporteront aucune valeur ajoutée.
Une autre hantise du testeur est de ne jamais faire confiance à un test que l'on a jamais vu "FAIL".
C'est là que le Mutation Testing entre en scène !
Des frameworks existent (Infection en PHP, PIT en Java... ) qui, à partir des 2 "artifacts" déjà présents dans votre projet, le code source et les tests existants, vont simplement :
1. Modifier votre code (1 modification = 1 mutation)
2. Faire tourner les tests
3. S'attendre à ce que vos tests "détectent" cette mutation en reportant au moins 1 test FAIL
4. Répéter avec 1 nouvelle mutation
Cette approche simple et peu coûteuse permet d'avoir un bon retour sur la qualité et la valeur réelle de vos tests. Le tout avec le plaisir infini de tuer des mutants ;-)
TestContainers : Arrêtez de vous "mocker" de vos dépendances
Les tests unitaires c'est bien, les tests d'integration c'est mieux :-)
Les tests d'intégrations nous permettent de vérifier l'interaction de notre système avec ses dépendances externes, comme par exemple une base de données.
Cependant il peut être difficile d'avoir ces dépendances accessibles.
Exemple dans le cas d'une base SQL, il existe des substituts "in-memory" comme H2. Mais ces systèmes ont leurs limites et spécificités et au final ne sont pas exactement identiques à la dépendance réelle.
Dans l'idéal, il serait intéressant de pouvoir démarrer des containers Docker à la demande, au cours de nos test, et contenant les dépendances de nos applications.
C'est maintenant possible avec TestContainers, voyons une demo avec SpringBoot, JUnit5 et MongoDB.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top