Tweet
Tweet

Slide 1

Slide 1 text

Ma stratégie de tests Alexandre Salomé - 2020

Slide 2

Slide 2 text

Introduction

Slide 3

Slide 3 text

Motivations

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Les types de tests

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Les dépendances

Slide 15

Slide 15 text

Solution simple Application A Base de données Internet Utilisateur

Slide 16

Slide 16 text

Solution simple Application A Base de données Internet Utilisateur

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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 ?

Slide 21

Slide 21 text

Le mythe “iso-production”

Slide 22

Slide 22 text

Les tests unitaires

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Code que je ne teste pas unitairement

Slide 25

Slide 25 text

Les tests fonctionnels

Slide 26

Slide 26 text

Mon outil fétiche : Behat

Slide 27

Slide 27 text

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)

Slide 28

Slide 28 text

Des tests fonctionnels le plus simple possible

Slide 29

Slide 29 text

Les tests d’intégration

Slide 30

Slide 30 text

Tests d’intégration ⇒ métier

Slide 31

Slide 31 text

Tests de performance

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Expériences “atypiques”

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Tester Ansible

Slide 36

Slide 36 text

Librairie WebDriver - Extension Behat similaire à Mink - Quelques Bonus - Retry - Selecteurs faciles - Capture d’écran en cas d’erreur ⇒ JournalExtension - Abandonné car mieux depuis ⇒ Cypress

Slide 37

Slide 37 text

Behat Launcher

Slide 38

Slide 38 text

Cas pratique

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Le code métier

Slide 44

Slide 44 text

Le code métier

Slide 45

Slide 45 text

Le code métier

Slide 46

Slide 46 text

Le code métier

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Tests fonctionnels

Slide 50

Slide 50 text

Tests fonctionnels

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Tests manuels - Pour l’instant, aucun

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

Mes conseils

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Ne négociez pas les tests

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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