Les tests

En développement logiciel, le débogage fait partie d’un processus appelé les tests et implique d’identifier correctement les erreurs de code.

Par contre, évité les erreurs techniques n’est pas assez, tester une application signifie bien plus que cela!

Une organisation internationale, le International Software Testing Qualifications Board (ISTQB) chapeaute l’instauration et le bon fonctionnement de méthodologie de test.

Cette entité est une organisation de certification qui vise à établir des standards de hautes qualités.

Le ISTQB défini l’activité de tester comme le processus qui consiste durant tout le temps de vie d’une application, à vérifier qu’une implémentation logicielle fait ce qu’elle doit faire, dans un laps de temps donné, avec consommation de ressource acceptable et qui soit retro-compatible.

Introduction

Je veux développer des applications, pourquoi tous ces détails à propos des tests ?

La réponse est simple ; parce que les activités de tests se font tout au long du cycle de vie du développement d’un logiciel. Quand les premières ébauches sont détaillées, des simulations sont faites et des gens d’expérience au sein de l’entreprise décide si oui ou non, en fonction des simulations et de leur expérience, la proposition est une façon efficace de résoudre le problème. Quand le code est lui-même écrit, il soit être testé afin de s’assurer que l’application ne plante pas et fait bien ce qui était attendu.

Avant la phase de livraison, une étape des tests est d’effectuer la phase d’acceptation ou le client test lui-même l’application dans un environnement contrôler et valide que le logiciel correspond bien à ce qu’il a demandé.

Après la livraison, les tests d’intégration permettent de détecter des problèmes au niveau de l’infrastructure de l’application. Les tests peuvent être réalisés avec le debugger en utilisant les techniques présenter ci-haut mais le principal désavantage de cette technique est la répétition ! La tâche est de tester une suite de d’opération effectuée de manière manuelle et répétitive…

L’objectif de cette section est de vous fournir une méthodologie ainsi que des outils afin de développer des tests adéquats mais, aussi de manière automatisée !

Les tests sont une part essentielle du développement applicatif et devrait commencer aussitôt que possible car, l’effort pour corriger un défaut augmente exponentiellement en fonction du temps que cela a pris pour découvrir ledit défaut !

Durant la phase de développement, en plus décrire le code pour la solution, il faut aussi écrire du code pour tester notre solution.

Ces tests peuvent être exécutés manuellement ou par un outil destiner à cette fin.

Quand vous écrivez du code, vous devez penser à oui, programmer la solution mais, aussi comment la tester !

Cette approche (tests, ensuite code) est connue sous le nom de TDD (Test Driven Development). Ce paradigme nous dit de penser et de tester la solution avant de l’avoir proprement écrite... ce qui est trop difficile à tester doit encore être bien plus difficile à réaliser...

Junit

JUnit est un framework open source pour le développement et l'exécution de tests unitaires automatisables. Le principal intérêt est de s'assurer que le code répond toujours aux besoins même après d'éventuelles modifications.

Plus généralement, ce type de tests est appelé tests unitaires de non-régression.

Bien que JUnit soit intégré à la plupart des IDE, il ne fait pas partie de la librairie standard de Java.

En fait, JUnit est le framework de test unitaire qui fait partie d'un plus grand ensemble nommé XUnit. XUnit désigne tous les frameworks de test répondant à certains critères pour une multitude de langages.

Il y a par exemple CUnit pour le C, CPPUnit pour le C++ ou encore PHPUnit pour PHP. Et la liste est longue...

Il existe plusieurs types de tests : - Les tests d'intégration : Le programme créé s'intègre-t-il bien dans son environnement d'exécution ? Ce type de test s’étend à plusieurs composantes et va valider le bon fonctionnement des communications entre les différents systèmes et les différents composants.

• Tests d'acceptation : L'utilisateur final accepte-t-il le logiciel ?

• Les tests de régression (fonctionnel) : Ce type de test est utilisé de manière périodique afin de s’assurer que ce qui a déjà été tester l’est bel et bien toujours. Ce type de test est primordial pour de gros projet qui implique une multitude de développeur. Du code changer par un développeur et qui passe le test brisera presque à coup sur le code d’un autre développeur.

• Les tests unitaires : Destinés à tester une unité du logiciel. Les tests unitaires sont la première ligne de défense de votre programme. Si vos tests unitaires sont mauvais votre solution sera nécessairement mauvaise.

