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