How to make unit test?

The unit test :

Definition:

“Test Unit (TU) (development test): A unit test is a test conducted by the developer in development environment; it is intended to demonstrate a unit complies with the criteria defined in the technical specifications.”

In the case of a procedural language unit is « the process », and in the case of an object-oriented unit is represented by « The Class. »

Unit testing is testing the first white box-type to be charged by profile type developers.

In the case of this kind of test the important question is « What is the quality of the units developed and how to measure it?

Thus, it is for the developer to test a module, independently of the rest of the program in order to ensure that it meets the requirements (functional / technical) and it works correctly. This audit is currently an audit of code coverage, which is to ensure that the test leads to perform all (or a portion) of the instructions in the code to test.

Thus, it should be understood that the unit must conduct (or the piece of code):

• Check the functions and roles of the Unity
• Test the boundaries of the unit (bounds: zero, one, complete. Search an empty collection, for example)

This results in a simple way by creating a test class per class developed.

Example of basic unit tests and represented by a class of test:

1. Invoke the method with the values passed as parameters
2. Observe the results
3. Check if the results are those expected

Thus we must select values for which we can determine the outcome.

As we see it may take time to perform these tests manually. Similarly, if classes are complex and that we must carry out regression tests…

To help the developer tools exist and JUnit is the most effective (see details in the section on tools).

Examples of other types of unit tests:

• Audit code: verification step of lines of code against a standard development
• Bound checking tool to check any entries in the memory areas
• Documentation: reading source code automatically generating descriptions of the code
• Memory leak detectors: these tools tests memory allocation applications
• Static code (path) analyzer: it is identifying paths / code structure as measured McCabe, etc.

Unit testing tools:

Tools integration:

• MAVEN: free software tool for the management and automation of production of Java software projects. It provided a way to synchronize independent projects: publication Standardized information vending module jar. In basic version, Maven can dynamically download material on storage software known. It offers the transparent synchronization of modules required.
• ANT : idem que MAVEN
• Continuum
• CVS Subversion
• JIRA

The testing Framework:

The best approach to undertake unit testing is to establish a « prepared environment » (or Framework) that is dedicated. In the case of development of Java type, the combination is the perfect synergy of tools below:

• Java development environment integrated with Eclipse in it:
• unit testing tools: JUnit (Tools written by the creator of the programming Xtrem Kent Beck), it allows to test the development of Java type
• Generating doc. : JavadocC# / .Net : NUnit
• C++ : CPPUnit / CUnit
• Fortran : fUnit
• Delphi : DUnit

The three basic concepts of JUnit are:

1. Verdict: Each test can go GREEN (OK or pass) or red (fail or NOK)
2. Test case: determining if a method produces good results for a given set of values passed as parameters:
   • Represented by a method in a class test
   • There have as many methods as you want in a class of tests
   • There is often a test class for each class to test (one to one)
3. Test suite: it contains a set of test cases for one class

The analytical coverage tests:

• Cobertura. It can produce:
  • The number of classes per package
  • The percentage of lines tested
  • The percentage of tested expressions
  • The list of components with the test unit is in error (list of anomalies by component / access services concerned)
• EMMA
• Clover

Tools Control code:

Checkstyle: This control ensures a well-defined level of quality of source code.

The reporting tools

Weekly reporting is generated and provided through the tool MAVEN.

Reports to generate 1: Unit Testing in error

This report presents a summary of all the tests and highlights the following:

• Number of tests
• Number of errors
• Percentage of success

Reports to generate 2: Coverage of unit tests

Tools defects:

Each anomaly must be met up through a management tool defects. Thus, the anomalies are included in the tool as tests.

The analysis should lead to:

• Changing the unit test to incorporate a change in the code. The change was made to replay developer testing
• The amendment of the Code, if a regression is found. The corrected source code is up for re-replay testing and closure of the defect if the test is validated

Some tools:

• Mantis
• BugZilla
• The module of Quality Center Defects (ed. HP Mercury)

Reminder of good practice in unit tests:

• Use a framework absolutely
• Interface with the framework tools
• Write tests before code
• A class = test
• To test the classes in the same package (same directory) that the classes related
• Code unit tests must change with the application and must be maintained
• The name of the classes of tests must necessarily include the word TEST (to distinguish them easily and Junit 3 and found her classes)
• As for automated functional testing make sure to put the system in the same condition as before the tests (this « rehabilitation » may be part of the actions of your Selenium test scripts for example)
• How to reduce test time:
• Isolate the unit tests identified as greedy time (DB access, competition …) and run less frequently than every compilation, for example: before each filing of source code in the common code base
• Do the unit tests on the assembly that has been modified and not the entire

To write this article I helped my experiences but also the return of developer and sites such as (whom I thank for their very informative articles):

• http://fr.wikipedia.org/ (and UK version)
• http://developpez.com (http://smeric.developpez.com/java/astuces/tests/)
• http://www.dotnetguru.org/articles/dossiers/testunitaires/UnitTest.htm
• http://www.tarpoon.org/tag/cobertura/

I advise you to report for more details on the subject.

Comment mettre en oeuvre des tests unitaires ?

Définition :

« Test Unitaire (TU) (ou test de développement) : un test unitaire est un test mené par le développeur en environnement de développement, il a pour but de démontrer qu’une unité respecte bien les critères définis dans les spécifications techniques ».

Dans le cas d’un langage procédural l’unité est « la procédure », et dans le cas d’un contexte orienté objet l’unité est représentée par « La classe ».

Les tests unitaires sont les premiers tests de type boite blanche devant être pratiqués par des profils de type développeurs.

Dans le cas de ce type de tests la question importante est « Quel est la qualité des unités développés et comment le mesurer ? ».

Ainsi, il s’agit pour le développeur de tester un module, indépendamment du reste du programme, ceci afin de s’assurer qu’il répond aux spécifications (fonctionnelles / techniques) et qu’il fonctionne correctement. Cette vérification s’accompagne couramment d’une vérification de la couverture de code, qui consiste à s’assurer que le test conduit à exécuter l’ensemble (ou une fraction déterminée) des instructions présentes dans le code à tester. ».

Ainsi, il faut comprendre ce que l’unité doit effectuer (ou la parcelle de code) :

• Vérifier les tâches et rôles de l’unité
• Tester les frontières de l’unité (bornes : zéro, un, complet. Chercher une collection vide par exemple)

Cela se traduit de manière simple par la création d’une classe de test par classe développée.

Exemple de tests unitaires de base et représenté par une classe de test :

1. Invoquer la méthode avec des valeurs passées en paramètres
2. Observer les résultats
3. Vérifier si les résultats sont ceux attendus

Ainsi il faut sélectionner des valeurs pour lesquelles on peut déterminer les résultats attendus.

Comme on le voit cela peut prendre du temps d’effectuer ces tests de manière manuelle. De même si les classes sont complexes et que l’on doit procéder à tests de non régressions…

Pour aider le développeur des outils existent et Junit est le plus efficace (voir détails dans le paragraphe sur les outils).

Exemples d’autres types de tests unitaires :

• Audit de code : vérification pas à pas des lignes de codes vis-à-vis d’un standard de développement
• Bound checking : Outil permettant de vérifier d’éventuelles écritures dans les zones mémoires
• Documentation : lecture de code source générant automatiquement les descriptions du code
• Memory leak detectors : ces outils tests l’allocation en mémoire des applications
• Static code (path) analyzer : il s’agit d’identifier les chemins / structure de code selon les mesures McCabe, etc.

Outillages des tests unitaires :

Outils d’intégration continue :

• MAVEN : outil logiciel libre pour la gestion et l’automatisation de production des projets logiciels Java. Il fourni un moyen de synchroniser des projets indépendants : publication standardisée d’information, distribution automatique de modules jar. En version de base, MAVEN peut dynamiquement télécharger du matériel sur des entrepôts logiciels connus. Il propose ainsi la synchronisation transparente des modules nécessaires.
• ANT : idem que MAVEN
• Continuum
• CVS Subversion
• JIRA

Les Framework de tests :

La démarche optimale pour entreprendre les tests unitaires est de mettre en place un « environnement préparé » (ou Framework) qui soit dédié. Dans le cas de développement de type Java, la combinaison parfaite est la synergie des outils ci-dessous :