Ce sont ces derniers qui nous intéresseront et les unités que nous allons tester seront les méthodes de nos classes.

JUnit propose : - Un framework pour le développement des tests unitaires reposant sur des assertions qui testent les résultats attendus. - Des applications pour permettre l'exécution des tests et afficher les résultats de manière automatiser. - Des sources de données fausses (faker).

Le but est d'automatiser les tests.

Ceux-ci sont exprimés dans des classes sous la forme de cas de tests avec leurs résultats attendus.

JUnit exécute ces tests et les comparent avec ces résultats.

Cela permet de séparer le code de la classe, du code qui permet de la tester.

Souvent pour tester une classe, il est facile de créer une méthode main() qui va contenir les traitements des tests.

L'inconvénient est que ce code "superflu" est inclus dans la classe.

De plus, son exécution doit se faire manuellement.

La rédaction de cas de tests peut avoir un effet immédiat pour détecter des bugs mais, surtout elle a un effet à long terme qui facilite la détection d'effets de bords lors de modifications.

Les cas de tests sont regroupés dans des classes Java qui contiennent une ou plusieurs méthodes de tests. Les cas de tests peuvent être exécutés individuellement ou sous la forme de suites de tests.

JUnit permet le développement incrémental d'une suite de tests.

Avec JUnit, l'unité de test est une classe dédiée qui regroupe des cas de tests. Ces cas de tests exécutent les tâches suivantes : - Création d'une instance de la classe et de tout autre objet nécessaire aux tests - Appel de la méthode à tester avec les paramètres du cas de tests - Comparaison du résultat attendu avec le résultat obtenu : en cas d'échec, une exception est levée, un succès.

JUnit est particulièrement adapté pour être utilisé avec la méthode eXtreme Programming (XP) puisque cette méthode préconise, entre autres, l'automatisation des tâches de tests unitaires qui ont été définies avant l'écriture du code.

Jusqu’à présent, JUnit se présentait sous forme d’une bibliothèque monolithique. JUnit 5 est divisé en 3 modules : - JUnit Platform : contient tout l’aspect « moteur » de JUnit. On utilise ce module lorsqu’on veut faire exécuter les tests. - JUnit Jupiter : combine une API et des mécanismes d’extension. Ce sont les éléments de ce module qu’on utilise dans les tests unitaires. - JUnit Vintage : fournit un moyen d’exécuter les tests unitaires existants initialement écrits pour JUnit 3 et 4.

Pour tester, nous allons nous baser sur trois assomptions : - Si ça marche une fois, ça marchera les autres fois ; - On teste le négatif, le zéro et le positif ; - Si ça marche pour quelques valeurs, ça marchera pour toutes les autres ;

- Ces trois assomptions réduisent radicalement le nombre de cas de test à effectuer.

https://junit.org/junit5/docs/current/user-guide/#writing-tests

Quelques principes : - Celui qui code une classe ne devrait pas la tester, apporter une nouvelle vue à ce problème est toujours une bonne chose ; - Testez les entrées valides mais, aussi les entrées invalides. Que se passe-t-il si je donne un caractère au lieu d'un entier ? - Partez avec un esprit de challenger ! Si vous faites des tests, c'est pour trouver le plus d'erreurs possibles, pas pour confirmer qu'il n'y en a pas ; - Soyez sûrs du résultat théorique avant de lancer le test. Ainsi, vous éviterez le "Ah, ça ne fait pas ? Mais c'est cohérent quand même, c'est moi qui ai dû me tromper en faisant la modélisation. Modifions ce test pour qu'il passe."

Citation : inconnu Si vous pensez que tester en premier est coûteux, essayez donc de debugger plus tard.

Localisation des tests

Par rapport au code qui se situe, selon la convention Java, dans le répertoire /src, les tests se situe au niveau du répertoire /tests.

Le répertoire doit bien entendu être identifié comme tel par votre IDE IDEA IntelliJ.

Installation de JUnit

Broche à foin, devrait utiliser Maven ou Gradle…

Workaround : Ajouter l’annotation @Test au-dessus d’une fonction valide. Mettre le curseur sur l’annotation et appuyer sur alt+enter et ajouter JUnit 5.8.

Les annotations JUnit

Les annotations JUnit sont une forme spéciale de métadonnées qui peuvent être ajouté au code Java (penser @Override) pour une meilleure lisibilité. Les variables, paramètres, paquetage, méthodes ainsi que les classes peuvent être annoté.