Ma stratégie de tests

Transcript

1. Ma stratégie de tests
   Alexandre Salomé - 2020
   

   View Slide

2. Introduction
   

   View Slide

3. Motivations
   

   View Slide

4. Sécurité
   - Ne pas mettre en péril le projet
   - Être rassuré avant de déployer
   Vert ⇒ on peut mettre en production
   

   View Slide

5. Performance
   - Déployer rapidement
   - Déployer souvent
   - Détecter les erreurs le plus vite possible
   - Plus c’est tard, plus c’est cher
   

   View Slide

6. Qualité
   - Oser “aller à la masse dans le code”
   - Tests de qualité de code ⇒ bien, mais hors sujet
   

   View Slide

7. Les types de tests
   

   View Slide

8. Tests unitaires
   Tester un fragment de code isolé de tout contexte.
   

   View Slide

9. Tests fonctionnels
   Vérifier le bon fonctionnement de l’application dans ses cas nominaux.
   

   View Slide

10. Tests d’intégration
    Vérifier la bonne articulation des applications une fois intégrées.
    

    View Slide

11. Tests manuels
    Tester ce qui n’est pas (encore?) automatisé
    

    View Slide

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
    

    View Slide

13. Souvent l’inverse
    - Tests longs à exécuter
    - Code difficile à maintenir
    - Développement lent et coûteux
    

    View Slide

14. Les dépendances
    

    View Slide

15. Solution simple
    Application A
    Base de données
    Internet
    Utilisateur
    

    View Slide

16. Solution simple
    Application A
    Base de données
    Internet
    Utilisateur
    

    View Slide

17. Solution complexe
    Application A
    Base de données
    Service tiers
    Service tiers
    Application B
    Internet
    Utilisateur
    

    View Slide

18. Solution complexe
    Application A
    Base de données
    Service tiers
    Service tiers
    Application B
    Internet
    Utilisateur
    

    View Slide

19. Solution avec bouchons
    Application A
    Base de données
    Service tiers
    Service tiers
    Application B
    Internet
    Utilisateur
    

    View Slide

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 ?
    

    View Slide

21. Le mythe “iso-production”
    

    View Slide

22. Les tests unitaires
    

    View Slide

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
    

    View Slide

24. Code que je ne teste pas unitairement
    

    View Slide

25. Les tests fonctionnels
    

    View Slide

26. Mon outil fétiche : Behat
    

    View Slide

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)
    

    View Slide

28. Des tests fonctionnels le plus simple possible
    

    View Slide

29. Les tests d’intégration
    

    View Slide

30. Tests d’intégration ⇒ métier
    

    View Slide

31. Tests de performance
    

    View Slide

32. Tests d’intégration ⇒ charge
    Vérifier, une fois déployé, que la performance est correcte
    

    View Slide

33. Expériences “atypiques”
    

    View Slide

34. Tester l’envoi de mails
    https://github.com/alexandresalome/mailcatcher
    

    View Slide

35. Tester Ansible
    

    View Slide

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
    

    View Slide

37. Behat Launcher
    

    View Slide

38. Cas pratique
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

42. Le code métier
    - GithubAnalyzer
    - RepositoryFetcher(= interface)
    - GithubRepositoryFetcher
    - StaticRepositoryFetcher
    

    View Slide

43. Le code métier
    

    View Slide

44. Le code métier
    

    View Slide

45. Le code métier
    

    View Slide

46. Le code métier
    

    View Slide

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
    

    View Slide

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
    

    View Slide

49. Tests fonctionnels
    

    View Slide

50. Tests fonctionnels
    

    View Slide

51. Tests d’intégration
    - Un environnement de pré-production
    - Je teste avec Cypress que “ça marche” pour le cas nominal
    - Visual testing
    

    View Slide

52. Tests manuels
    - Pour l’instant, aucun
    

    View Slide

53. Résultat
    - Tests continus
    - Tests unitaires
    - Tests fonctionnels
    - Déploiement continu
    - Pré-production
    - Tests d’intégration
    - Production
    - Tests d’intégration
    

    View Slide

54. Mes conseils
    

    View Slide

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
    

    View Slide

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
    

    View Slide

57. Ne négociez pas les tests
    

    View Slide

58. Automatisez ce que vous voulez garantir
    “Pas de tests,
    pas de garantie”
    

    View Slide

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
    

    View Slide