Encore un titre qui rappelle une bonne vieille pub[1]
De quelle formule s'agit-il ?
Et bien, je crois que j'ai trouvé ma réponse à la question que je vous posais[2] dans ce billet.
Le sujet est revenu sur le tapis au boulot après que le chef eut demandé à l'intégriste de faire une doc sur les tests unitaires pour Java, dotNet et C++ au travers des outils JUnit, NUnit et CppUnit.
Je passe outre le fait qu'un document de 129 pages censé finir sur le Wiki du département est lourdingue à lire pour vous fournir mes conclusions et mes réflexions sur la chose.
Je persiste donc dans les tests boîte noire en fournissant des tests unitaires pour les fonctions, procédures ou méthodes[3] qui sont définies dans les interfaces.
Avantages :

  • On prouve que son code colle toujours à la spec et fait ce que l'on attend de lui
  • On peut mettre dans les tests les bugs trouvés par les utilisateurs de notre code
  • On passe pas son temps à pondre du test pour du détails d'implémentation


Inconvénients :

  • Y en a pas vu que c'est moi qui cause et que ma méthode est parfaite


Vous me direz en attendant mon faux pas :

Et comment tu fais pour vérifier que ton détail d'implémentation n'est pas buggé ? Comment tu fais si quelqu'un reprend ton code pour qu'il n'y rajoute pas des trucs pas prévus ?

Forcément, vu que j'ai réponse à tout, j'ai réponse à ça. En un mot comme en cent mais ici, en un mot seulement : assertions
Si les assertions sont inutilisables pour vérifier l'aspect externe d'un composant[4], on peut s'en servir pour documenter son code à l'attention du relecteur ou ami co-codeur[5] et surtout vérifier les pré-conditions, post-conditions, variants et invariants d'un code enfoui[6].
Avantages :

  • permet de vérifier lors du développement que les attendus d'un bout de code sont vérifiés
  • documente le code sur les comportements déviants à éviter dans l'implémentation du code sus-cité
  • peut être débrayé facilement
  • ne nécessite pas l'écriture d'une trollée de jeux de tests inutiles


Inconvénients :

  • Encore une fois, je n'en vois pas


Pour constituer un trio fantastique, il ne manque plus qu'un outil de couverture de code et la qualité ne pourra qu'augmenter.
Je vous recommande chaudement la lecture des documents traitant de tout ça pour Java et qui se trouvent là.

Je ferai peut-être un petit billet d'exemples si cela vous intéresse et aussi histoire pour moi de garder une trace.

UPDATE :
Je conseille aussi la lecture de ces slides. C'est en anglais mais montre à quel point un petit algo peut faire exploser le nombre de tests. Dans ce doc, les tests boîte blanche servent avant tout à la couverture de code et donc à la création d'un jeu de valeurs adéquates.

Notes

[1] Dont il est impossible de retrouver la trace sur le grand Ternet :-\

[2] et à laquelle personne n'a répondu... re :-\

[3] Je ne suis pas raciste, je parle à la fois de programmation procédurale et objet

[4] Les mauvais paramètres et fautes d'appel doivent être traités en tant que tels

[5] La classe ce néologisme-là

[6] Non accessible directement à l'utilisateur