Automatiser les tests unitaires

Les tests unitaires sont ces tests qu'on applique à des objets ou à de petites entités atomiques d'un programme pour vérifier si ces entités rencontrent un certain nombre d'exigences. Typiquement, le contrat de comportement associé à une classe donnée ou à ses instances sera défini au préalable, et procéder à des tests unitaires impliquera de vérifier le respect de ce contrat.

Les tests possibles sont nombreux, en incluent entre autres possibilités les tests en boîte noire (vérification du respect des spécifications de l'entité sans examiner le détail de l'implémentation) et les tests en boîte blanche (vérification du comportement correct de l'objet en connaissant son implémentation et en tenant compte de celle-ci).

// inclusions pour A, B et C
#include "RegistreTests.h"
#include <iostream>
int main() {
   using std::cout;
   A a, a0;
   //B b;
   C c;
   RegistreTests::get().proceder(cout);
}

Les tests unitaires sont présumés indépendants les uns des autres, donc nous ne présumerons pas de l'ordre selon lequel les divers tests seront réalisés.

Notez que main() déclare deux instances de A, aucune instance de B et une instance de C. Notre souhait est que la classe A soit testée une seule fois (même si on en trouve deux instances dans le programme), que la classe B ne soit pas testée (parce qu'elle n'est pas utilisée) et que la classe C soit testée une seule fois aussi.

Nous voudrons enfin que la stratégie de test appliquée dépende des types à tester, mais nous ne voulons pas d'une stratégie intrusive où tous les types à tester devraient être polymorphiques et dériver d'un parent commun. Une stratégie intrusive aurait entre autres défauts celui de dénaturer les types valeurs en accroissant artificiellement l'espace que leurs instances occupent en mémoire, ce qui pourrait aller jusqu'à invalider certains tests.

Dernier détail : nous voudrons que la mécanique de tests elle-même produise des messages d'erreurs standardisés si des exceptions sont levées lors des tests unitaires de certains types, tout en faisant en sorte que la mécanique de tests soit neutre face aux exceptions (donc que les exceptions levées soient notées par la mécanique de tests mais filtrent tout de même vers le code client sans avoir été modifiées entre-temps).

Nommer les types de manière non ambiguë

C++ offre, à travers les mécanismes de Run Time Type Information (RTTI) que sont le type std::type_info et l'opérateur typeid, une manière localement homogène d'identifier le nom des types. J'indique explicitement localement homogène du fait que les noms obtenus par ce mécanisme peuvent varier d'un compilateur à l'autre ou d'une version à l'autre d'un même compilateur. Si nous souhaitons générer des messages uniformes pour signaler la levée d'exceptions lors des tests pour un type donné, il sera pertinent pour nous de mettre en place une stratégie homogène de nommage dans nos programmes.

Une technique simple pour obtenir un schème homogène de manière persistante pour un système donné est d'utiliser des traits. Le fichier type_name.h montre comment on peut y arriver et définit une macro qui simplifie la génération d'associations entre un type et le nom que le système lui attribuera (non, je n'aime pas les macros moi non-plus, mais ça allégeait le travail dans ce cas-ci et elles ne sont pas strictement nécessaires).

#ifndef TYPE_NAME_H
#define TYPE_NAME_H
#include <string_view>
//
// Cas par défaut (volontairement laissé indéfini)
//
template <class>
   struct type_name;
//
// Une macro pour alléger la génération des traits
//
#define ADD_TYPE_NAME(type,name) \
   template <> \
      struct type_name<type> { \
         static constexpr std::string_view value() { \
            return #name \
         } \
      };
//
// Quelques noms de types communs
//
ADD_TYPE_NAME(signed char,signed char)
ADD_TYPE_NAME(unsigned char,unsigned char)
ADD_TYPE_NAME(char,char)
ADD_TYPE_NAME(unsigned short,unsigned short)
ADD_TYPE_NAME(short,short)
ADD_TYPE_NAME(unsigned int,unsigned int)
ADD_TYPE_NAME(int,int)
ADD_TYPE_NAME(unsigned long,unsigned long)
ADD_TYPE_NAME(long,long)
ADD_TYPE_NAME(float,float)
ADD_TYPE_NAME(double,double)
ADD_TYPE_NAME(long double,long double)
ADD_TYPE_NAME(std::string,string)
// etc.
#endif

//
// Remplacer ceci...
// 
template <class>
   struct type_name;

//
// ...par cela
//
template <class T>
   struct type_name    {
      static const auto value() {
         //
         // Activer RTTI pour utiliser ceci
         //
         return typeid(T).name();
      }
   };

Le registre de tests

Le registre de tests (classe RegistreTests) sera un singleton responsable de connaître la liste des tests à réaliser. Les types à tester s'y enregistreront à travers une classe polymorphique accessoire, UnitTestableRoot, dont les enfants seront génériques.

Sur demande, le singleton procédera en séquence aux tests unitaires sur chacun des types inscrits.

#ifndef REGISTRETESTS_H
#define REGISTRETESTS_H
#include "UnitTestableRoot.h"
#include <vector>
#include <functional>
#include <algorithm>
#include <memory>
#include <iosfwd>
class RegistreTests {
   RegistreTests() = default;
   std::vector<std::unique_ptr<UnitTestableRoot>> units;
public:
   static RegistreTests &get() noexcept {
      static RegistreTests singleton;
      return singleton;
   }
   template <class T, class F>
      void enregistrer() {
         units.push_back(std::make_unique<UnitTestableImpl<T, F>>());
      }
   void proceder(std::ostream &os) {
      for(auto & p : units) proceder(os);
   }
};
#endif

Quelques détails à noter :

• Le singleton RegistreTests est entièrement responsable de la portée des unités de tests. La seule mécanique pour y inscrire des unités à tester est la méthode générique enregistrer<T,F>() qui associe un test sur le type T à partir de la fonction (ou de la méthode de classe) F, et le destructeur du singleton s'assure de détruire chaque unité de test
• Chaque UnitTestableImpl<T,F> est un cas particulier de la racine polymorphique UnitTestableRoot spécialisé pour tester T à l'aide de F
• La méthode d'instance proceder(ostream&) invoque la méthode d'instance proceder(ostream&) de chaque UnitTestableRoot inscrit au singleton

Encadrement des objets de tests

Les objets permettant d'encadrer et d'intégrer les diverses tstratégies de tests unitaires dans un tout cohérent sont la paire de classes UnitTestableRoot, racine polymorphique abstraite, et UnitTestableImpl<T,F>, enfant générique implémentant une procédure de test unitaire spécifique au type T et passant par la fonction F.

#ifndef UNITTESTABLEROOT_H
#define UNITTESTABLEROOT_H
#include <string_view>
#include <iosfwd>
struct UnitTestableRoot {
   // template methode pattern
   void proceder(std::ostream &os) {
      proceder_impl(os);
   }
   virtual ~UnitTestableRoot() = default;
protected:
   void message(std::ostream &os, std::string_view);
   virtual void proceder_impl(std::ostream &) = 0;
};
template <class T, class F>
   class UnitTestableImpl
      : public UnitTestableRoot {
      F fct_;
      // méthode privée!
      void proceder_impl(std::ostream &os) {
         try {
            fct_(os);
         } catch (...) {
            message(os, type_name<T>::value());
            throw; // exception neutral
         }
      }
   };
#endif

#include "UnitTestableRoot.h"
#include <string_view>
#include <iostream>
using namespace std;

void UnitTestableRoot::message(ostream &os, string_viewname) {
   os << "Exception non attrapée lors des tests sur \""
      << name << "\"" << endl;
}

Automatiser l'enregistrement des types à tester

Nous ne voulons pas inscrire tous les types d'un programme à la liste de ceux pour lesquels des tests unitaires sont requis, mais nous voulons par contre faire en sorte que l'inscription au registre des tests soit aussi simple que le serait une simple annotation qui indiquerait « il faut tester ce type ».

#ifndef UNITTESTABLE_H
#define UNITTESTABLE_H
#include "RegistreTests.h"
#include <mutex>
template <class>
   struct relais_statique;
template <class T, class F = relais_statique<T>>
   class UnitTestable {
      static inline std::once_flag fanion;
      static void enregistrement() {
         std:::call_once(fanion, []{ RegistreTests::get().enregistrer<T,F>(); });
      }
   protected:
      UnitTestable() {
         enregistrement();
      }
   };
#endif

Notez le recours à relais_statique<T>. Bien que les clients de UnitTestable<T,F> puissent suppléer leur propre fonction de test F, il peut être utile d'ajouter une indirection générique (donc statique) permettant à des gens de choisir la fonction de test souhaitée de manière flexible. En fait, si nous voulons utiliser certains idiomes de programmation, cette indirection sera même nécessaire, comme nous le verrons ci-dessous.

Quelques classes testables

Dans les exemples qui suivent, nous utiliserons ce schème de foncteur statique indirect (passant au besoin par un relais_statique<T>) pour intégrer deux approches distinctes aux tests unitaires.

#include "type_name.h"
#include "UnitTestable.h"
#include <iosfwd>
class A : UnitTestable<A> {
   friend struct relais_statique<A>;
   static void UnitTest(std::ostream &os) {
      // tests divers sur la classe A
      os << "Tests unitaires sur A: Ok" << endl;
   }
   // etc.
};
template <>
   struct relais_statique<A> {
      void operator()(std::ostream &os) {
         A::UnitTest(os);
      }
   };
ADD_TYPE_NAME (A,class A)

Notez que nous n'aurions pas pu indiquer que A dérive de UnitTest<A,&A::UnitTest> du fait qu'au moment d'indiquer le parent d'une classe, seul le nom de la classe enfant existe et le compilateur n'aurait pu comprendre, à ce stade, ce que signifie &A::UnitTest.

class A : UnitTestable<A, &A::UnitTest> // illégal, nom inconnu à ce stade!
{
   // ...
};

En C++, un nom doit être introduit dans un programme avant d'y être utilisé. Ici, le compilateur ne pourrait pas savoir si A::UnitTest est une méthode (encore moins sa signature!), un attribut ou autre chose d'étrange, ce qui lui rendrait impossible la tâche de générer le code du parent.

De même, nous n'aurions pas pu déclarer un prototype de méthode hors de la déclaration de la classe A elle-même, car ce serait contraire aux règles du langage.

class A;
void A::UnitTest(ostream&); // illégal!
class A : UnitTestable<A, &A::UnitTest>
{
   // ...
};

Par contre, le recours à relais_statique, qui est générique, retarde la génération du recours à A::UnitTest() au moment où le compilateur rencontrera le besoin de générer l'opérateur () de relais_statique<A>, et à ce moment il saura tout ce qu'il a besoin de savoir.

Le recours à une indirection à travers la classe générique relais_statique n'est donc pas un simple artifice. Il existe des alternatives mais elles ne sont pas très jolies.

// ...
class B : UnitTestable<B> {
   friend struct relais_statique<B>;
   static void UnitTest(std::ostream &os) {
      // tests sur B...
      os << "Tests unitaires sur B: Ok" << endl;
   }
};
template <>
   struct relais_statique<B> {
      void operator()(std::ostream &os) {
         B::UnitTest(os);
      }
   };
ADD_TYPE_NAME (B,struct B)

class C : UnitTestable<C> {
   friend struct relais_statique<C>;
   static void TestUnitaire(std::ostream &os) {
      //throw 0;
      os << "Tests unitaires sur C: Ok" << endl;
   }
};
template <>
   struct relais_statique<C> {
      void operator()(std::ostream &os) {
         C::TestUnitaire(os);
      }
   };
ADD_TYPE_NAME (C,struct C)