Clean Code
Extrait de la formation en ligne
PROGRAMME
(formule payante)
- Tester c’est douter, la qualité coûte cher
- 🔒 Live #1 : faisons connaissance
- D’où vient la dette technique
- 🔒 Configurer son environnement pour les tests
- La couverture du code
- Exercice ouvrir du code existant
- 🔒 L’obsession des primitives
- 🔒 Exercice : refactoring protégé par les tests
- Le cycle TDD
- 🔒 Exercice : un premier bout de code en TDD
- 🔒 Comment gagner du temps grâce à la qualité ?
- 🔒 Les indicateurs pour suivre ses progrès
- 🔒 Live #2
- 🔒 Protéger un code existant avec des tests
- 🔒 S’assurer de la couverture du code
- 🔒 Tester c’est documenter
- 🔒 Refactorer pour préparer une nouvelle fonctionnalité
- 🔒 Introduire la nouvelle fonctionnalité en TDD
- 🔒 Les bases du pair-programming
- 🔒 Live #3
- 🔒 Les bases des Stubs (bouchons), s’isoler des dépendances non testables
- 🔒 Les bases de Spies (espions), tester des méthodes
- 🔒 Et les Mocks (simulacres) dans tout ça ?
- 🔒 Stratégie #1 : Éliminer les Stubs
Stratégie #2 : - 🔒 Introduire une couture (Seam)
- 🔒 Et si vous n’aimez pas les Stubs et les Spies ?
- 🔒 Éviter les bugs de spécifications, travailler avec des exemples
- 🔒 Éliminer les exceptions
- 🔒 Dé-duplicaquer le code (et les tests)
- 🔒 Réduire le besoin de mise à jour des tests
- 🔒 Séparer le code testable du code non testable
- 🔒 Tester le code non testable (tests d’intégration ciblés)
- 🔒 Organiser un coding dojo avec son équipe
- 🔒 Concevoir sa stratégie de tests avec la pyramide des tests
- 🔒 Parler de la dette technique à son sponsor
- 🔒 Gérer la dette technique dans son backlog produit
- 🔒 Live #5
- 🔒 Bibliographie
- 🔒 Rappels des concepts objet
- 🔒 Maîtriser son IDE
- 🔒 Intégration continue
- 🔒 Déploiement continu
- 🔒 BDD (Behaviour Driven Development) pour faire du TDD
La couverture du code
Écrire des tests sur du code existant
Avant de modifier du code existant, il peut être utile de figer son comportement actuel à la fois afin de le refactorer avant d’introduire une nouvelle fonctionnalité et à la fois de ne pas introduire un bug lors de la nouvelle fonctionnalité.
Couvrir du code existant suit un certain rythme dont vous trouverez les étapes ci-dessous :
- Écrire le test le plus simple possible, faire une assertion sciemment fausse!
- Voir le test échouer, pour la bonne raison !
- Copier le “actual” du test – le comportement actuel – et le coller dans l’assertion. Oui le code actuel fonctionne de cette manière et c’est le comportement actuel que nous voulons garantir.
- Relancer le test, le voir passer.
Commencez en passant des arguments simples. Par exemple : null, 0, string vide, etc. Puis, au fur et au mesure, augmentez la complexité de vos arguments. Généralement cela conduit à couvrir d’abord les branches les moins indentées du code.
La couverture des tests
Pour savoir quel est le prochain test à écrire il est pratique d’utiliser les outils de couverture de code. Dès lors qu’un test est écrit et au vert :
- Relancer le test avec la couverture du code activée.
- Utiliser la couverture du code pour déduire le prochain test à écrire.
Ne vous fiez pas trop au pourcentage
Une couverture du code à 100% n’est pas une garantie nécessaire pour attaquer un refactoring important du code. En effet, une branche peut être couverte sans que le ou les tests qui le couvrent nous assurent la non régression. Imaginez par exemple un test sans assertion.
Dans cette vidéo, nous voyons que nous couvrons tout le code mais que nous pouvons changer les conditions dans les ifs sans qu’aucun test ne casse. Nos tests ne sont pas suffisants.
Un autre cas de manque de couverture, alors que techniquement c’est à 100%, se présente lorsque nous ne testons que certains champs d’un objet retourné par une fonction. Encore un autre exemple : lorsque nous ne testons pas qu’un objet tierce ait été appelé avec les bons paramètres.
Nous devons avoir des assertions pour tout ce que nous ne voulons pas casser avant de refactorer jusqu’au bout.
Pour y arriver, il y a une technique qui s’appelle mutation testing. Cela consiste à introduire des bugs dans le code, de lancer les tests et s’assurer qu’au moins un test casse.
