Catégorie: Tests

En ce moment, je suis en pleine session d'écriture de tests, et une chose en particulier me fait tiquer, a savoir les tests qui ne sont pas couverts a 100 %.

Dans le code en questions, les tests qui font baisser la couverture sont en général des tests qui concernent les exceptions.

On y trouve deux familles de tests, on a donc:

Le test "avec attribut" 

Ce test utilise l'attribut ExpectedException pour que le test fonctionne réussisse si et seulement si il jette un exception du type demande (ici, ArgumentOutOfRangeException). Le problème, en termes de couverture, est que tout le code situe en dessous de l'exception est ignore, le code n'est donc pas couvert a 100%.

Le test "traditionnel"

Si on n'utilise pas NCover, ou si on veut faire des tests sur le message retourné, on produit plus régulièrement de genre de code :

NB. : cet exemple vient directement du blog de NUnit, alors on peut admettre qu'il soit mentionné comme "bonne pratique"

Sauf que...

Sauf que si les tests fonctionnent correctement, une partie du code ne sera jamais atteinte, de même que si ils échouent.

Pourquoi ca pose problème ?

En général, je ne cherche pas a atteindre 100% de couverture...dans mon code testé ! Par contre, si une partie du code de test n'est pas joué, cela peut vouloir dire, au choix, deux choses :

1. Que le code testé est faux
2. Que le test est faux

Comment corriger les tests ?

Une option est de reprendre le code ci-dessus de la façon suivante :

Le catch sur une exception n'est plus présent...effectivement, mais de toute façon, si il n'est plus présent, le test va échouer quoi qu'il arrive...

Et selon vous, la couverture du code de test est-elle importante ? Cette méthode vous semble-t'elle valide ?

Le post est un peu vieux, mais avec les vacances, je l'avais manque.

Le 29 Juillet, TypeMock organise un séminaire web (webinar) gratuit sur le sujet de l'introduction des tests unitaires au sein d'une société ou d'une equipe, ainsi que sur des trucs et astuces autour des tests unitaires.

Le webinar est anime par Roy Osherove, qui a récemment écrit un livre très sympa sur les tests unitaires (la critique doit suivre dans les jours a venir ;) )...

Personnellement, je pense m'inscrire, deux sessions sont prévues, une a 6 heures du mat' pour nous (un peu tôt), l'autre a 21 heures (un peu tard).

Pour plus de détails, voir ici :

The Typemock Insider Blog: Lead the way in unit testing - live Webinar

J'avais mentionne dans mon article Utilisation de Frameworks de Mock en .Net un framework de Mock bien sympathique, a savoir TypeMock Isolator.

Depuis aujourd'hui, est sorti un bundle comprenant TypeMock + un add-on permettant le test unitaire dans ASP.NET.

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.

Typemock is launching a new product for ASP.NET developers - the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.
The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many 'hard to test' technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.

The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.
Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.
Go ahead, click the following link for more information on how to get your free license.

 

Alors, oui, c'est de la pub éhontée, pour espérer gagner une licence gratuite...mais c'est aussi un très bon produit, que j'avais pu tester avec leur version  communautaire (malheureusement discontinuée), et qui permets de tester facilement du code qui normalement ne peut pas être testé...

Alors, si vous avez des tests a faire, allez jeter un oeil (et ca marche AUSSI avec Sharepoint ;) )

Suite à une petite discussion sur un forum externe a DVP (celui d'un des livres que je suis en train de lire), je me pose un peu des questions sur les pratiques de tests(unitaires ou autres).

De mes différentes expériences, un a grosso modo deux choix, avec une variante :

• Stocker les tests dans des projets spécifiques :

Dans ce cas, que j'utilise en général, on va ajouter à la solution un (ou plusieurs, dan le cas ou on veut séparer les tests unitaires et les tests d'intégration) projet, dont le contenu sera uniquement composé de tests. Par exemple, ma solution Solution1 va avoir un projet Solution1.UnitTests et un projet Solution1.IntegrationTests. Cette configuration va me permettre de localiser facilement les tests, de configurer facilement un serveur d'intégration continue pour lancer le(s) projet(s) de test.

• Stocker les tests dans les projets du code testé:

L'avantage principal de cette méthode est de pouvoir accéder aux propriétés internes, voire privées (si le test est dans la classe) de la classe en cours de test. Cela permets aussi de voir facilement le code testé, le code étant dans le même fichier, ou dans le même répertoire.

Personnellement, je suis plutôt fermement convaincu que la première méthode est la meilleure.

En premier lieu, les tests unitaires doivent être des tests de "boite noire" , donc des tests qui en s'occupent pas du contenu réel du code testé, mais des entrées et sorites. Dans le cas contraire, les tests en savent souvent trop sur le code testé, et finissent par devenir fragiles et constituent une résistance au changement. Par conséquent, je considère l'avantage principale du stockage de tests dans le même projet comme potentiellement dangereux

Ensuite, imaginons que, pour des raisons d'extensivité des tests, on veuille explicitement tester un membre interne d'une classe donnée. Dans ce cas, il suffit d'ajouter l'attribut InternalsVisibleTo pour contourner le problème.

Enfin, cela permets de ne pas livrer de code qui ne sera pas utilisé par les clients finaux.

Alors, à ca, on m'à répondu que c'était "plus simple" de mettre le code de test dans les mêmes projets/fichiers.mais je ne suis pas tout à fait d'accord, d'ou ma question, qu'en pensez-vous ???

Je suis régulièrement le blog de Roy Osherove, un développeur et architecte qui travaille actuellement pour TypeMock, un éditeur de logiciel qui publie le Framework de mocking...typeMock ;)

En general, son  blog est déjà assez intéressant (si vous etes interesses par tout ce qui touche aux tests unitaires, bien sur...), mais, depuis quelques temps, il poste des webcasts de revue de tests unitaires, sur des projets aussi peu stratégiques et visibles que le framework Asp.Net MVC, ou Unity (le conteneur IoC de Microsoft).

La première revue de code est un peu...bizarre (tournée a deux heures du matin, avec un petit peu de mauvaise foi par moments ;) ), mais très intéressante tout de même, les suivantes sont encore mieux...

Si vous utilisez des tests unitaires (je ne parle pas de TDD, mais de tests unitaires au sens large), ou simplement si vous êtes curieux (et que vous n'êtes pas effrayés par un webcast en anglais, bien articulé), je vous conseille de vous rendre a l'URL suivante pour jeter un oil a ces webcasts (prévoyez une petite heure, ce ne sont pas des DimeCasts ;)

http://weblogs.asp.net/rosherove/archive/tags/TestReview/default.aspx