Ma stratégie de tests

Ma stratégie de tests

8665aad8f35b1710df79e9aef52d6daa?s=128

Alexandre Salomé

January 28, 2020
Tweet

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