Aller au contenu

Coder l’esprit libre avec les
tests automatisés

A quoi servent les tests automatisés ?

Les projets informatiques peuvent évoluer facilement : il est plus courant de mettre à jour un logiciel que de remplacer un pan de mur d’un immeuble. Or chaque changement peut amener une régression, un bug.

C’est là que réside l’intérêt des tests automatisés : ces tests sont créés en même temps que le logiciel et vont être exécutés à chaque modification, pour s’assurer que tout fonctionne comme prévu.

Ils deviennent le filet de sécurité (on parle souvent de harnais de test) qui évite les accidents lors de modifications de l'application.

Quels types de tests automatisés chez Troopers ?

  • Tests statiques

    Analyse froide du code source produit

    Ces tests automatisés nous permettent de détecter la qualité de code produit, le respect des bonnes pratiques, d’identifier les cas de bug probables, ou de contrôler la sécurité des librairies utilisées.

  • Tests unitaires

    Les fonctions spécifiques, en isolation

    Nous concentrons les tests unitaires sur le code qui représente la logique métier de nos clients : calculateurs, aide à la décision…

  • Tests comportementaux

    Simuler des interactions utilisateurs

    Nous utilisons des outils de test fonctionnel comme Behat et Cypress pour simuler la navigation d’un utilisateur. Cela nous assure que le site se comporte comme prévu dans les cas normaux comme dans les cas limites : erreurs de formulaire, droits d’accès insuffisants…

Combien ça coûte ?

Nous incluons systématiquement le coût de mise en place des tests dans nos estimations, car nous sommes convaincus que non, il n’y a pas d’économie sur les tests.

Très vite, un test automatique qui est exécuté systématiquement va nous faire gagner du temps et éviter qu’un bug non détecté n’arrive jusqu’en production.

Jusqu’où mener les tests ?

Il n’est pas possible de tout tester, cela devient même contre-productif passé un certain point. Nous tâchons d’être réalistes : le bon sens et l’expérience nous servent de guides.

  • A tester

  • La logique métier : spécifique et souvent critique pour nos clients

  • Quelques cas “où tout va bien” : créer un compte sur un site avec toutes les bonnes informations.

  • Les erreurs fréquentes des utilisateurs : le mot de passe doit contenir au moins 16 caractères !

  • Les fonctionnalités qui ont déjà été victimes de bugs détectés tardivement

  • Ne pas tester

  • Les fonctions des logiciels libres ou open source : elles sont déjà testées !

  • L’ensemble des cas possibles : un mot de passe de 1 caractère, un autre de 2 caractères…

  • Les fonctions annexes peu critiques : elles seront simplement “vues” par les autres tests

Le point de vue des experts

Plus question de développer dans un environnement qui ne met pas en avant les tests automatisés ! La prochaine étape serait d’ouvrir la rédaction des tests fonctionnels à nos clients. Avec Gherkin, c’est possible mais difficilement imaginable en dehors d’une session de travail en binôme.

Julien Dubuisson Duplessis

Développeur back

Les tests sont devenus un outil central dans le développement logiciel. Nous pratiquons régulièrement le TDD (Test Driven Development), qui nous permet en plus de rédiger systématiquement des tests, d’accélérer et de gagner en qualité sur le code que nous produisons.

Paul Andrieux

Développeur back

Ouvre une nouvelle fenêtre