Fathi Bellahcene

[CodeContracts] PEX, un ami qui vous veut du bien

Lors de mes deux derniers posts (ici et ici), j’ai eu l’occasion de parler du framework proposé par Microsoft pour faire du Design by Contract.

J’ai pas abordé des sujets tels que l’analyse statique ou encore toutes les types de contrats possible car cela est déjà très bien documenté et amha le plus important est de savoir en quoi (en terme de design) cet outil à un intérêt dans l’amélioration de nos dev: l’analyse statique est pour moi quelque chose d’excellent et de très utile…mais qui ne n’impacte pas la manière de designer une application.

Parler de CodeContract et ne pas parler de PEX c’est passer à coté de quelque chose d’extremement important lorsque l’on utilise CodeContracts…c’est ce que je vais tenter de vous montrer ici!

Une fois que l’on est convaincu que le DbC est quelque chose d’important et que l’on souhaite utiliser, la premiere question que l’on se pose est :

-“je met quoi moi sur cette méthode comme contrat?”

et la réponse est :

-“bah je vérifie que les paramètres de ma méthodes sont pas nulls”

et si on est très fort, on ajoute:

-“…et je contrôle ma valeur de retour”

Cela est bien sûr un bon début mais pas suffisant, on doit s’assurer de pas mal de choses comme par exemple si les valeurs passés sont valides: par exemple la division par 0; les valeurs limites; etc…

Et c’est la que PEX entre en jeux: il va analyser votre code de manière intelligente et vous sortir un certains nombre de jeux de paramètres et des valeurs de sorties qui y correspondent. du coup vous pourrez voir rapidement si quelques chose cloche…on va voir ca sur un exemple simple et tenter de mieux comprendre comment PEX marche:

Cas simple; la fameuse division:

   1: public int Division(int a, int b)

   2: {

   3:     return a / b;

   4: }

On execute pex dessus (pour cela, il suffit de faire click droit sur le nom de la methode et faire “run pex”):

On obtient trois jeux de tests:

- le premier nous dit que l’on plante pour une histoire de division par zéro (on s’y attendais)

- le deuxième…bah pas de surprise c’est OK (PEX n’est pas Sylvain Mirouf, il n’est pas capable de comprendre votre code et vous dire que le résultat est ok…c’est a vous de checker)

-  le troisème…pas mal, je pense que beaucoup n’y aurais pas pensé (moi le premier).

Un option sympa dans PEX, est le panneau des suggestions; vous le trouverez ici:

et une fois ouvert, vous obtiendrez le résultat suivant:

Et c’est ici que les choses intéressantes commencent:

PEX vous suggère trois choses pour améliorer votre code:

la premère est de vérifier que b n’est pas nulle en utilisant…Code Contracts!!!!!

si vous double clicker sur la target et que vous valider l’insertion…vous obtenez la modification suivante:

   1: public int Division(int a, int b)

   2: {

   3:     // <pex>

   4:     Contract.Requires(b != 0);

   5:     // </pex>

   6:  

   7:  

   8:     return a / b;

   9: }

PEX analyse donc notre code, trouves des failles et insert le contrat qui va bien…no comment BRAVO.

Mais si on se rappel bien: Harry n’était pas un si chic type que ca…

voyons voir les autres suggestions :

1 on évite les valeurs aux limites:

>>  Contract.Requires(a != int.MinValue);

OK c’est cool

2

!!! il nous suggère de ne pas accepter la valeur –1!

La raison est simple, le jeux de données qui a fait planter la méthode était le suivant : Int.Max et –1, PEX n’est pas capable de dire (et c’est normal) lequel des deux paramètres est mauvais…du coup, il vous suggère d’interdire les deux.

On doit donc être très prudent et faire bien attention lorsque l’on ajoutes les contrats: notre exemple était simple et avec peu de paramètres, imaginez-vous un cas réel avec des objets en paramètres et des dizaines de lignes de code…on va prendre un cas un peu plus complexe:

   1: public int GetValue(List<int> values)

   2:       {

   3:           int retVal = 100000;

   4:           values.ForEach(v => retVal = retVal/v);

   5:           return retVal;

   6:  

   7:       }

PEX a détecter la liste null et deux tests possibles qui aboutissent à une exception (division par zéro)…si on regarde le panneau de suggestion:

PEX perd un peu les pédales:

- les suggestions grisés ne sont pas applicables à notre classe (il propose d’ajouter du code dans le constructeur…mais on en a pas)

- il propose de vérifier que certaines valeurs de la liste ne sont pas nulles

    Contract.Requires(values._items[0] != 0);

et

    Contract.Requires(values._items[1] != 0);

…pas terrible: en plus ca ajoute un possible bug dans notre code dans le cas ou ma liste ne contient qu’un seul élément (mais un deuxième coup de pex vous le fera voir)

Pour conclure: PEX vous permet de mettre le doigt sur les possibles failles de votre code –ce qui  justifie amplement son utilisation!-, il vous suggère également certains contrats pour y remédier pour des cas simple…mais pas pour des cas complexes.