Test unitaire

La méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester (Test Driven Development). Ceci permet de définir précisément l'interface du module à développer. Les tests sont exécutés durant tout le développement, permettant de visualiser si le code fraîchement écrit correspond au besoin.

Lors d'une modification d'un programme, les tests unitaires signalent les éventuelles régressions. En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code.

Les tests unitaires peuvent servir de complément à l'API, il est très utile de lire les tests pour comprendre comment s'utilise une méthode. De plus, il est possible que la documentation ne soit plus à jour, mais les tests eux correspondent à la réalité de l'application.

Un test doit correspondre aux spécifications de l'application, il faut donc écrire les tests en premier puis les faire passer par la suite plutôt que d'écrire le code avant et de prendre le risque d'être influencé par celui-ci lors de la rédaction des tests [6]. Bob Martin[7], grand défenseur de la méthode TDD, propose un modèle simple pour l'écriture des tests unitaires :

1. Écrire une fonction de test qui doit obtenir un résultat défini dans les spécifications. Ce code appelant un code qui n'existe pas encore, celui-ci doit échouer. Ceci a pour but de définir une fonction qui teste « quelque chose ».
2. Écrire le code (le minimum de « quelque chose ») pour faire réussir le test.
3. Une fois le test en succès, rajouter un autre test pour obtenir un résultat légèrement différent, en faisant varier les entrées par exemple. Ce nouveau test fera faillir le code principal.
4. Modifier le code principal pour faire réussir les tests.
5. Recommencer, en éliminant et refactorisant les éventuelles redondances dans le code des tests. On refactorise en même temps le code principal que le code des tests.
6. Un test unitaire doit tester une caractéristique et une seule. On ne définit pas un « scénario » de test complexe dans un test unitaire.
7. Il est déconseillé de tester les détails d'implémentation telles que les fonctions privées d'une classe, on se concentrera à tester les fonctions publiques, c'est-à-dire les interfaces avec lesquelles les acteurs extérieurs interagissent. Ainsi, on découple les tests de l'implémentation et on se concentre sur la vérification du comportement attendu tout en gardant une flexibilité sur la manière d'arriver au résultat souhaité.

Les mocks sont des objets permettant de simuler un objet réel de façon contrôlée. Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de couverture de code, et de fiabilité des tests[8]

• pour simuler une base de données, un service web, etc., les interactions entre l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs fonctionnements peut être un gain de temps considérable ;
• certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de code, par exemple le catch d'une exception ;
• sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code qui est testé (par exemple une base de données).

Cependant, une utilisation abusive de mock peut avoir l'effet inverse, notamment allonger le temps d'exécution des tests, rendre les tests compliqués à comprendre et à maintenir.

Lors d'une modification dans le code d'un programme, il se peut que certains tests ne passent plus ; dans ce cas, le développeur doit déterminer si cela vient du code en lui-même ou du test : si cela vient du test, le développeur doit modifier son test car la suppression de celui-ci entraînerait une augmentation des chances de régression du programme. Certains chercheurs ont développé des outils pour résoudre ce problème.

ReAssert[9] est un outil suggérant des réparations pour un test qui échoue, il analyse les tests à modifier et suggère des changements au développeur, si cette suggestion convient au développeur, il peut effectuer le changement en cliquant sur un bouton.

Les tests unitaires paramétrables sont des tests unitaires qui prennent des paramètres. Ils peuvent ensuite utiliser des outils comme QuickCheck pour générer des paramètres. Ces tests sont supportés par JUnit, TestNG et NUnit.

En s'appuyant sur des cas concrets d'entrée et sortie, la génération d'Oracle et sur la couverture de test pour minimiser les cas, des chercheurs ont réussi à générer des tests unitaires paramétrables[10]. Les résultats de cette méthode sont prometteurs.

Le terme générique « xUnit » désigne un outil permettant de réaliser des tests unitaires dans un langage donné (dont l'initiale remplace « x » le plus souvent).

• AUnit[12] pour Ada ;
• ASUnit[13] pour ActionScript ;
• Cppunit[14] pour C++ ;
• CUnit[15] pour C ;
• DUnit pour Delphi ;
• FLEXunit pour Adobe Flex ;
• Google Test[16] et Boost Test[17] pour C++ ;
• HUnit[18] pour Haskell ;
• JSUnit[19], QUnit[20], Unit.js[21] et Jest[22] pour JavaScript ;
• JUnit[23] et TestNG[24] pour Java ;
• NUnit[25] pour .NET ;
• Microsoft Unit Test[26] pour .NET ;
• xUnit[27] pour .NET ;
• NUnitASP[28] pour ASP.NET (support interrompu depuis le 31 janvier 2008) ;
• OUnit[29] pour OCaml ;
• OCunit pour Objective C ;
• PBUnit pour PowerBuilder ;
• PHPUnit[30], SimpleTest[31] et Atoum[32] pour PHP ;
• plunit pour Prolog ;
• utPLSQL [33] pour PL/SQL ;
• Unittest et PyUnit pour Python ;
• Tape pour JavaScript ;
• Test::Unit pour Ruby ;
• Test::More pour Perl ;
• Typemock pour .NET, C++, C#. Avec Typemock vous pouvez travailler sur legacy code aussi.
• SUnit[34] pour Smalltalk ;
• RPGUnit[35] pour RPG ;
• ScalaTest pour Scala
• SASUnit[36] pour SAS.