Améliore tes tests automatisés !
Acheter maintenant
En savoir plus
Introduction
Bienvenue !
Théorie
Pourquoi tester ?
Caractéristiques des bons tests : Qu'est-ce qui fait un bon test ?
Unitaire, Intégration, ... : Une définition parmi tant d'autres
Économie des tests : Des stratégies à géométrie variable
Nommer les tests : Ce que l'on conçoit bien s'énonce clairement
Des tests davantage lisibles et maintenables
Arrange Act Assert : Une structure de test reconnaissable au premier coup d'œil
Une assertion par test : Comprendre facilement pourquoi un test échoue
Assertions sur mesure : Faciliter la compréhension de ce qui est vérifié
Méthodes de création : Encapsuler la logique de création des objets
Attention aux structures de contrôle : Ne pas se perdre dans les tests
Pas de calcul dans les tests : Garder la logique dans le code de prod
Expected object : Vérifier l'intégralité de l'état d'un objet d'un seul coup
Convention des variables : Connaitre leur rôle à la vitesse de l'éclair
Object mother : Créer facilement les types courants
Builders : Écrire les tests comme une histoire
Data driven tests : Améliorer la documentation en supprimant la duplication
Organisation des classes de tests : Sortir du classique mapping 1-1
Mocks, Stub, Fake, Spy, Doubles ?
Différents types de doublures : S'en sortir dans les batailles de vocabulaire
Problème de mocks : Figer une implémentation à jamais
Don't mock what you don't own : Mettre de la distance avec les affaires des autres
Fake en mémoire : Remplacer une implémentation pénible
Test de contrat : Ne pas découvrir le pot aux rose en production
Stubbing du temps : Prendre le contrôle du système
Tester avec une base de données
Attention aux données partagées : Ne pas coupler les tests discrètement
Nettoyer les fixtures : Merci de laisser la base de données dans l'état où vous voudriez la trouver
Programmes
Cours
Section
Mocks, Stub, Fake, Spy, Doubles ?
Mocks, Stub, Fake, Spy, Doubles ?
Améliore tes tests automatisés !
Acheter maintenant
En savoir plus
Introduction
Bienvenue !
Théorie
Pourquoi tester ?
Caractéristiques des bons tests : Qu'est-ce qui fait un bon test ?
Unitaire, Intégration, ... : Une définition parmi tant d'autres
Économie des tests : Des stratégies à géométrie variable
Nommer les tests : Ce que l'on conçoit bien s'énonce clairement
Des tests davantage lisibles et maintenables
Arrange Act Assert : Une structure de test reconnaissable au premier coup d'œil
Une assertion par test : Comprendre facilement pourquoi un test échoue
Assertions sur mesure : Faciliter la compréhension de ce qui est vérifié
Méthodes de création : Encapsuler la logique de création des objets
Attention aux structures de contrôle : Ne pas se perdre dans les tests
Pas de calcul dans les tests : Garder la logique dans le code de prod
Expected object : Vérifier l'intégralité de l'état d'un objet d'un seul coup
Convention des variables : Connaitre leur rôle à la vitesse de l'éclair
Object mother : Créer facilement les types courants
Builders : Écrire les tests comme une histoire
Data driven tests : Améliorer la documentation en supprimant la duplication
Organisation des classes de tests : Sortir du classique mapping 1-1
Mocks, Stub, Fake, Spy, Doubles ?
Différents types de doublures : S'en sortir dans les batailles de vocabulaire
Problème de mocks : Figer une implémentation à jamais
Don't mock what you don't own : Mettre de la distance avec les affaires des autres
Fake en mémoire : Remplacer une implémentation pénible
Test de contrat : Ne pas découvrir le pot aux rose en production
Stubbing du temps : Prendre le contrôle du système
Tester avec une base de données
Attention aux données partagées : Ne pas coupler les tests discrètement
Nettoyer les fixtures : Merci de laisser la base de données dans l'état où vous voudriez la trouver
Les doublures sont une des causes principales de la fragilité des tests. Dans cette section nous verrons les pièges tendus et les principes qui permettent des les éviter.
6 Leçons
Différents types de doublures : S'en sortir dans les batailles de vocabulaire
Problème de mocks : Figer une implémentation à jamais
Don't mock what you don't own : Mettre de la distance avec les affaires des autres
Fake en mémoire : Remplacer une implémentation pénible
Test de contrat : Ne pas découvrir le pot aux rose en production
Stubbing du temps : Prendre le contrôle du système