Soyons honnête : nous aimerions tous tester nos plateformes, nos codes, mais personne ne le fait vraiment bien. Heureusement, ce n’est pas une fatalité, et il n’est jamais trop tard pour tester ! La vraie question est : comment tester ? Derrière toute stratégie de tests efficace, il y a une connaissance de tous les types de tests disponibles, de leurs coûts et de leurs utilités. Tout au long de cette journée, nous allons vous détailler les différents types de tests, du test unitaire au test de charge, afin que vous puissiez évaluer la pertinence de chacun dans votre propre contexte.

1. Techniques avancées de refactoring
Parce qu’on a tous un jour rêvé de devenir un Ninja
Agile Testing Day

2. @NicholasSuter
Consultant / manager / couteau suisse
Visual Studio and Development
Technologies .NET / C#
http://www.nicholassuter.com/
http://blog.cellenza.com/author/nsuter/

3. Pourquoi parler de refactoring aujourd’hui ?
Tester une nouvelle
application conçue pour
être testable, c’est facile.
Oui, mais… et l’existant ?

4. 1. Description du champ de bataille
2. Détecter et identifier l’ennemi
3. Techniques de combat et armement

5. Legacy
Le code des autres
Du code non-
supporté
Tout code déjà
écrit
Code without
automated tests
Michael Feathers in Working Effectively with Legacy Code

6. Styles d’architecture
1990 2000 2010

7. Styles d’architecture
Et parfois…

8. Refactoring

9. Refactoring
Le refactoring consiste à améliorer du code
existant sans modifier son comportement.

10. SOLID
Single responsibility
Open for extension, closed for modification
Liskov substitution
Interface segregation
Dependency inversion

11. Clean Code
Le code propre est :
Simple Expressif Lisible Organisé Testé

12. Clean Code

13. Bonnes pratiques
KISS YAGNI DRY
Keep it simple and stupid You aren’t going to need it Don’t repeat yourself

14. 1. Description du champ de bataille
2. Détecter et identifier l’ennemi
3. Techniques de combat et armement

15. Cartographier

16. Cartographier

17. Mesurer la qualité du code
Parfois, l’estimation au doigt
mouillé n’est pas suffisante.

18. Mesurer la qualité du code
Nombre de
lignes de code
Complexité
cyclomatique
Taux de
couverture
Volume de
commentaires
Ratio de
méthodes
trop longues
Nombre de
classes par
librairie
Nombre de
méthodes par
classe
Indice de
spécialisation
Indice
d’instabilité
Coefficient
d’abstraction
Distance de
bonne
conception
Taux de
duplication

19. Mesurer la qualité du code

20. Code smells
Les code smells sont un indicateur de problèmes de
design applicatif.
« Les code smells sont des symptômes de problèmes
plus profonds. »
Martin Fowler

21. Code smells
Les Gros
Les méthodes
trop longues
Les classes
trop grosses
La liste de
paramètres
interminable
L’abus de
primitives
La
dissémination
de données

22. Code smells
Les Dispensables
Les
commentaires
Le code mort
Le code
dupliqué
Les classes
fainéantes
La généricité
spéculative

23. Code smells
Les Abus de la Programmation Orientée Objet
Les switchs et
if/else if/else
if/else
Les champs
facultatifs
L’héritage
abusif
Le manque
d’homogénéité

24. Code smells
Les Problèmes de Couplage
Feature Envy
Intimité
inappropriée
Enchaînements
excessifs
Man in the
middle

25. 1. Description du champ de bataille
2. Détecter et identifier l’ennemi
3. Techniques de combat et armement

26. L’Arme Fatale

27. Cleaning the deck
• Renommage
• Déplacements de
blocs de code

28. Refactorings
Amélioration de la lisibilité et de la localisation du code
Rename
Move to…
• Move up
• Move down
Extract
variable
Inline variable

29. Refactorings
Découpage et organisation du code
Découpage de
grosses interfaces
en petites
interfaces ciblées
Extraction de
méthode
Extraction de
classe

30. Refactorings
Abstraction
Encapsuler un
champ
Remplacer les
conditionnelles par
du polymorphisme
Remplacer un code
de type par un
pattern State ou
Strategy
Extraction
d’interface
Ajout de
paramètre

31. Fakes, mocks et stubs
Mock : permet également de
compter le nombre d'appels aux
méthodes
Mock
Stub
Fake
Stub : on lui injecte du
comportement dynamiquement
Fake : faux objet généré
manuellement simulant un objet réel
à l'aide de valeurs codées en dur.
IContract

32. Golden Master

33. Golden Master
Golden Master
Input Output
Unit tests
When [Input], then
[Output]

34. Demo
Kata !

35. Bien armer ses soldats
Roslyn Code Cracker

36. Bibliographie

37. Conclusion
• Ne négligez pas la théorie
• Maîtrisez les outils
• Ne soyez pas effrayés par la difficulté
• Gardez le bon état d’esprit
Des questions