Les tests doivent faire partie intégrante de tous les sujets. Il ne devrait pas avoir de tâches même technique disant « Ajouter les tests pour … ».
Leur seule visibilité est sur le board est dans la DoD.
La Définition de terminé contient
- Il y a une preuve rapide, fiable et reproductible que le code fonctionne comme il se doit.
- La structure du code est améliorée…
Mes pratiques
- Travail avec le métier pour énoncer le comportement attendu.
- Réalisation du comportement
- Branchement du code écrit précédemment pour rendre ce qui a été écrit à l’étape « 1. » automatisé.
- Dans une application avec plusieurs composants, il faut s’assurer que ces composants communiquent bien entre eux.
- Un ou deux tests qui englobent tout le système.
- Utilisation de l’ingéniosité humaine pour chercher des bugs, des failles de sécurité, … Les seuls tests manuels.
Annexe
Précision sur le Test-Driven Development (TDD)
TDD n’est pas une pratique de test, mais une discipline d’écriture du code.
- Elle permet principalement de changer le code sans peur. Car cela construit une suite de tests dont on a confiance.
- C’est une documentation parfaite pour les développeurs.
- Cela permet de réduire le temps de débug
- D’avoir une architecture de code découplé
- C’est fun
La loi de Kent Beck
- Faites d’abord fonctionner le code
- Ensuite, nettoyez-le
- Ensuite, si nécessaire, rendez-le rapide et petit.
Les mocks ou doublure de test
Ils sont seulement utilisés aux frontières d’architecture.
Le détail des pratiques de développement
1. Travail avec le métier pour énoncer le comportement attendu.
Pratiques : les 3 amigos, exemple mapping, Acceptance Tests Driven Development (ATDD), Behavior Driven Development (BDD)
Langages : Gherkin « given/when/then », un simple tableau
Type de tests : « Component tests »
Résultat : La description du comportement attendu de l’application compréhensible par le métier. Cela permet d’avoir un vocabulaire partagé.
2. Réalisation du comportement
Pratiques : Test-Driven Development (TDD) & Correction de la structure du code
Langages : Le langage de programmation du code
Type de tests : « Unit tests »
Résultat : Du code qui est facile à lire. Qui expose une interface utilisable par le « when ». Un filet de sécurité dans le domaine de définition connu. Les détails de l’implémentation sont ignorés, car les comportements sont testés à travers l’interface public du cas d’usage.
Fréquence d’exécution : Durant le développement. Au moins 2 fois / minutes.
3. Branchement du code écrit précédemment pour rendre ce qui a été écrit à l’étape « 1. » Automatiser.
Résultat : La réalisation avance du comportement attendu par le métier.
Cela peut être monté comme information d’avancement, combien de pourcentage des scénarios sont terminés.
Fréquence d’exécution : Durant le développement. Au moins 1 fois / heure
4. Dans une application avec plusieurs composants, il faut s’assurer que ces composants communiquent bien entre eux.
Pratiques : Test-Driven Development (TDD) & Correction de la structure du code
Langages : Le langage de programmation du code
Type de tests : « Integration tests »
Résultat : Un filet de sécurité qui assure la bonne communication en composant, la chorégraphie. Aucuns règle métier est testée ici. On y trouve les tests de performance.
Fréquence d’exécution : Dans l’intégration continue. Ou périodiquement.
5. Un ou deux tests qui englobent tout le système.
Type de tests : « System tests »
Résultat : Un filet de sécurité de bout en bout qui assure que les branchements sont bons depuis l’interface utilisateur à la base de données. Ici pas de mock.
Fréquence d’exécution : Au moins une fois par semaine. Si possible avant chaque déploiement en prod.
6. Utilisation de l’ingéniosité humaine pour chercher des bugs, des failles de sécurité, … Les seuls tests manuels.
Type de tests : « Exploratory »
Fréquence d’exécution : 1 ou 2 fois par an
