Ma stratégie de tests

Ma stratégie de tests

8665aad8f35b1710df79e9aef52d6daa?s=128

Alexandre Salomé

January 28, 2020
Tweet

Transcript

  1. 4.

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

    Être rassuré avant de déployer Vert ⇒ on peut mettre en production
  2. 5.

    Performance - Déployer rapidement - Déployer souvent - Détecter les

    erreurs le plus vite possible - Plus c’est tard, plus c’est cher
  3. 6.

    Qualité - Oser “aller à la masse dans le code”

    - Tests de qualité de code ⇒ bien, mais hors sujet
  4. 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
  5. 13.

    Souvent l’inverse - Tests longs à exécuter - Code difficile

    à maintenir - Développement lent et coûteux
  6. 17.
  7. 18.
  8. 19.

    Solution avec bouchons Application A Base de données Service tiers

    Service tiers Application B Internet Utilisateur
  9. 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 ?
  10. 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
  11. 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)
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 51.

    Tests d’intégration - Un environnement de pré-production - Je teste

    avec Cypress que “ça marche” pour le cas nominal - Visual testing
  19. 53.

    Résultat - Tests continus - Tests unitaires - Tests fonctionnels

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