Ma stratégie de tests

Transcript

1. Ma stratégie de tests Alexandre Salomé - 2020
2. Introduction
3. Motivations
4. Sécurité - Ne pas mettre en péril le projet - Être rassuré avant de déployer Vert ⇒ on peut mettre en production
5. Performance - Déployer rapidement - Déployer souvent - Détecter les erreurs le plus vite possible - Plus c’est tard, plus c’est cher
6. Qualité - Oser “aller à la masse dans le code” - Tests de qualité de code ⇒ bien, mais hors sujet
7. Les types de tests
8. Tests unitaires Tester un fragment de code isolé de tout contexte.
9. Tests fonctionnels Vérifier le bon fonctionnement de l’application dans ses cas nominaux.
10. Tests d’intégration Vérifier la bonne articulation des applications une fois intégrées.
11. Tests manuels Tester ce qui n’est pas (encore?) automatisé
12. En résumé - Tests manuels : si on a pas trouvé mieux - Tests d’intégration : s’assurer que les applications communiquent bien - Tests fonctionnels : s’assurer du fonctionnement de l’application - Tests unitaires : garantir l’exhaustivité des cas fonctionnels, unitairement
13. Souvent l’inverse - Tests longs à exécuter - Code difficile à maintenir - Développement lent et coûteux
14. Les dépendances
15. Solution simple Application A Base de données Internet Utilisateur
16. Solution simple Application A Base de données Internet Utilisateur
17. Solution complexe Application A Base de données Service tiers Service tiers Application B Internet Utilisateur
18. Solution complexe Application A Base de données Service tiers Service tiers Application B Internet Utilisateur
19. Solution avec bouchons Application A Base de données Service tiers Service tiers Application B Internet Utilisateur
20. Facteur à prendre en compte : coût / bénéfice / risque Intégrée et maîtrisée : base de données, moteur de recherche, cache - Pas recommandé de bouchonner Si externe - Bouchonnée pour les tests fonctionnels - Supprimer la dépendance (tester dans l’avion) - Permet de tester les cas où le service est KO Faut-il bouchonner ?
21. Le mythe “iso-production”
22. Les tests unitaires
23. Check-list pour des TU réussis - Teste une pièce isolée du logiciel - Un code simple qui teste un code simple - WebTestCase n’est pas un test unitaire - Service assez linéaire, que des mocks - 30 lignes de préparation pour 1 test
24. Code que je ne teste pas unitairement
25. Les tests fonctionnels
26. Mon outil fétiche : Behat
27. Données de production ⇒ problèmes assurés (anonymisation, maintenance) Fixtures ⇒ meilleure idée Fixtures et reset entre chaque test ⇒ début des ennuis (10sx100t = 16m) Données en pré-requis ⇒ mon état actuel - Le test est auto-suffisant, peut se lancer à tout moment - Permet de détecter d’autres problèmes (parce que des données “traînent”) Les données de test (aka fixtures)
28. Des tests fonctionnels le plus simple possible
29. Les tests d’intégration
30. Tests d’intégration ⇒ métier
31. Tests de performance
32. Tests d’intégration ⇒ charge Vérifier, une fois déployé, que la performance est correcte
33. Expériences “atypiques”
34. Tester l’envoi de mails https://github.com/alexandresalome/mailcatcher
35. Tester Ansible
36. Librairie WebDriver - Extension Behat similaire à Mink - Quelques Bonus - Retry - Selecteurs faciles - Capture d’écran en cas d’erreur ⇒ JournalExtension - Abandonné car mieux depuis ⇒ Cypress
37. Behat Launcher
38. Cas pratique
39. Notre cas pratique Un formulaire en ligne pour savoir si on est un bon testeur via nos dépôts Github Formule : pour chaque dépôt, une note sur 10 : - Si fichier .travis.yml présent ⇒ 2 points - Ratio fichiers de test / fichiers dans le dépôt ⇒ 8 points
40. Expérience utilisateur - Formulaire Web pour mettre son identifiant github - Redirection vers une page d’attente - En arrière plan, un traitement va analyser le Github et envoyer le résultat - Affichage de la page de résultat
41. Le code framework - 1 table “request” avec UUID + username + note - 3 contrôleurs - App\Controller\RequestController - App\Controller\RunningController - App\Controller\ResultController - 1 commande “request-analyze” pour traiter les demandes
42. Le code métier - GithubAnalyzer - RepositoryFetcher(= interface) - GithubRepositoryFetcher - StaticRepositoryFetcher
43. Le code métier
44. Le code métier
45. Le code métier
46. Le code métier
47. Tests unitaires - GithubAnalyzerTest, via le StaticRepositoryFetcher - Aucun dépôt - 1 seul dépôt sans .travis.yml - .travis.yml présent mais pas de tests - 200 tests, 1 classe - 1 test, 200 classes - BONUS - GithubRepositoryFetcher, via des mocks - Cas utilisateur existant / non existant - Cas erreur réseau / erreur 500 - Cas nominal
48. Tests fonctionnels 2 solutions possibles : - StaticRepositoryFetcher déclaré pour l’environnement de test - GithubRepositoryFetcher avec des bouchons Wiremock + dépôts Git Ma préférence ⇒ StaticRepositoryFetcher, car plus simple
49. Tests fonctionnels
50. Tests fonctionnels
51. Tests d’intégration - Un environnement de pré-production - Je teste avec Cypress que “ça marche” pour le cas nominal - Visual testing
52. Tests manuels - Pour l’instant, aucun
53. Résultat - Tests continus - Tests unitaires - Tests fonctionnels - Déploiement continu - Pré-production - Tests d’intégration - Production - Tests d’intégration
54. Mes conseils
55. Le premier test - Écrivez un premier test - Ce que vous faites à la main plusieurs fois, automatisez le Des tests isolés - N’importe quel test dans n’importe quel ordre ⇒ parallélisation - Ne pas tester ses dépendances (Doctrine, Postgres). Faites confiance
56. 4 couches, 4 rôles - Les tests unitaires pour tester tous les cas particuliers (OK/KO1/KO2/KO...) - Les tests fonctionnels pour tester les cas nominaux (OK/KO) - Les tests d’intégration pour tester que ça communique (OK) - Les tests manuels en dernier recours
57. Ne négociez pas les tests
58. Automatisez ce que vous voulez garantir “Pas de tests, pas de garantie”
59. Et voilà ! Remerciements La coopérative des Tilleuls, bravo les bureaux et merci l’accueil Cécile Hamerel, meilleure organisatrice jamais Et à vous bien sûr (coeur avec les doigts) Contenu de la présentation - Icônes de Freepik de Flaticon - Code rendu avec carbon.now.sh