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
Exercice : couvrir du code existant
Les bonnes pratiques pour couvrir 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é mais aussi pour 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
- Relancer le test avec la couverture du code activée
- Utiliser la couverture du code pour déduire le prochain test à écrire
Commencez en passant des arguments simples. Par exemple : null, 0, string vide, etc. Puis, au fur et à mesure, augmentez la complexité de vos arguments. Généralement, cela conduit à couvrir d’abord les branches les moins indentées du code.
Exercice
package boissons;
public class ReglesBoissons {
public String boit(Integer age) throws AgeNotProvidedException {
if (age != null) {
if (age < 6) {
return "boit sirop";
} else {
if (age < 18) {
return "boit soda";
} else {
if (age < 40) {
return "boit bière";
} else {
return "boit whiskey";
}
}
}
} else {
throw new AgeNotProvidedException("Age cannot be null");
}
}
👉 Voyez si vous vous rappelez de tout en essayant par vous-même de couvrir la classe ReglesBoisson, que vous trouverez dans le projet.
Si besoin, relisez les instructions dans la section précédente. Attention cette classe ReglesBoisson se trouve dans un projet maven fromscratch à la racine des sources dans gitlab. Pour information il y a plusieurs projets maven à la racine.
👉 Que reste-t-il à faire lorsque le code est couvert à 100 % ?
