SlideShare une entreprise Scribd logo
Julien Charpentier – Directeur R&D
Cyrille Grandval – Directeur Général
Tests Unitaires
« Je veux mes 80% de couverture de code »
24.06.2014
PHP Tour Lyon 2014
Qui sommes nous?
Cyrille Grandval
Directeur général Darkmira
Consultant sécurité
Auteur
cgrandval@darkmira.fr
@CyrilleGrandval
Julien Charpentier
Directeur R&D
Lead Dev PHP
Auteur
jcharpentier@darkmira.fr
@jcharpentier_
Darkmira
Développement PHP sécurisé
Industrialisation Sécurité Bonnes pratiques
@DarkmiraBrasil
www.darkmira.com.br
@Darkmira1
www.darkmira.fr
Historique des tests unitaires
1994 (K.Beck) : SUnit pour SmallTalk
1997 (K.Beck & E.Gamma) : JUnit pour Java
1999 (K.Beck) : XP => TDD
Multiples frameworks créés (xUnit)
Notamment pour PHP :
PHPUnit (S.Bergmann)
SimpleTest (en fin de vie)
Atoum (F.Hardy)
Tests unitaires aujourd’hui…
Préconisés par les techniques de développement logiciel dans lesquels ils sont mis à
l’honneur
• TDD (Tests Driven Development)
• BDD (Behaviour Driven Development)
• PDD (Pragmatism Driven Development)
• merci à Gabriel Pillet :)
Dans les esprits :
• Pratiqués par les développeurs et attendus par les responsables de projets
Dans la réalité :
• Pas le temps
• ROI difficilement quantifiable
• Armada de tests unitaires obsolètes, en échec mais ignorés
• Justification de non écriture systématique
• Fausses pistes de recherche de résolution de bugs
Et de plus en plus…
C2DT (Code Coverage Driven Tests)
Je veux au
minimum 80% de
couverture de
code!!!!!!
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couverture de code
Couverture de code : indicateur quantitatif ou
qualitatif ?
Extrait de wikipedia
“La couverture de code (en anglais code coverage) est une mesure utilisée en génie logiciel
pour décrire le taux de code source testé d'un programme. Ceci permet de mesurer la qualité
des tests effectués.
Car plus un programme est bien testé, moins il est soumis aux bugs.”
Différentes couvertures
Les outils pour PHP nous donne le taux de la couverture des
instructions => QUANTITATIF
• Points de tests
• Chemins d’exécution
Quantitative
• Fonctions
• Instructions
Qualitative
100% de couverture de code = application testée ?
Une invitation aux mauvaises pratiques
Que font la plupart des développeurs?
Couverture de code : un trompe l’œil ?
Je test un
comportement
Je passe à un test
d’un autre
comportement
NON
OUI
J’écris un test
Je vérifie la
couverture
>80%
…
Couverture de code : un trompe l’œil ?
class Bar {
public function drink($a, $b)
{
$x = '';
if (1 == $b) {
$x .= 'B';
} else {
$x .= 'E';
}
if (1 == $b) {
$x .= 'R';
} else {
$x .= 'E';
}
return $x;
}
}
class BarTest extends PHPUnit_Framework_TestCase
{
protected function setUp()
{
parent::setUp ();
$this->Bar = new Bar();
}
public function testBar()
{
$sDrink = $this->Bar->drink(1, 2);
$this->assertEquals('BE', $sDrink);
$sDrink = $this->Bar->drink(2, 1);
$this->assertEquals('ER', $sDrink); }
}
Représentation graphique
Couverture de code : un trompe l’œil ?
Représentation graphique
Couverture de code : un trompe l’œil ?
Couverture de code : un trompe l’œil ?
100% de couverture de code = application testée
N’assure pas que :
• Des assertions sont présentes
• Qu’elles testent les bons comportements
• Que les tests soient vraiment unitaires
• Que le test soit lisible et bien écrit
• Que les cas d’entrée soient clairement identifiés
Que le test soit un test unitaire
Couverture de code : conséquences
Une plaie pour les développeurs
• Ils ne comprennent pas l’utilité
• Ils ne comprennent pas comment écrire les tests
• Ils ont l’impression de perdre leur temps
C’est inutile et contre-productif
• Laisser-aller
• Incompréhension
• Perte de temps
• Builds trop longs
Une bombe à retardement
• Coûts de développement trop élevés
• Coûts de maintenance trop élevés
• Perte de confiance
• TU obsolètes et ignorés
• Application vulnérable
Couverture de code : conséquences
C’est un risque bien réel
C2DT : Tue la politique de tests unitaires
Outils pas assez matures pour PHP
Indicateur uniquement quantitatif
N’atteste pas de la qualité des tests unitaires
=> La vérité est ailleurs
80% !???
LE CODE DE
TEST N’EST PAS
QUE DU CODE
DE TEST !!!
La qualité à l’état naturel
• Philosophie
• Bonnes pratiques
o Conventions
o Lisibilité
o Commentaires
• Bons outils
La qualité à l’état naturel :
Intro
Qu’est ce qu’un test unitaire ?
• Un test unitaire consiste à isoler un comportement de tout facteur extérieur et de
vérifier qu’il est conforme à ce que vous attendez.
Pourquoi teste-t-on ?
• Vérifier
Quels sont les avantages ?
• Documenter
• Automatiser
Sérénité
Ne plus avoir peur de modifier le code
Comprendre un code que l’on n’a pas
écrit
Supprimer du code sans perdre de
fonctionnalité
Facilité de la
maintenance
S’assurer de la non régression
La qualité à l’état naturel :
Philosophie
Coder en pensant test…
• Coder l’application pour qu’elle soit naturellement et unitairement testable
• Veiller à garder un couplage faible
• Utiliser l’injection de dépendance
• Veiller à limiter la complexité cyclomatique
• Faire des revues de codes ou du pair programming
• Ne pas propager un code qui peut-être refactorisé
…et tester en pensant qualité de la couverture
• Rechercher le taux de couverture des chemins d’exécution le plus haut possible
• Tester en boîte blanche
o Identifier et tester toutes les entrées possibles…
o …et vérifier les sorties attendues correspondantes
• Ne pas se limiter aux cas simples
o Tester les cas nominaux…
o …mais aussi les cas en erreur et les cas limites
La qualité à l’état naturel :
Bonnes pratiques
10 règles à respecter
• Un test unitaire doit-être UNITAIRE !
• Utilisez les mocks et/ou stubs (100% des appels externes)
• Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à
comprendre
• Un test doit être rapide à exécuter
• Les tests doivent être écrits le plus tôt possible
• Un test = une assertion (ou presque)
• Testez en priorité les parties critiques de l’application
• Écrivez le code de l’application pour qu’il soit testable
• Refactorisez !
• Le nom d’un test est capital, normalisez le !
ex: testNomMethode_EtatDepart_ComportementAttendu donnera
testOpenFile_FileNoExists_ThrowException()
La qualité à l’état naturel :
Bonnes pratiques
10 règles à respecter
• Un test unitaire doit-être UNITAIRE !
• Utilisez les mocks et/ou stubs (100% des appels externes)
• Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à
comprendre
• Un test doit être rapide à exécuter
• Les tests doivent être écrits le plus tôt possible
• Un test = une assertion (ou presque)
• Testez en priorité les parties critiques de l’application
• Écrivez le code de l’application pour qu’il soit testable
• Refactorisez !
• Le nom d’un test est capital, normalisez le !
La qualité à l’état naturel :
Bonnes pratiques
10 règles à respecter
• Un test unitaire doit-être UNITAIRE !
• Utilisez les mocks et/ou stubs (100% des appels externes)
• Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à
comprendre
• Un test doit être rapide à exécuter
• Les tests doivent être écrits le plus tôt possible
• Un test = une assertion (ou presque)
• Testez en priorité les parties critiques de l’application
• Écrivez le code de l’application pour qu’il soit testable
• Refactorisez !
• Le nom d’un test est capital, normalisez le !
La qualité à l’état naturel :
Bonnes pratiques
10 règles à respecter
• Un test unitaire doit-être UNITAIRE !
• Utilisez les mocks et/ou stubs (100% des appels externes)
• Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à
comprendre
• Un test doit être rapide à exécuter
• Les tests doivent être écrits le plus tôt possible
• Un test = une assertion (ou presque)
• Testez en priorité les parties critiques de l’application
• Écrivez le code de l’application pour qu’il soit testable
• Refactorisez !
• Le nom d’un test est capital, normalisez le !
La qualité à l’état naturel :
Bonnes pratiques
10 règles à respecter
• Un test unitaire doit-être UNITAIRE !
• Utilisez les mocks et/ou stubs (100% des appels externes)
• Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à
comprendre
• Un test doit être rapide à exécuter
• Les tests doivent être écrits le plus tôt possible
• Un test = une assertion (ou presque)
• Testez en priorité les parties critiques de l’application
• Écrivez le code de l’application pour qu’il soit testable et refactorisez !
• Utiliser les design pattern (ex : AAA)
• Le nom d’un test est capital, normalisez le !
test[NomMethode][EtatDeDepart][ComportementAttendu]
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couverture de code
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couverture de code
10 pièges à éviter
• Avoir pour but la couverture de code :)
• Écrire un test illisible
• Écrire un test non isolé
o dépendant de facteurs extérieurs (temps)
o dépendant de l'environnement (système de fichiers, base de données,
webservices, ...)
o dépendant d’un autre test
• Écrire les tests quand on a le temps
• Décorréler le test et le code testé
o Ecrire un test sans comprendre le comportement testé
o Écrire un test sans refactoriser un code qui doit l’être
• Confondre test unitaire et test d’intégration
• Ne pas exécuter les TU à chaque commit / push sur le dépot
• Écrire un test par comportement testé
• Ecrire un test gérant plusieurs états
• Faire trop de tests unitaires !
La qualité à l’état naturel :
Mauvaises pratiques
10 pièges à éviter
• Avoir pour but la couverture de code :)
• Écrire un test illisible
• Écrire un test non isolé
o dépendant de facteurs extérieurs (temps)
o dépendant de l'environnement (système de fichiers, base de données,
webservices, ...)
o dépendant d’un autre test
• Écrire les tests quand on a le temps
• Décorréler le test et le code testé
o Ecrire un test sans comprendre le comportement testé
o Écrire un test sans refactoriser un code qui doit l’être
• Confondre test unitaire et test d’intégration
• Ne pas exécuter les TU à chaque commit / push sur le dépot
• Écrire un test par comportement testé
• Ecrire un test gérant plusieurs états
• Faire trop de tests unitaires !
La qualité à l’état naturel :
Mauvaises pratiques
10 pièges à éviter
• Avoir pour but la couverture de code :)
• Écrire un test illisible
• Écrire un test non isolé
o dépendant de facteurs extérieurs (temps)
o dépendant de l'environnement (système de fichiers, base de données,
webservices, ...)
o dépendant d’un autre test
• Écrire les tests quand on a le temps
• Décorréler le test et le code testé
o Ecrire un test sans comprendre le comportement testé
o Écrire un test sans refactoriser un code qui doit l’être
• Confondre test unitaire et test d’intégration
• Ne pas exécuter les TU à chaque commit / push sur le dépot
• Écrire un test par comportement testé
• Ecrire un test gérant plusieurs états
• Faire trop de tests unitaires !
La qualité à l’état naturel :
Mauvaises pratiques
10 pièges à éviter
• Avoir pour but la couverture de code :)
• Écrire un test illisible
• Écrire un test non isolé
o dépendant de facteurs extérieurs (temps)
o dépendant de l'environnement (système de fichiers, base de données,
webservices, ...)
o dépendant d’un autre test
• Écrire les tests quand on a le temps
• Décorréler le test et le code testé
o Ecrire un test sans comprendre le comportement testé
o Écrire un test sans refactoriser un code qui doit l’être
• Confondre test unitaire et test d’intégration
• Ne pas exécuter les TU à chaque commit / push sur le dépot
• Écrire un test par comportement testé
• Ecrire un test gérant plusieurs états
• Faire trop de tests unitaires !
La qualité à l’état naturel :
Mauvaises pratiques
Tester la qualité :
le Mutation Testing
Tester le test lui-même
Un peu d’histoire
• 1971 (Richard Lipton) – Concept
• 1980 (Timothy Budd) - Premier outil
• Constat : Les tests vérifient que l’application est l'implémentation correcte des
besoins. Sont-ils suffisamment qualifiés ? Repèrent-t-ils un dysfonctionnement ?
• Objectif : Créer des mutations simples du code source d’une application et
soumettre ces mutations à la suite de tests unitaires.
• Score qualitatif = nombre de mutants tués / nombre de mutants créés
Tester la qualité :
le Mutation Testing
Fonctionnement
• Le mutation-testing utilise un lot de mutations simples qu’il applique une à une sur le
code source original de l’application.
• Il crée ainsi des mutations du code original qui en modifie son comportement.
• Ce comportement étant différent, certains tests devraient logiquement le repérer et
ne plus être acceptés
• Exemples de mutations :
o modification de conditions (== par !=, == par =, && par ||, > par <, etc.)
o modification structurelles (suppression de bloc else, d’un case de switch, etc.)
o modification de valeurs (true par false, …)
Tester la qualité :
le Mutation Testing
Tester la qualité :
le Mutation Testing
Exemple 1
if ($a && $b) {
$c = 1;
} else {
$c = 0;
}
L’opérateur de
condition && va être
remplacé par ||
if ($a || $b) {
$c = 1;
} else {
$c = 0;
}
Si $a = true et $b = false, le
comportement est différent
du code original, $c sera égal
à 1 au lieu d’être à 0.
Un test unitaire va-t-il
repérer cela ?
Tester la qualité :
le Mutation Testing
Exemple 2
if ($a && $b) {
$c = 1;
} else {
$c = 0;
}
Le bloc else va être
supprimé
if ($a && $b) {
$c = 1;
}
Si $a et/ou $b sont égaux à
false, le comportement est
différent du code original, $c
ne sera pas défini au lieu d’être
égal à 0.
Un test unitaire va-t-il repérer
cela ?
Tester la qualité :
le Mutation Testing
Ce qui impose donc au test, pour tuer le mutant :
• de couvrir l’instruction mutante
• de prendre en compte l’entrée qui donne vie au mutant
• d’être capable de vérifier que la sortie mutante n’est pas attendue
et impose au code, de propager la ou les valeurs mutantes
en sortie.
Cela vérifie donc bien :
• la couverture des instructions
• la couverture des chemins d’exécution
• la couverture des points de tests
• la couverture des E/S
Tester la qualité :
le Mutation Testing
Outils pour PHP
• 2013 (Jean-François Lépine) MutaTesting
o PHP 5.3+
o Ne nécessite pas d’extension
o Indépendant du framework de tests
o Ne nécessite pas de code en plus
o Intégrable facilement dans un outil d’intégration continue (type Jenkins)
o Ne crée pas les mutants physiquement
(Source : https://github.com/Halleck45/MutaTesting/)
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couverture de code
Des questions???
Merci !

Contenu connexe

Tendances

Exposé qualité et test
Exposé qualité et test Exposé qualité et test
Exposé qualité et test
Imen Turki
 
Flex Unit Testing
Flex Unit TestingFlex Unit Testing
Flex Unit Testing
Christophe Keromen
 
Industrialiser le contrat dans un projet PHP
Industrialiser le contrat dans un projet PHPIndustrialiser le contrat dans un projet PHP
Industrialiser le contrat dans un projet PHP
halleck45
 
Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de tests
Sabrine MASTOURA
 
Bbl sur les tests
Bbl sur les testsBbl sur les tests
Bbl sur les tests
Idriss Neumann
 
Présentation Tests Fonctionnels
Présentation Tests FonctionnelsPrésentation Tests Fonctionnels
Présentation Tests Fonctionnels
DATANYWARE.com
 
Test logiciel
Test logicielTest logiciel
Test logiciel
Youness Boukouchi
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logiciel
Jean-Paul CARMONA
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
Mohamed Akrouh
 
Exposée: Processus de test logiciel
Exposée:  Processus de test logiciel Exposée:  Processus de test logiciel
Exposée: Processus de test logiciel
Esaie88
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
Geeks Anonymes
 
La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
La qualité logicielle et l'intégration continue - Cas concret du projet CytomineLa qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
Geeks Anonymes
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
Frederic Hardy
 
Formation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratifFormation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratif
kemenaran
 
Tester unitairement une application java
Tester unitairement une application javaTester unitairement une application java
Tester unitairement une application java
Antoine Rey
 
13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel
lauraty3204
 
Tester c'est douter - Linkvalue tech
Tester c'est douter - Linkvalue techTester c'est douter - Linkvalue tech
Tester c'est douter - Linkvalue tech
Marine Karam
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
cyrilgandon
 
Tests de performances
Tests de performancesTests de performances
Tests de performances
Damien Raude-Morvan
 

Tendances (20)

Exposé qualité et test
Exposé qualité et test Exposé qualité et test
Exposé qualité et test
 
Flex Unit Testing
Flex Unit TestingFlex Unit Testing
Flex Unit Testing
 
Industrialiser le contrat dans un projet PHP
Industrialiser le contrat dans un projet PHPIndustrialiser le contrat dans un projet PHP
Industrialiser le contrat dans un projet PHP
 
Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de tests
 
Bbl sur les tests
Bbl sur les testsBbl sur les tests
Bbl sur les tests
 
Présentation Tests Fonctionnels
Présentation Tests FonctionnelsPrésentation Tests Fonctionnels
Présentation Tests Fonctionnels
 
Test logiciel
Test logicielTest logiciel
Test logiciel
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logiciel
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
 
Exposée: Processus de test logiciel
Exposée:  Processus de test logiciel Exposée:  Processus de test logiciel
Exposée: Processus de test logiciel
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
 
La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
La qualité logicielle et l'intégration continue - Cas concret du projet CytomineLa qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
Formation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratifFormation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratif
 
Tester unitairement une application java
Tester unitairement une application javaTester unitairement une application java
Tester unitairement une application java
 
13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel
 
Tester c'est douter - Linkvalue tech
Tester c'est douter - Linkvalue techTester c'est douter - Linkvalue tech
Tester c'est douter - Linkvalue tech
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
 
Tests de performances
Tests de performancesTests de performances
Tests de performances
 
Et4 4 testinformel
Et4 4 testinformelEt4 4 testinformel
Et4 4 testinformel
 

En vedette

Seth Okai - Public Beta Testing - EuroSTAR 2012
Seth Okai - Public Beta Testing - EuroSTAR 2012Seth Okai - Public Beta Testing - EuroSTAR 2012
Seth Okai - Public Beta Testing - EuroSTAR 2012
TEST Huddle
 
Formation MySQL Workbench
Formation MySQL WorkbenchFormation MySQL Workbench
Formation MySQL Workbench
IsenDev
 
Création d’application facile en html via node-webkit
Création d’application facile en html via node-webkitCréation d’application facile en html via node-webkit
Création d’application facile en html via node-webkit
IsenDev
 
T P
T PT P
T P
ADB2
 
Initiation au C++
Initiation au C++Initiation au C++
Initiation au C++
IsenDev
 
Differences between Testing in Waterfall and Agile
Differences between Testing in Waterfall and AgileDifferences between Testing in Waterfall and Agile
Differences between Testing in Waterfall and Agile
Return on Intelligence
 
SGBDR - MySQL
SGBDR - MySQLSGBDR - MySQL
SGBDR - MySQL
Musatge
 
Cours Base de Données
Cours Base de DonnéesCours Base de Données
Cours Base de Données
yassine kchiri
 
Agile scrum roles
Agile scrum rolesAgile scrum roles
Agile scrum roles
David Tzemach
 
Merise+ +exercices+mcd+-+corrigés
Merise+ +exercices+mcd+-+corrigésMerise+ +exercices+mcd+-+corrigés
Merise+ +exercices+mcd+-+corrigés
Majid CHADAD
 
exercices Corrigées du merise
exercices Corrigées du  meriseexercices Corrigées du  merise
exercices Corrigées du merise
Yassine Badri
 
PARCOURS-BCPP_infos_2016-17
PARCOURS-BCPP_infos_2016-17PARCOURS-BCPP_infos_2016-17
PARCOURS-BCPP_infos_2016-17
Mehdi Felfli
 
Numeracion romana
Numeracion romanaNumeracion romana
Numeracion romana
Axel De La Fuente
 
Plan de negocios presentacion
Plan de negocios presentacionPlan de negocios presentacion
Plan de negocios presentacion
Diego Maldonado
 
Parábolas .
Parábolas .Parábolas .
Parábolas .
Quinto B BN
 
Tema 2 aguas 1
Tema 2 aguas   1Tema 2 aguas   1
Tema 2 aguas 1
JOSELUISLLORENTE
 
Juego Ural Truck Camión Militar
Juego Ural Truck Camión MilitarJuego Ural Truck Camión Militar
Juego Ural Truck Camión Militar
Jugar Con Juegos
 

En vedette (20)

Seth Okai - Public Beta Testing - EuroSTAR 2012
Seth Okai - Public Beta Testing - EuroSTAR 2012Seth Okai - Public Beta Testing - EuroSTAR 2012
Seth Okai - Public Beta Testing - EuroSTAR 2012
 
Formation MySQL Workbench
Formation MySQL WorkbenchFormation MySQL Workbench
Formation MySQL Workbench
 
Création d’application facile en html via node-webkit
Création d’application facile en html via node-webkitCréation d’application facile en html via node-webkit
Création d’application facile en html via node-webkit
 
T P
T PT P
T P
 
Initiation au C++
Initiation au C++Initiation au C++
Initiation au C++
 
Differences between Testing in Waterfall and Agile
Differences between Testing in Waterfall and AgileDifferences between Testing in Waterfall and Agile
Differences between Testing in Waterfall and Agile
 
SGBDR - MySQL
SGBDR - MySQLSGBDR - MySQL
SGBDR - MySQL
 
Cours Base de Données
Cours Base de DonnéesCours Base de Données
Cours Base de Données
 
Agile scrum roles
Agile scrum rolesAgile scrum roles
Agile scrum roles
 
Merise+ +exercices+mcd+-+corrigés
Merise+ +exercices+mcd+-+corrigésMerise+ +exercices+mcd+-+corrigés
Merise+ +exercices+mcd+-+corrigés
 
exercices Corrigées du merise
exercices Corrigées du  meriseexercices Corrigées du  merise
exercices Corrigées du merise
 
Test unitaire
Test unitaireTest unitaire
Test unitaire
 
PARCOURS-BCPP_infos_2016-17
PARCOURS-BCPP_infos_2016-17PARCOURS-BCPP_infos_2016-17
PARCOURS-BCPP_infos_2016-17
 
Numeracion romana
Numeracion romanaNumeracion romana
Numeracion romana
 
Plan de negocios presentacion
Plan de negocios presentacionPlan de negocios presentacion
Plan de negocios presentacion
 
ESS et Vaulx en Velin
ESS et Vaulx en VelinESS et Vaulx en Velin
ESS et Vaulx en Velin
 
Parábolas .
Parábolas .Parábolas .
Parábolas .
 
Tema 2 aguas 1
Tema 2 aguas   1Tema 2 aguas   1
Tema 2 aguas 1
 
Fortune Article
Fortune ArticleFortune Article
Fortune Article
 
Juego Ural Truck Camión Militar
Juego Ural Truck Camión MilitarJuego Ural Truck Camión Militar
Juego Ural Truck Camión Militar
 

Similaire à PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couverture de code

Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
Christophe Rochefolle
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
martinsson
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
French Scrum User Group
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
Thierry Gayet
 
Valider par des tests - Blend
Valider par des tests - BlendValider par des tests - Blend
Valider par des tests - Blend
Christophe Villeneuve
 
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAgile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Association Agile Nantes
 
Université du soir - TDD
Université du soir - TDDUniversité du soir - TDD
Université du soir - TDD
Jean-Baptiste Vigneron
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
Christophe Rochefolle
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
Agile Tour 2009 Québec
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
neuros
 
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Jean-Pierre Lambert
 
Human Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDDHuman Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDD
Xavier NOPRE
 
TDD avec ou sans mock
TDD avec ou sans mockTDD avec ou sans mock
TDD avec ou sans mock
Yannick Ameur
 
Top 5 des meilleures façon d'améliorer ton code
Top 5 des meilleures façon d'améliorer ton codeTop 5 des meilleures façon d'améliorer ton code
Top 5 des meilleures façon d'améliorer ton code
Eric De Carufel
 
La qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitairesLa qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitaires
Gauthier Delamarre
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logiciels
Sylvain Leroy
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Denis Voituron
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
CGI Québec Formation
 
[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)
Cellenza
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
Nicolas Fédou
 

Similaire à PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couverture de code (20)

Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
 
Valider par des tests - Blend
Valider par des tests - BlendValider par des tests - Blend
Valider par des tests - Blend
 
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAgile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
 
Université du soir - TDD
Université du soir - TDDUniversité du soir - TDD
Université du soir - TDD
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
 
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
 
Human Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDDHuman Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDD
 
TDD avec ou sans mock
TDD avec ou sans mockTDD avec ou sans mock
TDD avec ou sans mock
 
Top 5 des meilleures façon d'améliorer ton code
Top 5 des meilleures façon d'améliorer ton codeTop 5 des meilleures façon d'améliorer ton code
Top 5 des meilleures façon d'améliorer ton code
 
La qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitairesLa qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitaires
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logiciels
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
 
[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
 

Plus de Cyrille Grandval

Hackeando sua aplicaçao php na pratica
Hackeando sua aplicaçao php na pratica Hackeando sua aplicaçao php na pratica
Hackeando sua aplicaçao php na pratica
Cyrille Grandval
 
Proteja sua aplicação com o zend framework 2
Proteja sua aplicação com o zend framework 2Proteja sua aplicação com o zend framework 2
Proteja sua aplicação com o zend framework 2
Cyrille Grandval
 
Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2
Cyrille Grandval
 
Nouveautés php 7
Nouveautés php 7Nouveautés php 7
Nouveautés php 7
Cyrille Grandval
 
Quer segurar sua aplicação? Hackeie a primeiro(a)!
Quer segurar sua aplicação? Hackeie a primeiro(a)!Quer segurar sua aplicação? Hackeie a primeiro(a)!
Quer segurar sua aplicação? Hackeie a primeiro(a)!
Cyrille Grandval
 
Durcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative WebDurcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative Web
Cyrille Grandval
 

Plus de Cyrille Grandval (6)

Hackeando sua aplicaçao php na pratica
Hackeando sua aplicaçao php na pratica Hackeando sua aplicaçao php na pratica
Hackeando sua aplicaçao php na pratica
 
Proteja sua aplicação com o zend framework 2
Proteja sua aplicação com o zend framework 2Proteja sua aplicação com o zend framework 2
Proteja sua aplicação com o zend framework 2
 
Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2
 
Nouveautés php 7
Nouveautés php 7Nouveautés php 7
Nouveautés php 7
 
Quer segurar sua aplicação? Hackeie a primeiro(a)!
Quer segurar sua aplicação? Hackeie a primeiro(a)!Quer segurar sua aplicação? Hackeie a primeiro(a)!
Quer segurar sua aplicação? Hackeie a primeiro(a)!
 
Durcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative WebDurcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative Web
 

PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couverture de code

  • 1. Julien Charpentier – Directeur R&D Cyrille Grandval – Directeur Général Tests Unitaires « Je veux mes 80% de couverture de code » 24.06.2014 PHP Tour Lyon 2014
  • 2. Qui sommes nous? Cyrille Grandval Directeur général Darkmira Consultant sécurité Auteur cgrandval@darkmira.fr @CyrilleGrandval Julien Charpentier Directeur R&D Lead Dev PHP Auteur jcharpentier@darkmira.fr @jcharpentier_
  • 3. Darkmira Développement PHP sécurisé Industrialisation Sécurité Bonnes pratiques @DarkmiraBrasil www.darkmira.com.br @Darkmira1 www.darkmira.fr
  • 4. Historique des tests unitaires 1994 (K.Beck) : SUnit pour SmallTalk 1997 (K.Beck & E.Gamma) : JUnit pour Java 1999 (K.Beck) : XP => TDD Multiples frameworks créés (xUnit) Notamment pour PHP : PHPUnit (S.Bergmann) SimpleTest (en fin de vie) Atoum (F.Hardy)
  • 5. Tests unitaires aujourd’hui… Préconisés par les techniques de développement logiciel dans lesquels ils sont mis à l’honneur • TDD (Tests Driven Development) • BDD (Behaviour Driven Development) • PDD (Pragmatism Driven Development) • merci à Gabriel Pillet :) Dans les esprits : • Pratiqués par les développeurs et attendus par les responsables de projets Dans la réalité : • Pas le temps • ROI difficilement quantifiable • Armada de tests unitaires obsolètes, en échec mais ignorés • Justification de non écriture systématique • Fausses pistes de recherche de résolution de bugs
  • 6. Et de plus en plus… C2DT (Code Coverage Driven Tests) Je veux au minimum 80% de couverture de code!!!!!!
  • 8. Couverture de code : indicateur quantitatif ou qualitatif ? Extrait de wikipedia “La couverture de code (en anglais code coverage) est une mesure utilisée en génie logiciel pour décrire le taux de code source testé d'un programme. Ceci permet de mesurer la qualité des tests effectués. Car plus un programme est bien testé, moins il est soumis aux bugs.” Différentes couvertures Les outils pour PHP nous donne le taux de la couverture des instructions => QUANTITATIF • Points de tests • Chemins d’exécution Quantitative • Fonctions • Instructions Qualitative
  • 9. 100% de couverture de code = application testée ?
  • 10. Une invitation aux mauvaises pratiques Que font la plupart des développeurs? Couverture de code : un trompe l’œil ? Je test un comportement Je passe à un test d’un autre comportement NON OUI J’écris un test Je vérifie la couverture >80% …
  • 11. Couverture de code : un trompe l’œil ? class Bar { public function drink($a, $b) { $x = ''; if (1 == $b) { $x .= 'B'; } else { $x .= 'E'; } if (1 == $b) { $x .= 'R'; } else { $x .= 'E'; } return $x; } } class BarTest extends PHPUnit_Framework_TestCase { protected function setUp() { parent::setUp (); $this->Bar = new Bar(); } public function testBar() { $sDrink = $this->Bar->drink(1, 2); $this->assertEquals('BE', $sDrink); $sDrink = $this->Bar->drink(2, 1); $this->assertEquals('ER', $sDrink); } }
  • 12. Représentation graphique Couverture de code : un trompe l’œil ?
  • 13. Représentation graphique Couverture de code : un trompe l’œil ?
  • 14. Couverture de code : un trompe l’œil ? 100% de couverture de code = application testée N’assure pas que : • Des assertions sont présentes • Qu’elles testent les bons comportements • Que les tests soient vraiment unitaires • Que le test soit lisible et bien écrit • Que les cas d’entrée soient clairement identifiés Que le test soit un test unitaire
  • 15. Couverture de code : conséquences Une plaie pour les développeurs • Ils ne comprennent pas l’utilité • Ils ne comprennent pas comment écrire les tests • Ils ont l’impression de perdre leur temps C’est inutile et contre-productif • Laisser-aller • Incompréhension • Perte de temps • Builds trop longs Une bombe à retardement • Coûts de développement trop élevés • Coûts de maintenance trop élevés • Perte de confiance • TU obsolètes et ignorés • Application vulnérable
  • 16. Couverture de code : conséquences
  • 17. C’est un risque bien réel
  • 18. C2DT : Tue la politique de tests unitaires Outils pas assez matures pour PHP Indicateur uniquement quantitatif N’atteste pas de la qualité des tests unitaires => La vérité est ailleurs
  • 20. LE CODE DE TEST N’EST PAS QUE DU CODE DE TEST !!!
  • 21. La qualité à l’état naturel • Philosophie • Bonnes pratiques o Conventions o Lisibilité o Commentaires • Bons outils
  • 22. La qualité à l’état naturel : Intro Qu’est ce qu’un test unitaire ? • Un test unitaire consiste à isoler un comportement de tout facteur extérieur et de vérifier qu’il est conforme à ce que vous attendez. Pourquoi teste-t-on ? • Vérifier Quels sont les avantages ? • Documenter • Automatiser Sérénité Ne plus avoir peur de modifier le code Comprendre un code que l’on n’a pas écrit Supprimer du code sans perdre de fonctionnalité Facilité de la maintenance S’assurer de la non régression
  • 23. La qualité à l’état naturel : Philosophie Coder en pensant test… • Coder l’application pour qu’elle soit naturellement et unitairement testable • Veiller à garder un couplage faible • Utiliser l’injection de dépendance • Veiller à limiter la complexité cyclomatique • Faire des revues de codes ou du pair programming • Ne pas propager un code qui peut-être refactorisé …et tester en pensant qualité de la couverture • Rechercher le taux de couverture des chemins d’exécution le plus haut possible • Tester en boîte blanche o Identifier et tester toutes les entrées possibles… o …et vérifier les sorties attendues correspondantes • Ne pas se limiter aux cas simples o Tester les cas nominaux… o …mais aussi les cas en erreur et les cas limites
  • 24. La qualité à l’état naturel : Bonnes pratiques 10 règles à respecter • Un test unitaire doit-être UNITAIRE ! • Utilisez les mocks et/ou stubs (100% des appels externes) • Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à comprendre • Un test doit être rapide à exécuter • Les tests doivent être écrits le plus tôt possible • Un test = une assertion (ou presque) • Testez en priorité les parties critiques de l’application • Écrivez le code de l’application pour qu’il soit testable • Refactorisez ! • Le nom d’un test est capital, normalisez le ! ex: testNomMethode_EtatDepart_ComportementAttendu donnera testOpenFile_FileNoExists_ThrowException()
  • 25. La qualité à l’état naturel : Bonnes pratiques 10 règles à respecter • Un test unitaire doit-être UNITAIRE ! • Utilisez les mocks et/ou stubs (100% des appels externes) • Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à comprendre • Un test doit être rapide à exécuter • Les tests doivent être écrits le plus tôt possible • Un test = une assertion (ou presque) • Testez en priorité les parties critiques de l’application • Écrivez le code de l’application pour qu’il soit testable • Refactorisez ! • Le nom d’un test est capital, normalisez le !
  • 26. La qualité à l’état naturel : Bonnes pratiques 10 règles à respecter • Un test unitaire doit-être UNITAIRE ! • Utilisez les mocks et/ou stubs (100% des appels externes) • Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à comprendre • Un test doit être rapide à exécuter • Les tests doivent être écrits le plus tôt possible • Un test = une assertion (ou presque) • Testez en priorité les parties critiques de l’application • Écrivez le code de l’application pour qu’il soit testable • Refactorisez ! • Le nom d’un test est capital, normalisez le !
  • 27. La qualité à l’état naturel : Bonnes pratiques 10 règles à respecter • Un test unitaire doit-être UNITAIRE ! • Utilisez les mocks et/ou stubs (100% des appels externes) • Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à comprendre • Un test doit être rapide à exécuter • Les tests doivent être écrits le plus tôt possible • Un test = une assertion (ou presque) • Testez en priorité les parties critiques de l’application • Écrivez le code de l’application pour qu’il soit testable • Refactorisez ! • Le nom d’un test est capital, normalisez le !
  • 28. La qualité à l’état naturel : Bonnes pratiques 10 règles à respecter • Un test unitaire doit-être UNITAIRE ! • Utilisez les mocks et/ou stubs (100% des appels externes) • Un test est avant tout du code : il doit simple, normé, commenté, facile à lire et à comprendre • Un test doit être rapide à exécuter • Les tests doivent être écrits le plus tôt possible • Un test = une assertion (ou presque) • Testez en priorité les parties critiques de l’application • Écrivez le code de l’application pour qu’il soit testable et refactorisez ! • Utiliser les design pattern (ex : AAA) • Le nom d’un test est capital, normalisez le ! test[NomMethode][EtatDeDepart][ComportementAttendu]
  • 31. 10 pièges à éviter • Avoir pour but la couverture de code :) • Écrire un test illisible • Écrire un test non isolé o dépendant de facteurs extérieurs (temps) o dépendant de l'environnement (système de fichiers, base de données, webservices, ...) o dépendant d’un autre test • Écrire les tests quand on a le temps • Décorréler le test et le code testé o Ecrire un test sans comprendre le comportement testé o Écrire un test sans refactoriser un code qui doit l’être • Confondre test unitaire et test d’intégration • Ne pas exécuter les TU à chaque commit / push sur le dépot • Écrire un test par comportement testé • Ecrire un test gérant plusieurs états • Faire trop de tests unitaires ! La qualité à l’état naturel : Mauvaises pratiques
  • 32. 10 pièges à éviter • Avoir pour but la couverture de code :) • Écrire un test illisible • Écrire un test non isolé o dépendant de facteurs extérieurs (temps) o dépendant de l'environnement (système de fichiers, base de données, webservices, ...) o dépendant d’un autre test • Écrire les tests quand on a le temps • Décorréler le test et le code testé o Ecrire un test sans comprendre le comportement testé o Écrire un test sans refactoriser un code qui doit l’être • Confondre test unitaire et test d’intégration • Ne pas exécuter les TU à chaque commit / push sur le dépot • Écrire un test par comportement testé • Ecrire un test gérant plusieurs états • Faire trop de tests unitaires ! La qualité à l’état naturel : Mauvaises pratiques
  • 33. 10 pièges à éviter • Avoir pour but la couverture de code :) • Écrire un test illisible • Écrire un test non isolé o dépendant de facteurs extérieurs (temps) o dépendant de l'environnement (système de fichiers, base de données, webservices, ...) o dépendant d’un autre test • Écrire les tests quand on a le temps • Décorréler le test et le code testé o Ecrire un test sans comprendre le comportement testé o Écrire un test sans refactoriser un code qui doit l’être • Confondre test unitaire et test d’intégration • Ne pas exécuter les TU à chaque commit / push sur le dépot • Écrire un test par comportement testé • Ecrire un test gérant plusieurs états • Faire trop de tests unitaires ! La qualité à l’état naturel : Mauvaises pratiques
  • 34. 10 pièges à éviter • Avoir pour but la couverture de code :) • Écrire un test illisible • Écrire un test non isolé o dépendant de facteurs extérieurs (temps) o dépendant de l'environnement (système de fichiers, base de données, webservices, ...) o dépendant d’un autre test • Écrire les tests quand on a le temps • Décorréler le test et le code testé o Ecrire un test sans comprendre le comportement testé o Écrire un test sans refactoriser un code qui doit l’être • Confondre test unitaire et test d’intégration • Ne pas exécuter les TU à chaque commit / push sur le dépot • Écrire un test par comportement testé • Ecrire un test gérant plusieurs états • Faire trop de tests unitaires ! La qualité à l’état naturel : Mauvaises pratiques
  • 35. Tester la qualité : le Mutation Testing Tester le test lui-même
  • 36. Un peu d’histoire • 1971 (Richard Lipton) – Concept • 1980 (Timothy Budd) - Premier outil • Constat : Les tests vérifient que l’application est l'implémentation correcte des besoins. Sont-ils suffisamment qualifiés ? Repèrent-t-ils un dysfonctionnement ? • Objectif : Créer des mutations simples du code source d’une application et soumettre ces mutations à la suite de tests unitaires. • Score qualitatif = nombre de mutants tués / nombre de mutants créés Tester la qualité : le Mutation Testing
  • 37. Fonctionnement • Le mutation-testing utilise un lot de mutations simples qu’il applique une à une sur le code source original de l’application. • Il crée ainsi des mutations du code original qui en modifie son comportement. • Ce comportement étant différent, certains tests devraient logiquement le repérer et ne plus être acceptés • Exemples de mutations : o modification de conditions (== par !=, == par =, && par ||, > par <, etc.) o modification structurelles (suppression de bloc else, d’un case de switch, etc.) o modification de valeurs (true par false, …) Tester la qualité : le Mutation Testing
  • 38. Tester la qualité : le Mutation Testing Exemple 1 if ($a && $b) { $c = 1; } else { $c = 0; } L’opérateur de condition && va être remplacé par || if ($a || $b) { $c = 1; } else { $c = 0; } Si $a = true et $b = false, le comportement est différent du code original, $c sera égal à 1 au lieu d’être à 0. Un test unitaire va-t-il repérer cela ?
  • 39. Tester la qualité : le Mutation Testing Exemple 2 if ($a && $b) { $c = 1; } else { $c = 0; } Le bloc else va être supprimé if ($a && $b) { $c = 1; } Si $a et/ou $b sont égaux à false, le comportement est différent du code original, $c ne sera pas défini au lieu d’être égal à 0. Un test unitaire va-t-il repérer cela ?
  • 40. Tester la qualité : le Mutation Testing Ce qui impose donc au test, pour tuer le mutant : • de couvrir l’instruction mutante • de prendre en compte l’entrée qui donne vie au mutant • d’être capable de vérifier que la sortie mutante n’est pas attendue et impose au code, de propager la ou les valeurs mutantes en sortie. Cela vérifie donc bien : • la couverture des instructions • la couverture des chemins d’exécution • la couverture des points de tests • la couverture des E/S
  • 41. Tester la qualité : le Mutation Testing Outils pour PHP • 2013 (Jean-François Lépine) MutaTesting o PHP 5.3+ o Ne nécessite pas d’extension o Indépendant du framework de tests o Ne nécessite pas de code en plus o Intégrable facilement dans un outil d’intégration continue (type Jenkins) o Ne crée pas les mutants physiquement (Source : https://github.com/Halleck45/MutaTesting/)

Notes de l'éditeur

  1. Les conséquences de penser test unitaires purement en code coverage c’est une plaie pour les développeurs, contre-productif et une bombe à retardement
  2. Roue de Deming et l’amélioration continue utilisée notamment pour la qualité des entreprises privées japonaises 4 actions, Prévoir, Faire, Vérifier, Réagir et ainsi de suite avec une cale d’expérience qui empêche de ne pas avancer