Coding Rules: Tests unitaires, mocking, et conventions de nommage


essential-unit-testingLe mocking d’objets:

Aujourd’hui, je présente à l’équipe R&D le mocking (en fait j’ai présenté le stubbing et le mocking, mais la suite de l’article décrit plutôt ce qu’est le stubbing, j’expliquerai la différence entre le stubbing et le mocking dans un autre article) d’objets afin de mettre à niveau tous les développeurs sur ce qu’il est possible de faire avec les tests unitaires.

Le mocking consiste à isoler certaines classes de leurs dépendances afin de pouvoir écrire des tests. Cela permet aussi de pouvoir effectuer des tests alors même que toutes les implémentations n’ont pas été effectuées. Cette isolation est quand même beaucoup plus intéressante lorsqu’il s’agit de s’abstraire de la couche d’accès aux données ou d’un service web. L’appel de ces couches pouvant être vraiment fastidieux et consommateur de temps : il faut préparer une base de données à renvoyer des données pertinentes pour le test ou s’assurer que le service web sera atteignable.

De plus, le mocking fait ainsi réfléchir sur les dépendances entre classes, puisqu’il faut créer des « Mock Objects » pour tous les objets dont dépend la méthode que l’on veut tester.

Pour rentrer dans le concret, je présente les frameworks de mocking de NUnit et celui proposé par les labos de recherche de Microsoft: Moles (J’adore)

Convention de nommage des tests unitaires:

Pendant la présentation, je fais aussi un petit point sur le nommage des tests unitaires.  Le but est que tous les développeurs utilisent cette convention que je pense être une bonne façon de faire, ou que nous la discutions ensemble, auquel cas j’ajouterai la nomenclature adoptée en fin d’article.

Pour ma part, j’utilise la nomenclature suivante: NomMethodeTestee_ContexteDuTest_ResultatAttendu() (c’est une convention que j’ai tirée après quelques lectures sur le BDD)

Pour moi, elle donne l’avantage de pouvoir identifier la méthode testée au premier coup d’oeil. Ensuite, on peut voir le contexte dans lequel le test est réalisé et le résultat qui est attendu par le test. C’est d’après moi la convention de nommage la plus simple tout en proposant les informations dont on a besoin pour comprendre pourquoi un test plante lors d’une lecture d’un compte-rendu des tests unitaires joués lors de l’intégration continue par exemple.

N’hésitez pas à proposer vos idées ou à critiquer ma nomenclature si vous voyez une meilleure façon de faire…

EDIT: Voici la nomenclature qui a été retenue par l’équipe au cours de la réunion:

NomClasse_NomMethodeTestee_ContexteDuTest_ResultatAttendu()

Elle permet d’après l’équipe de pouvoir identifier rapidement la classe testée, ce qui n’est pas évident dans le rapport CCNet des MSTests puisque les tests sont classés dans des listes (choisies par le développeur) mais que l’indication de la classe testée n’apparaît pas.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s