• Java : Environnement de développement intégré : Eclipse avec en son sein :
  • Outils de tests unitaires : Junit (Outils écris par le créateur de l’Xtrem programming Kent Beck), il permet de tester les développements de type Java
  • Génération de doc. : Javadoc
• C# / .Net : NUnit
• C++ : CPPUnit / CUnit
• Fortran : fUnit
• Delphi : DUnit

Les trois concepts de bases de Junit sont :

1. Verdict : chaque test peut passer en VERT (pass ou OK) ou en ROUGE (fail ou NOK)
2. Cas de test : détermine si une méthode produit les bons résultats pour un ensemble donné de valeurs passées en paramètres :
   1. Représenté par une méthode dans une classe de test
   2. Il y avoir autant de méthodes que voulu dans une classe de tests
   3. Il existe souvent une class de test correspondant à chaque class à tester (one to one)
3. Tests suite : elle contient un ensemble de cas de test pour une classe

Les outils d’analyse de couverture des tests :

· Cobertura. Il peut produire :

o Le nombre de classes par paquetage

o Le pourcentage de lignes testées

o Le pourcentage d’expressions testées

o La liste des composants dont le test unitaire est en erreur (liste des anomalies par composant / services d’accès concernés)

· EMMA

· Clover

Outils de contrôle de code :

Checkstyle : Ce contrôle permet d’assurer un niveau bien défini de qualité de code source.

Les outils de reporting

Un reporting hebdomadaire est prévu et généré au travers de l’outil MAVEN.

Rapports à générer 1 : Tests unitaires en erreur

Ce rapport présente une synthèse de l’ensemble des tests et fait ressortir les éléments suivants :

– Nombre de tests effectués

– Nombres d’erreurs

– Pourcentage de réussite

Rapports à générer 2 : Couverture des tests unitaires :

Outils de gestion des anomalies

Chaque anomalie rencontrée doit être remonté au travers d’un outil de gestion des anomalies. Ainsi, les anomalies sont intégrées dans l’outil au fur et à mesure des tests. L’analyse doit conduire à :

· La modification du test unitaire afin d’intégrer une évolution du code. La modification est réalisée développeur pour rejeu des tests

· La modification du code, si une régression est constatée. Le code source corrigé est re-livré pour rejeu des tests et clôture de l’anomalie si le test est validé

Quelques outils :

• Mantis
• BugZilla
• Le module Defects de Quality Center (éditeur HP Mercury)

Rappel des bonnes pratiques dans les tests unitaires :

• Utiliser absolument un framework
• Interfacer le framework avec les outils
• Ecrire les tests avant le code
• Une classe = un test
• Mettre les classes de tests dans le même package (et même répertoire) que les classes s’y rapportant
• Le code des tests unitaires doit évoluer avec l’application et doit donc être maintenu
• Le nom des classes de tests doivent comporter obligatoirement le mot TEST (pour les différencier facilement et Junit 3 retrouve ses classes ainsi)
• Comme pour les tests fonctionnels automatisés pensez bien à remettre le système dans le même état que celui d’avant les tests (cette « remise en état » peut faire partie des actions de vos scripts de tests Selenium par exemple)
• Comment réduire les temps de test :
  • Isoler les tests unitaires identifiés comme gourmand en temps (accès DB, concurrence…) et les exécuter moins souvent qu’à chaque compilation, exemple : avant chaque archivage du code source dans la base de code commune
  • N’exécuter que les tests unitaires concernant l’assemblage qui a été modifié et non pas l’intégralité

Pour rédiger cet article je me suis aidé de mes expériences mais aussi du retour de développeur et de certains sites comme (que je remercie pour leurs articles fort instructifs) :

• • http://fr.wikipedia.org/ (et la version anglaise également)
  • http://developpez.com (http://smeric.developpez.com/java/astuces/tests/)
  • http://www.dotnetguru.org/articles/dossiers/testunitaires/UnitTest.htm
  • http://www.tarpoon.org/tag/cobertura/

Je vous conseil de vous y rapporter pour plus de détails sur le sujet.