On écrit tous des tests (n’est-ce pas ?), mais comment savoir s’ils sont utiles ?
- Par leur nombre ? Faux, beaucoup de tests ne garantissent pas que l’application fonctionne correctement
- Avec une bonne couverture du code ? Encore faux, mieux mais pas suffisant
L’important est d'être confiant sur la capacité des tests à détecter les problèmes (c’est pourquoi en TDD un test doit échouer au début, pour etre sur qu’il teste bien quelque chose). Laissez-moi donc vous présenter le mutation testing ! Cette technique modifie votre code, lance les tests et s’attend à ce qu’ils échouent. Si non, c’est que cette partie est mal testée… Dans ce talk je détaillerai les principes du mutation testing, expliquerai comment l’utiliser sur un projet scala et montrerai les résultats obtenus sur un projet réel.
Decouvrez les particularités de JavaScript qui vous aideront à débogguer sans craindre ce langage aujourd'hui indispensable.
- la portée des variables et comment ne pas polluer l'espace global
- comprendre le mot clé this
- les particularités des fonctions
- introduction aux namespaces
Loin de la théorie vous aurez des explications pratiques et des démos de code ainsi que les bonnes pratiques.
Rappels d'ordre général sur les tests automatisés (unitaires, fonctionnels, de comportement), suivis d'une introduction à l'écriture de tests unitaires avec PHPUnit. Orienté PHP.
Ce premier cours introduit à plusieurs aspects liés au développement informatique. Le cours présente comment versioner son code avec le système Git et comment le déployer avec Heroku. Il présente ensuite comment débugguer avec le module pdb et comment profiler son code avec les modules timeit et profile. Enfin, le cours termine en présentant le concept de tests unitaires que l'on peut construire avec les modules doctest et unittest.
Decouvrez les particularités de JavaScript qui vous aideront à débogguer sans craindre ce langage aujourd'hui indispensable.
- la portée des variables et comment ne pas polluer l'espace global
- comprendre le mot clé this
- les particularités des fonctions
- introduction aux namespaces
Loin de la théorie vous aurez des explications pratiques et des démos de code ainsi que les bonnes pratiques.
Rappels d'ordre général sur les tests automatisés (unitaires, fonctionnels, de comportement), suivis d'une introduction à l'écriture de tests unitaires avec PHPUnit. Orienté PHP.
Ce premier cours introduit à plusieurs aspects liés au développement informatique. Le cours présente comment versioner son code avec le système Git et comment le déployer avec Heroku. Il présente ensuite comment débugguer avec le module pdb et comment profiler son code avec les modules timeit et profile. Enfin, le cours termine en présentant le concept de tests unitaires que l'on peut construire avec les modules doctest et unittest.
Formation Gratuite Total Tests par les experts Java Ippon Ippon
Garantissez la qualité des vos applications par des tests efficaces : unitaire, d'intégration, de performance... Apprenez à mettre en oeuvre un harnais de tests complet et efficace avec Junit, AssertJ, Mockito, Spring Test, Arquillian, ... et assimilez les concepts du TDD et du BDD, illustré avec Cucumber. La formation Total Test Training ira encore plus loin en vous présentant l'utilisation de Sonar et le rôle des tests dans un système d'intégration continue. Enfin, les aspects liés à la mesure de la performance (instrumentation avec Metric et stress test avec JMeter et Gatling) et à l'optimisation ciblée vous permettront d'être en mesure de produire un code "propre", protégé des risques de regressions.
Infra as Code, choisissez vous la pilule rouge ou la pilule bleue - Devoxx 2016Fabien Arcellier
Après maints périples, vous avez progressivement amélioré votre capacité à gérer des environnements au travers d'Infra as Code. Votre code initialement simple a pris de l'embonpoint et vous sentez la réalité vous rattraper implacablement : vous êtes en train de créer de la complexité, voire même de la dette.
Loin d'être une fatalité, à partir de notre expérience de développeur (Fabien) et d'ops (Alexandre), nous vous proposons un road trip dans des
pratiques de développement déclinées sur l'Infra as Code (Bash, Puppet et Ansible).
Nous présentons des pratiques, des plus simples activables immédiatement à des démarches plus complexes pour dessiner une big picture de l'Infra as Code, de ses contraintes, de ses forces et de ses pièges.
* Comment mettre en place des boucles de feedback les plus courtes possibles ?
* Comment faire du test driven development sur l'infrastructure ?
* Quels patterns et outils pour tester une configuration sans tirer toute votre infra et itérer plus rapidement ?
* Quel est le rapport entre Tetris, un ascenceur et l'Infra as Code ?
Tester unitairement une application javaAntoine Rey
Présente les différents types de tests automatisés, les objectifs des tests unitaires, les stratégies de mise en œuvre, les bonnes pratiques, les difficultés, ce qu'est un mock, différents outils (Unitils, Mockito, DbUnit, Spring Test) et des exemples de tests (DAO et contrôleurs Spring MVC), sans oublier le test de code legacy.
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...Cyrille Grandval
De nos jours de plus en plus d'entreprises ne jurent que par les tests unitaires. Faire du test, faire du test, faire du test ! “Une application n'est pérenne que si elle est testée et elle est testée si plus de 80% du code est couvert.”
Cela devient même un élément décisif du recruteur en entretien :
- Votre collaborateur a l'air vraiment bien mais... Il a déjà fait des tests unitaires ? Il a plus de deux ans d'expérience là dessus ?
- Juste sur deux projets, par contre il possède la bonne philosophie.
- Ah oui mais non il faut qu'il en ait fait 2 ans, c'est un minimum. On cherche des experts nous !
Problématique : "Je veux minimum 80% de couverture de code !!!" Qui n'a pas entendu cette phrase dans la bouche d'un chef de projet ou d'un lead dev trop consciencieux sans doute.
Dans certains projets un test unitaire est bon si il couvre au moins 80% de la fonctionnalité à tester, c'est tout ce qui est demandé et c'est cela qu'il faut avoir. Il est avant tout essentiel de s'interroger sur la notion de couverture de code dans un test unitaire : La couverture de code est-elle un but ? un facteur qualité ? une représentation visuelle d'un test ? Ou est-ce cet horrible fantôme qui vient hanter une application ?
Pour faire simple : un test qui couvre 100% du code à tester est-il forcement fiable ?
Conférence PHPTour Lyon 2014 - Tests unitaires - Je veux mes 80% de couverture de code !!!! http://afup.org/pages/phptourlyon2014/sessions.php#1094
Survole de l'industrialisation pour les étudiants pour http://src-media.com/ et d'anciens étudiants.
Inspirez de http://hoa-project.net/Fr/Event/Phptour14.html pour le Slide 8.
Rédigé en Mars 2013
Comment automatiser les tests ?
Les différents types de tests automatisés : TU, BDD/TDD, GUI, TDC, Test de vie …
Méthodes d’automatisation
Capture/replay
Projet de développement
Techniques d’automatisation
Data driven
Keyword driven
DSTL
Composants technique pour l’automatisation
Oracle
Bouchon
Techniques de comparaison
Reporting
Rédigé en Mars 2013
Introduction : ce que l’on va couvrir (et ne pas couvrir)
Définition : Qu’est-ce que l’automatisation des tests ?
Objectifs : Pourquoi automatiser ?
Couverture :
Qu’est-ce qu’on automatise ?
Pre et Post Process
Comment déterminer ce qu’on automatise ?
Responsabilité : Qui fait quoi?
ROI : Combien ça coute ?
Infrastructure de test
Processus d’automatisation
Conclusion
Une conférence de 2h30 (aka université) faites à Devoxx France en 2021 avec Maxime Gellé. On y fait un tour d'horizon des tests logiciels: TDD, Test unitaire vs Test d'integration, l'apport de l'archi hexagonale, Contract testing, property based testing, UI testing ... mais aussi comment "tester en production" !
Plop : un micro-générateur pour se simplifier la vie au quotidienNicolas Carlo
Plop : un micro-générateur pour se simplifier la vie au quotidien. Talk présenté le 21 décembre 2015 au meetup Node.js Paris Chapitre 3 / Conférence 2.
Industrialiser le contrat dans un projet PHPhalleck45
La notion de contrat intervient à tous les étages en PHP : du code source au besoin fonctionnel, en passant par la nécessité de travailler en équipe ou de fournir un travail clair et compréhensible. Petit tour d'horizon des outils qui vous permettront de vous assurer automatiquement que ces contrats sont bien respectés.
Conférences lors du rendez-vous AFUP Nantes du 29 octobre 2012
This course will introduce the core data structures of the Python programming language. We will move past the basics of procedural programming and explore how we can use the Python built-in data structures such as lists, dictionaries, and tuples to perform increasingly complex data analysis.
Discover some of bad practices in Scala and how to avoid them.
This talk is mainly about functionnal programming style but only with very simple concepts.
Comprendre la programmation fonctionnelle, Blend Web Mix le 02/11/2016Loïc Knuchel
Vous commencez à en entendre parler de plus en plus mais vous avez encore du mal à voir ce que c’est et à comprendre de que ça change concrètement, ce talk est fait pour vous !!!
La programmation fonctionnelle est une manière de programmer basée sur les fonctions qui permet de faire du code vraiment modulaire, améliorer la qualité et limiter les bugs. Vous ne me croyez pas ? Venez voir cette session !
Contenu connexe
Similaire à Mutation testing, enfin une bonne mesure de la qualité des tests ?, RivieraDev le 18/05/2018
Formation Gratuite Total Tests par les experts Java Ippon Ippon
Garantissez la qualité des vos applications par des tests efficaces : unitaire, d'intégration, de performance... Apprenez à mettre en oeuvre un harnais de tests complet et efficace avec Junit, AssertJ, Mockito, Spring Test, Arquillian, ... et assimilez les concepts du TDD et du BDD, illustré avec Cucumber. La formation Total Test Training ira encore plus loin en vous présentant l'utilisation de Sonar et le rôle des tests dans un système d'intégration continue. Enfin, les aspects liés à la mesure de la performance (instrumentation avec Metric et stress test avec JMeter et Gatling) et à l'optimisation ciblée vous permettront d'être en mesure de produire un code "propre", protégé des risques de regressions.
Infra as Code, choisissez vous la pilule rouge ou la pilule bleue - Devoxx 2016Fabien Arcellier
Après maints périples, vous avez progressivement amélioré votre capacité à gérer des environnements au travers d'Infra as Code. Votre code initialement simple a pris de l'embonpoint et vous sentez la réalité vous rattraper implacablement : vous êtes en train de créer de la complexité, voire même de la dette.
Loin d'être une fatalité, à partir de notre expérience de développeur (Fabien) et d'ops (Alexandre), nous vous proposons un road trip dans des
pratiques de développement déclinées sur l'Infra as Code (Bash, Puppet et Ansible).
Nous présentons des pratiques, des plus simples activables immédiatement à des démarches plus complexes pour dessiner une big picture de l'Infra as Code, de ses contraintes, de ses forces et de ses pièges.
* Comment mettre en place des boucles de feedback les plus courtes possibles ?
* Comment faire du test driven development sur l'infrastructure ?
* Quels patterns et outils pour tester une configuration sans tirer toute votre infra et itérer plus rapidement ?
* Quel est le rapport entre Tetris, un ascenceur et l'Infra as Code ?
Tester unitairement une application javaAntoine Rey
Présente les différents types de tests automatisés, les objectifs des tests unitaires, les stratégies de mise en œuvre, les bonnes pratiques, les difficultés, ce qu'est un mock, différents outils (Unitils, Mockito, DbUnit, Spring Test) et des exemples de tests (DAO et contrôleurs Spring MVC), sans oublier le test de code legacy.
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...Cyrille Grandval
De nos jours de plus en plus d'entreprises ne jurent que par les tests unitaires. Faire du test, faire du test, faire du test ! “Une application n'est pérenne que si elle est testée et elle est testée si plus de 80% du code est couvert.”
Cela devient même un élément décisif du recruteur en entretien :
- Votre collaborateur a l'air vraiment bien mais... Il a déjà fait des tests unitaires ? Il a plus de deux ans d'expérience là dessus ?
- Juste sur deux projets, par contre il possède la bonne philosophie.
- Ah oui mais non il faut qu'il en ait fait 2 ans, c'est un minimum. On cherche des experts nous !
Problématique : "Je veux minimum 80% de couverture de code !!!" Qui n'a pas entendu cette phrase dans la bouche d'un chef de projet ou d'un lead dev trop consciencieux sans doute.
Dans certains projets un test unitaire est bon si il couvre au moins 80% de la fonctionnalité à tester, c'est tout ce qui est demandé et c'est cela qu'il faut avoir. Il est avant tout essentiel de s'interroger sur la notion de couverture de code dans un test unitaire : La couverture de code est-elle un but ? un facteur qualité ? une représentation visuelle d'un test ? Ou est-ce cet horrible fantôme qui vient hanter une application ?
Pour faire simple : un test qui couvre 100% du code à tester est-il forcement fiable ?
Conférence PHPTour Lyon 2014 - Tests unitaires - Je veux mes 80% de couverture de code !!!! http://afup.org/pages/phptourlyon2014/sessions.php#1094
Survole de l'industrialisation pour les étudiants pour http://src-media.com/ et d'anciens étudiants.
Inspirez de http://hoa-project.net/Fr/Event/Phptour14.html pour le Slide 8.
Rédigé en Mars 2013
Comment automatiser les tests ?
Les différents types de tests automatisés : TU, BDD/TDD, GUI, TDC, Test de vie …
Méthodes d’automatisation
Capture/replay
Projet de développement
Techniques d’automatisation
Data driven
Keyword driven
DSTL
Composants technique pour l’automatisation
Oracle
Bouchon
Techniques de comparaison
Reporting
Rédigé en Mars 2013
Introduction : ce que l’on va couvrir (et ne pas couvrir)
Définition : Qu’est-ce que l’automatisation des tests ?
Objectifs : Pourquoi automatiser ?
Couverture :
Qu’est-ce qu’on automatise ?
Pre et Post Process
Comment déterminer ce qu’on automatise ?
Responsabilité : Qui fait quoi?
ROI : Combien ça coute ?
Infrastructure de test
Processus d’automatisation
Conclusion
Une conférence de 2h30 (aka université) faites à Devoxx France en 2021 avec Maxime Gellé. On y fait un tour d'horizon des tests logiciels: TDD, Test unitaire vs Test d'integration, l'apport de l'archi hexagonale, Contract testing, property based testing, UI testing ... mais aussi comment "tester en production" !
Plop : un micro-générateur pour se simplifier la vie au quotidienNicolas Carlo
Plop : un micro-générateur pour se simplifier la vie au quotidien. Talk présenté le 21 décembre 2015 au meetup Node.js Paris Chapitre 3 / Conférence 2.
Industrialiser le contrat dans un projet PHPhalleck45
La notion de contrat intervient à tous les étages en PHP : du code source au besoin fonctionnel, en passant par la nécessité de travailler en équipe ou de fournir un travail clair et compréhensible. Petit tour d'horizon des outils qui vous permettront de vous assurer automatiquement que ces contrats sont bien respectés.
Conférences lors du rendez-vous AFUP Nantes du 29 octobre 2012
This course will introduce the core data structures of the Python programming language. We will move past the basics of procedural programming and explore how we can use the Python built-in data structures such as lists, dictionaries, and tuples to perform increasingly complex data analysis.
Similaire à Mutation testing, enfin une bonne mesure de la qualité des tests ?, RivieraDev le 18/05/2018 (20)
Discover some of bad practices in Scala and how to avoid them.
This talk is mainly about functionnal programming style but only with very simple concepts.
Comprendre la programmation fonctionnelle, Blend Web Mix le 02/11/2016Loïc Knuchel
Vous commencez à en entendre parler de plus en plus mais vous avez encore du mal à voir ce que c’est et à comprendre de que ça change concrètement, ce talk est fait pour vous !!!
La programmation fonctionnelle est une manière de programmer basée sur les fonctions qui permet de faire du code vraiment modulaire, améliorer la qualité et limiter les bugs. Vous ne me croyez pas ? Venez voir cette session !
Ionic2, les développeurs web à l'assaut du mobile, BDX I/O le 21/10/2016Loïc Knuchel
Le mobile est maintenant majoritaire et continue toujours de croître. Mais son écosystème technique est encore très spécifique et demande des compétences pointues. Venez découvrir Ionic, le framework d’UI qui permet aux développeurs web de faire des applications mobiles de qualité avec des technologies web.
Ionic2 - the raise of web developer, Riviera DEV le 17/06/2016Loïc Knuchel
Ionic est un framework fantastique pour faire des applications mobile et la version 2 repousse encore les limites en complétant et simplifiant encore le développement cordova !
Cette présentation passe sur l'historique du développement hybride et dresse un panorama global de l'écosystème Ionic avant de rentrer plus en détail et détailler comment coder une simple TODO Liste mobile :)
La programmation fonctionnelle est un style de programmation qui commence à se populariser. Cependant, elle garde un côté compliqué et inaccessible ce qui n'est absolument pas le cas.
Le but de cette présentation est de montrer pourquoi la programmation fonctionnelle est intéressante et surtout comment s'y mettre par petites étapes :)
Les exemples sont montrés en JavaScript / Java / Scala pour rester le plus accessible et voir les différences entre ces langages.
Programmation fonctionnelle en JavaScriptLoïc Knuchel
La programmation fonctionnelle permet de faire du code plus modulaire, avec moins de bugs et de manière plus productive !!!
Cette présentation montre comment la programmation fonctionnelle peut tenir se promesse et comment l'appliquer avec JavaScript.
Ionic Framework, L'avenir du mobile sera hybride, bdx.io le 16-10-2015Loïc Knuchel
Découvrez Ionic Framework, le meilleur outil pour les application cordova actuellement.
Il permet de développer des applications mobile hybrides très qualitatives et très simplement. A tester de toute urgence !!!
Ionic, ce n'est pas que de l'UI, meetup PhoneGap le 25-05-2015Loïc Knuchel
Ionic framework est un outil qui commence à être très commun dans le monde du développement mobile hybride. Ils permettent de créer des application mobiles hybrides de qualité en utilisant cordova et angularjs de manière très simple .
Mais Ionic, c'est aussi bien plus que ça. C'est un ensemble d'outils facilitant le développement cordova au quotidien, que ce soit avec angularjs et ionic ou pas !
Les outils Ionic c'est avant tout une CLI permettant de faciliter et d'automatiser de nombreuses tâches :
- intégration de sass
- affichage des différents rendus de l'application (iOS et Android)
- live reload, dans le navigateur mais aussi sur le device !!!!
- génération automatique des icônes et écrans de lancement
- intégration simplifiée de crosswalk
- et beaucoup d'autres subtilités utiles tous les jours...
Avec ça, ils proposent aussi tout un tas de services en mode sass :
- Ionic View qui permet de partager son app *très* facilement, sur Android comme sur iOS \o/
- Ionic Playground qui est un codepen à la Ionic
- Ionic créator, une interface drag & drop pour créer l'UI de son application Ionic
- Ionic push pour simplifier l'utilisation de notifications push
- Ionic package pour compiler son application dans le cloud (très utiles pour les applications iOS quand on a pas de mac !!!)
Beaucoup d'autres services sont en préparation et, personnellement, j'ai hâte de pouvoir les essayer ! Bref, ils sont clairement en train de construire le meilleur environnement de développement pour les applications hybrides et ainsi de leur donner une vraie légitimité !!! On en reparle dans 6 mois :D
Le développement mobile hybride sort du bois, Ch'ti JUG le 15-04-2015Loïc Knuchel
Ionic Framework révolutionne la manière de faire des applications mobile hybride avec Cordova. Il est maintenant facile de faire des applications de qualité et le développement hybride devient, grâce à Ionic, une réelle alternative.
Dans ce talk, au Ch'ti JUG, je donne mon point de vue sur le débat hybride vs natif. Pour moi, tout dépends de l'objectif de l'application et bien sûr du budget alloué.
Après une rapide présentation de Ionic et Cordova, je le compare a ses concurrents. Manifestement, aucun ne tient la comparaison...
Je me focalise ensuite sur les outils développés par drifty autours de Ionic et Cordova qui nous permettent de faciliter grandement le développement ! Ils sont, pour moi, une des forces majeures de ce framework :)
Enfin, je termine par corder une application de chat en live et la faire tester aux participants grâce à Ionic View.
Les derniers slides référencent les liens les plus utiles pour démarrer du bon pied avec Ionic et faire des applications très qualitatives :D
L'article avec la vidéo se trouve ici : http://loic.knuchel.org/blog/2015/04/18/chti-jug-le-developpement-mobile-hybride-sort-du-bois/
Devoxx est la plus grosse conférance française de développeurs. Cette année, j'ai eu la chance de pouvoir y présenter un atelier sur Ionic Framework. L'objectif de cet atelier était de faire développer aux participants une application de chat en utilisant Firebase comme backend.
Les instructions de l'atelier se trouvent ici : https://github.com/loicknuchel/devoxx-2015-ionic-chat
Introduction à Ionic Framework et son écosystème :
* Choisir la technologie de son application mobile : hybride vs natif
* Présentation de Cordova, AngularJS et Ionic Framework
* Exemples de composants Ionic avec le code associé
* Comment démarrer son application Ionic
* L'écosystème Ionic : Ionic CLI, ngCordova, Ionic Lab, Ionic Creator, Ionic View & Ionic Backend...
* Points d'attentions pour avoir une application qui fonctionne bien : cycle de vie des vues et contrôleurs, mocker ses plugin cordova, ne pas faire de traitement lourd, bien gérer le cache (localStorage)
* Liens utiles :
- http://codepen.io/ionic/public-list/ : exemples de composants
- https://github.com/loicknuchel/ionic-starter
10. Loïc Knuchel - @loicknuchel
Solution 2: couverture de code
11. Loïc Knuchel - @loicknuchel
Code exécuté par des tests != code testé
class Cart(size: Int) {
val items = mutable.ArrayBuffer[String]()
def add(item: String): Boolean = {
println(s"item add: $item")
val exists = items.contains(item)
if(items.length < size) {
items.append(item)
}
exists
}
}
it("has no assert") {
new Cart(3).add("shoes")
}
12. Loïc Knuchel - @loicknuchel
Code exécuté par des tests != code testé
it("has irrelevant assert") {
new Cart(3).add("shoes") shouldBe
false
}
class Cart(size: Int) {
val items = mutable.ArrayBuffer[String]()
def add(item: String): Boolean = {
println(s"item add: $item")
val exists = items.contains(item)
if(items.length < size) {
items.append(item)
}
exists
}
}
13. Loïc Knuchel - @loicknuchel
Code exécuté par des tests != code testé
class Cart(size: Int) {
val items = mutable.ArrayBuffer[String]()
def add(item: String): Boolean = {
println(s"item add: $item")
val exists = items.contains(item)
if(items.length < size) {
items.append(item)
}
exists
}
}
Non testé :
● les effets de bords
● la condition limite
● l’ajout dans la liste
it("asserts few things") {
val cart = new Cart(3)
cart.add("shoes")
cart.items.length shouldBe 1
}
14. Loïc Knuchel - @loicknuchel
Code exécuté par des tests != code testé
31. Loïc Knuchel - @loicknuchel
En pratique
● mutants uniquement pour le
code couvert par les tests
● lance uniquement les tests qui
couvrent le code muté
● fonctionne en mode itératif
● à mettre en priorité pour le code
critique
● activer que les mutations
intéressantes
Brute force
32. Loïc Knuchel - @loicknuchel
Exemple
/**
* Take a list of item prices and calculate the bill :
* - if total is higher than 50, apply 10% overall discount
* - if more than 5 items, apply 100% discount on cheapest
one
* - if many discount apply, use the higher one
*/
public static Double getPrice(List<Double> prices) {
Double total = sum(prices);
Double discount = 0.0;
if (total >= 50) {
discount = total * 0.1;
}
if (prices.size() >= 5) {
Double minPrice = min(prices);
if (minPrice > discount) {
discount = minPrice;
}
}
return total - discount;
}
33. Loïc Knuchel - @loicknuchel
Test 1
@Test
public void getPrice_should_be_normal_price_with_few_and_cheap_items() {
assertEquals(24, Demo.getPrice(Arrays.asList(4, 7, 1, 12), 0.001);
}
42. Loïc Knuchel - @loicknuchel
Conclusion
Impossible à
contourner
Long à
exécuter
Couplage
code ⇔
tests
Impossible à
tuer
Tester ses
tests
Meilleure
couverture
de code !
Facile à
mettre en
place
Bonjour à tous,
Bienvenu à mon talk sur le mutation testing.
Je me présente, Loïc Knuchel, je suis développeur Scala chez Criteo, j’organise les HumanTalks et j’essaie de faire du bon code…
Je m’intéresse notamment à tous ces sujets, et maintenant aussi au mutation testing
En tant que développeurs, on essaie tous de faire du bon code
Mais on a pas forcément tous la même définition du “bon code”
A minima on peut probablement s’entendre sur le fait que le code doit :
avoir un minimum de bugs
rester lisible pour les autres développeurs
ne pas demander des efforts disproportionnés pour être modifié
Et bien sûr, pour le premier point, on va écrire des tests
Plein de tests
Des tests unitaires qui vont vérifier que chaque morceau de code fait bien ce qu’on attend de lui
Des tests d’intégration qui vont s’assurer que les composants n’aient pas d’incompatibilités
Des tests de bout en bout pour vérifier que l’application est capable d’exécuter les actions voulues par l’utilisateur
Parfois des tests de charge pour prévenir les indisponibilités liées au nombre de requêtes
Voire même des chaos monkey tests pour être certain que même en cas de problème, on puisse conserver un certain service
Et tout ça dans un seul but: avoir une application qui fonctionne au maximum comme attendu
Mais comment savoir si nos tests garantissent vraiment ça ?
On va devoir tester nos tests => testception
Solution 1: le feeling
On connaît bien notre application
On a écrit plein de tests
On a peu de problèmes en prod
Bref, on se dit que ça ne doit pas être mal
Et si on est sérieux avec ça, c’est déjà un très bon point
Solution 2: la couverture de code
Qui connait ?
Ici on lance nos tests et on regarde quels sont les lignes qui ont été exécutées.
ça donne une première idée de la qualité de nos tests
clairement, avec une couverture de code faible, on comprends vite que les parties non couvertes sont à risque car pas du tout exécutées lors des tests
mais la réciproque n’est pas vraie, une bonne couverture de code ne garantit absolument pas des bon tests.
Lorsque le code est exécuté, il n’est pas forcément vérifié => assert manquant ou assert que sur une partie des résultats ou assert non pertinent
c’est pourquoi quand on écrit un test, on doit toujours le faire échouer avant de le faire réussir, mais ça, c’est possible uniquement lorsqu’on le crée, après impossible de s’en assurer
on peut aussi avoir un effet difficilement testable voire invisible du point de vue des tests => ex: logger
dans ce cas il est exécuté du coup il compte dans la couverture de code, mais pas vérifié
Lorsque le code est exécuté, il n’est pas forcément vérifié => assert manquant ou assert que sur une partie des résultats ou assert non pertinent
c’est pourquoi quand on écrit un test, on doit toujours le faire échouer avant de le faire réussir, mais ça, c’est possible uniquement lorsqu’on le crée, après impossible de s’en assurer
on peut aussi avoir un effet difficilement testable voire invisible du point de vue des tests => ex: logger
dans ce cas il est exécuté du coup il compte dans la couverture de code, mais pas vérifié
Lorsque le code est exécuté, il n’est pas forcément vérifié => assert manquant ou assert que sur une partie des résultats ou assert non pertinent
c’est pourquoi quand on écrit un test, on doit toujours le faire échouer avant de le faire réussir, mais ça, c’est possible uniquement lorsqu’on le crée, après impossible de s’en assurer
on peut aussi avoir un effet difficilement testable voire invisible du point de vue des tests => ex: logger
dans ce cas il est exécuté du coup il compte dans la couverture de code, mais pas vérifié
On peut aussi oublier de tester une valeur particulière importante => condition aux limites
Comme toute métrique, elle peut être détournée => introspection pour tout exécuter en un test
et enfin, toutes les lignes de code ne se valent pas, certaines sont beaucoup plus importantes que d’autres et on veut s’assurer que les parties importantes sont très bien testées
la couverture de code donne principalement un chiffre global pas forcément pertinent
La couverture de code, c’est bien mais loin d’être suffisant.
Heureusement, aujourd’hui je vous présente la solution ultime !!!
Ou presque…
Enfin, une meilleure solution que les précédentes en tout cas ;)
Le mutation testing !
Contrairement à ce que son nom pourrait faire penser, c’est pas une nouvelle méthode de test mais une méthode pour évaluer la qualité des tests, un peu comme la couverture de code
D’ailleurs, comme la couverture de code, c’est une technique non-intrusive pour le code de l’application
Il suffit simplement de configurer un outil, qui peut être totalement extérieur au code !
Le mutation testing peut être utilisé dans n’importe quel langage mais chaque langage a son outil spécifique.
Par exemple en Java il y a PIT
Et pour l’utiliser il suffit de l’ajouter au build et de le lancer
C’est aussi simple que ça ! (bien sûr il y a pas mal d’options si on souhaite mais la première intégration est triviale)
En scala il y a scalamu et de la même manière, il suffit de l’ajouter comme plugin et de le lancer
Et enfin, en JavaScript on a stryker
Mais on a toujours pas parlé de ce que fait le mutation testing…
Le principe est très simple
Le framework de mutation testing va créer des mutants et vérifier s’ils sont détectés pour les tests
bien sûr, tout ça est assez coûteux en terme de performances…
Il est important que les tests s’exécutent rapidement et n’aient pas une portée trop large
Et bien sûr il y a quelques optimisations possibles pour améliorer ça