Beaucoup d’entreprises sont aux prises avec une importante base de code patrimoniale (legacy). Elles savent qu’il faut s’y attaquer, mais elles ne savent pas par où commencer et abandonnent par découragement Pas de tests → Difficulté à réusiner → Architecture mal adaptée → Difficulté à écrire des tests → “Patch” laide → Retour à la case départ → ... → Refonte obligatoire :( Comment éviter le piège coûteux et extrêmement risqué de la refonte ? Pour briser ce cercle vicieux, il existe une forme de tests appelés “tests de caractérisation”. Voici une technique de “consolidation de dettes” techniques ! Dans cette présentation Félix-Antoine Bourbonnais et Pascal Roy d’Elapse Technologies vous présenteront pourquoi, comment, quand écrire et ne pas écrire ce type de tests. Une démonstration dynamique avec du code typique qui vous permettra de voir en action l’écriture de tests de caractérisation, puis le réusinage (refactoring).

1. &
FÉLIX-ANTOINE
BOURBONNAIS
B.ING., M.SC, PSM
Agile tour Québec 2016
Tests de caractérisation :
à l’assaut de votre
code « Legacy » patrimonial
PASCAL ROY
ING., CSM, PSM, PMP

2. Nous voulons vous introduire aux tests de
caractérisation, un concept et un outil essentiel
pour les développeurs qui travaillent dans du code
patrimonial
Pourquoi cette présentation ?

4. 4 4
Qui sommes-nous ?
Pascal Roy
Ing., PSM, CSM, PMP
Félix-Antoine Bourbonnais
B.ing., PSM, M.Sc.

5. 5
Conférenciers
Formateurs
Mentors
Tech.
ÉQUIPE
GestionTDD
Architecture
évolutive
Essais
automatisés
DDD
…
Scrum
QA Agile
Gestion de
projets
Agilité
BDD
> Nous sommes
Conseils
stratégiques
> Spécialités

6. LE CODE PATRIMONIAL

7. Selon vous…
Qu’est ce que du code
patrimonial (« Legacy Code »)?

8. • Du code écrit par d’autres
• Du code que plus personne ne veut toucher
• Du code qui n’est plus supporté par ceux qui l’ont écrit
• Du code qui pourrait être réécrit en utilisant de meilleures
pratiques de code, d’outils ou de langages
• ...
Quelques définitions possibles…

9. Du code sans tests
Michael Feathers,
Working Effectively with Legacy Code

10. C’est du code difficile à
faire évoluer.
Peu importe
son âge ou la raison.
En gros…

11. 11
La peur : le pire ennemi du
développement logiciel

12. Deux grandes approches…

13. 13
Tanné de stresser pour une
livraison, de débogger,
d’avoir peur de briser?

14. 14 14
S.v.p. donnez-moi un
nouveau projet
!@/$%!/%

15. Les tests sont essentiels pour
maintenir une vélocité!

16. Oups…

17. COMMENT S’ATTAQUER AU CODE PATRIMONIAL?

18. Le paradoxe des tests et du ré-usinage…

19. Bien outillé, vous pouvez rénover !

20. Vos options

21. Vos options

22. Vous avez 2 choix…
Une dépense
Big Bang
Risque très élevé
Pas de nouvelle valeur
Paiements accélérés
Étape par étape
Risque moindre
Produit de la valeur
Rebâtir de zéro Rénover / revitaliser

23. Pourquoi les gestionnaires ne
veulent pas vous laisser faire
votre “refactoring” ?!?

24. C’est un trou noir...!

25. S’attaquer au coût du changement en
ramenant le système dans un état stable
et en le maintenant dans cet état par la suite !
Le but de la rénovation?

26. Graduellement,
tout en produisant
de la valeur
Comment ?

27. Sélectionnez votre prochaine « Story » et
commencez vos paiements de dette!
Comment?

28. LE TEST DE CARACTÉRISATION

29. Un outil important pour vous
permettre de rénover votre
code patrimonial
Le test de caractérisation…

30. 30

31. Un test de caractérisation est une
description du comportement
actuel d’un bout de code.
- Michael Feathers
Définition : Test de caractérisation

32. Il permet de protéger le comportement existant
contre toute modification non désirée.
C’est notre briseur de peur!
Et par la suite…

33. LA STRATÉGIE DE RÉ-USINAGE UTILISANT LES TESTS DE
CARACTÉRISATION

34. 1. Identifier un point de changement
2. Trouver les points de tests (« seam »)
3. Briser les dépendances pour pouvoir tester
4. Écrire les tests de caractérisation
5. Faire le changement + ré-usiner
Les 5 grandes étapes

35. On peut toujours améliorer le code patrimonial…
Attention de focaliser sur notre but:
entourer de tests et faire le minimum

36. Une prise en charge dans une urgence:
on veut limiter les dommages
et on focalise sur l’objectif le plus pressant
(ex.: briser les dépendances, caractériser …)
Le « Legacy code », c’est comme…

37. Le changement à faire !
Quel est l’objectif ?
Qu’est-ce qui nous guide?

38. Attention de ne pas
arrêter la chaîne de
production de valeur!
Attention au Big Bang !
38

39. ÉCRITURE D’UN TEST DE CARACTÉRISATION

40. 1. Identifier et isoler un bout de code et le rendre accessible
dans un harnais de tests
2. Écrire une assertion qui ne passe pas
3. Exécuter le test et le laisser vous dire quel est le
comportement actuel
4. Changer votre assertion pour tenir compte du comportement
actuel
5. Répéter…
La mécanique d’écriture d’un test de caractérisation

41. public class SalesUtil {
double BQ = 1000.0;
double BCR = 0.20;
double OQM1 = 1.5;
double OQM2 = OQM1 * 2;
public double calculate(double tSales) {
if (tSales <= BQ) {
return tSales * BCR;
} else if (tSales <= BQ * 2) {
return (BQ) * BCR + (tSales - BQ) * BCR * OQM1;
} else {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1 +
(tSales - BQ * 2) * BCR * OQM2;
}
}
}
http://s3.amazonaws.com/giles/demons_010609/wtfm.jpg
Un exemple simple de code patrimonial?
WTF?
WTF?
WTF?

42. Étape 1: identifier un bout de code et le rendre accessible
dans un harnais de tests
public class SalesUtil {
double BQ = 1000.0;
double BCR = 0.20;
double OQM1 = 1.5;
double OQM2 = OQM1 * 2;
public double calculate(double tSales){
if (tSales <= BQ) {
return tSales * BCR;
} else if (tSales <= BQ * 2) {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1;
} else {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1 +
(tSales - BQ * 2) * BCR * OQM2;
}
}
}
@Test
public void test… {
assert(...)
}
1
?
2
? ?
1
2

43. Étape 2: écrire une assertion qui ne passe pas
public class SalesUtil {
double BQ = 1000.0;
double BCR = 0.20;
double OQM1 = 1.5;
double OQM2 = OQM1 * 2;
double calculate(double tSales) {
if (tSales <= BQ) {
return tSales * BCR;
} else if (tSales <= BQ * 2) {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1;
} else {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1+
(tSales - BQ*2)*BCR * OQM2;
}
}
}
@Test
public void testCalculate() {
assertEquals(
0.0,
SalesUtil.calculate(1000.0)
);
}
1
?
2
? ?
1
2

44. Étape 3: exécuter le test
+ trouver le comportement actuel
public class SalesUtil {
double BQ = 1000.0;
double BCR = 0.20;
double OQM1 = 1.5;
double OQM2 = OQM1 * 2;
double calculate(double tSales) {
if (tSales <= BQ) {
return tSales * BCR;
} else if (tSales <= BQ * 2) {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1;
} else {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1 +
(tSales - BQ * 2) * BCR * OQM2;
}
}
}
@Test
public void testCalculate() {
assertEquals(
0.0,
SalesUtil.calculate(1000.0)
);
}
> junit.framework.AssertionFailedError:
expected:<0.0> but was:<200.0>1
?
2
? ?
1
2

45. Étape 4: Remplacer par le comportement découvert
public class SalesUtil {
double BQ = 1000.0;
double BCR = 0.20;
double OQM1 = 1.5;
double OQM2 = OQM1 * 2;
double calculate(double tSales) {
if (tSales <= BQ) {
return tSales * BCR;
} else if (tSales <= BQ * 2) {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1;
} else {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1+
(tSales – BQ*2)*BCR * OQM2;
}
}
}
@Test
public void testCalculate2() {
assertEquals(
200.0,
SalesUtil.calculate(1000.0)
);
}
1
200.0
2
? ?
1
2

46. Étape 5: Répéter
public class SalesUtil {
double BQ = 1000.0;
double BCR = 0.20;
double OQM1 = 1.5;
double OQM2 = OQM1 * 2;
double calculate(double tSales) {
if (tSales <= BQ) {
return tSales * BCR;
} else if (tSales <= BQ * 2) {
return (BQ) * BCR +
(tSales - BQ) * BCR * OQM1;
} else {
return (BQ) * BCR +
(tSales - BQ) * BCR*OQM1+
(tSales – BQ*2) * BCR*OQM2;
}
}
}
…
@Test
public void testCalculate() {
assertEquals(
0.0,
SalesUtil.calculate(2000.0)
);
}
1
200.0
2
? ?
1
2

47. Attention aux « tant qu’à y être » !
Ciblez uniquement ce que vous voulez modifier.

49. On n’a pas le temps
de faire ça ?!?

50. Combien de temps ça
prend pour comprendre
un bout de code Legacy
avant de le modifier?
Réponse…

51. PARTICULARITÉS
D’UN TEST DE CARACTÉRISATION

52. En quoi un TC est-il différent?
Objectif
Spécification du
comportement requis
Spécification du
comportement actuel
Régulier Caractérisation

53. En quoi un TC est-il différent?
Contexte d’utilisation
Comportement connu
et nouveau code
Code patrimonial,
comportement flou ou
perdu
Régulier Caractérisation

54. En quoi un TC est-il différent?
Durée de vie
Permanent Temporaire
Régulier Caractérisation

55. Quel niveau ?
Est-ce que d’entourer mon
application avec des tests bout-
en-bout peut m’aider à
caractériser ?

56. Le nouveau code doit être testé et écrit avec les
meilleures pratiques… n’ajoutez pas encore plus de
patrimoine douteux !
Avertissement !

57. 58

58. Le défi moderne…
La maintenabilité !
59

59. 60
La pourriture du code n’est pas
une « loi naturelle »…

60. Although our first joy of programming
may have been intense, the misery of
dealing with legacy code is often
sufficient to extinguish that flame.
Michael Feathers,
Working Effectively with Legacy Code
Le code patrimonial tue la flamme!

61. Image de http://beinweb.fr/wp-content/uploads/2014/04/boite-a-outils-entrepreneurs.jpg
Le test de caractérisation…
À ajouter dans votre boîte à outils!

62. La « patrimonialite »
ça se soigne !

63. Merci .

64. 65
Merci
Notre site
elapsetech.com
Notre blogue
developpementagile.com
Nos Twitter
@fbourbonnais | @elapsetech
Nos courriels
fbourbonnais@elapsetech.com
pascalroy@elapsetech.com
Nos LinkedIn
linkedin.com/in/fbourbonnais/fr
ca.linkedin.com/in/roypa
conferences.elapsetech.com
Diapositives
Nos présentations, chez vous!