Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Ma stratégie de tests

Ma stratégie de tests

Alexandre Salomé

January 28, 2020
Tweet

More Decks by Alexandre Salomé

Other Decks in Programming

Transcript

  1. Sécurité - Ne pas mettre en péril le projet -

    Être rassuré avant de déployer Vert ⇒ on peut mettre en production
  2. Performance - Déployer rapidement - Déployer souvent - Détecter les

    erreurs le plus vite possible - Plus c’est tard, plus c’est cher
  3. Qualité - Oser “aller à la masse dans le code”

    - Tests de qualité de code ⇒ bien, mais hors sujet
  4. 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
  5. Souvent l’inverse - Tests longs à exécuter - Code difficile

    à maintenir - Développement lent et coûteux
  6. Solution avec bouchons Application A Base de données Service tiers

    Service tiers Application B Internet Utilisateur
  7. 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 ?
  8. 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
  9. 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)
  10. Librairie WebDriver - Extension Behat similaire à Mink - Quelques

    Bonus - Retry - Selecteurs faciles - Capture d’écran en cas d’erreur ⇒ JournalExtension - Abandonné car mieux depuis ⇒ Cypress
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. Tests d’intégration - Un environnement de pré-production - Je teste

    avec Cypress que “ça marche” pour le cas nominal - Visual testing
  17. Résultat - Tests continus - Tests unitaires - Tests fonctionnels

    - Déploiement continu - Pré-production - Tests d’intégration - Production - Tests d’intégration
  18. 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
  19. 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
  20. 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