Visual T sharp

Un test unitaire est toujours composé de trois parties :

• Préparation : création des instances nécessaires à l'exécution du test
• Exécution : une seule instruction pour utiliser la déclaration à tester dans un contexte donné
• Vérification : vérification que les résultats attendus (directement ou indirectement) sont bien là.

La partie la plus importante étant Exécution, c'est pour elle que vous écrivez le test.

T# identifie clairement la partie Exécution en faisant commencer l'instruction par le mot clé runtest. La préparation est donc naturellement tout ce qui se trouve avant runtest, et la vérification après runtest.

La partie vérification s'assure que tous les effets (par exemple : retour de fonction, changements des paramètres, modification d'instance, de déclarations statiques, de fichiers, bases de données...) escompté lors de l'utilisation de la déclaration se sont bien effectués comme prévu.

T# n'offre qu'un seul mot-clé pour cela : assert. Le message est automatiquement généré à partir du code source. Ainsi, si le test précédent échoue (si la fonction Ajouter est mal codée en retournant toujours 0), le test échouera avec le message d'erreur suivant : "Expected: somme == 3 but was: 0 == 3". Il est ainsi très rapide de déterminer que la somme vaut 0, mais que l'on s'attendait à 3. Cette façon de générer le message d'erreur le rend plus proche du code source (donc plus facile de faire le lien avec le code quand l'erreur apparait) et décompose les différentes valeurs impliquées (si plusieurs variables étaient impliquées, on saurait alors la valeur de chacune des variables et non pas de l'expression finale), rendant le déboguage beaucoup plus facile.

De plus, les conversions naturelles du langage de programmation sont utilisées (somme est un double, 3 est un entier). Ainsi, pas de problème pour comparer les deux contrairement à Visual Studio Team Test pour lequel vous devez écrire : Assert.AreEqual(3.0, somme); pour faire la même vérification!

La forme la plus simple de contexte est le context de chaque test. C'est celle utilisée par défaut.

Les tests sont exécutés, mais pas directement. Le contexte, introduit par une méthode déclarée par le mot clé testcontext, est appelée pour chaque test. Le mot clé runtest indique l'endroit où le test doit réellement s'exécuter.

Ainsi, dans notre exemple, nous voulons créer l'instance avec une seule ligne de code, mais il faut créer une instance pour chaque test :

testclass for Produit
{
  Produit prod;
  testcontext
  {
    prod = new Produit("T#", 123);
    runtest;
  }
  test Prix set // valeur minimale
  {
    assert prod.Prix != 0;
    runtest prod.Prix = 0;
    assert prod.Prix == 0;
  }
  test Prix set // valeur valide quelconque
  {
    assert prod.Prix != 12;
    runtest prod.Prix = 12;
    assert prod.Prix == 12;
  }
}

En T#, le contexte se situe à trois niveaux :

1. test : le code du contexte est effectué pour chaque test. Le test lui-même étant effectué à l'appel de runtest dans le contexte. Contexte par défaut.
2. testclass : le code du contexte est effectué pour la classe de test. Les tests de la classe de test étant effectués à l'appel de runtest dans le contexte.
3. testassembly : le code du contexte est effectué pour l'ensemble des classes de test de l'assemblage. Les tests étant effectué à l'appel de runtest dans le contexte.

Dans cet exemple, les tests seront exécutés deux fois, sans avoir à les écrire deux fois :

1. pour une connexion vers une base de données SQL Server.
2. pour une connexion vers une base de données Oracle.

testclass
{
  IDbConnection connexion;
  testcontext
  {
    testclass
    {
      connexion = new SQLConnection(...);
      runtest;
      connexion = new OracleConnection(...);
      runtest;
    }
  }
  ...
}

En fait, ce qui suit le mot clé when est un cas parmi plusieurs fonctionnant ensemble, décrits par un critère. Dans notre exemple, le critère est MinIncluded qui combine deux cas normaux (IsAboveMin et IsMin) et un cas d'erreur (BelowMinCase).

Il suffit donc d'identifier qu'un prix de produit a une valeur minimale (0) pour identifier qu'il faut tester selon le critère MinIncluded. Ce critère définissant trois cas, il va falloir écrire 3 tests pour tester cette propriété, un pour chaque cas défini dans le critère.

Pour l'instant, nous n'avons que deux cas définis (les cas normaux). Dès la compilation, T# indique les cas manquants : MinIncludedCriteria.BelowMinCase.

En réalité, après un when, une expression de cas est utilisée. Cette expression peut être un cas simple d'un critère ou une combinaison de critères.

Les opérateurs suivants existent :

• && (et logique) : combine toutes les possibilités entre deux critères, sachant que seules les cas normaux sont combinables, les cas d'erreur devant être testés séparément.
• || (ou logique) : regroupe deux cas dans un même test. A priori ce n'est pas une bonne idée, mais cela peut être nécessaire d'exprimer la situation d'un même test exécutant plusieurs tests avec paramètres.
• => (implication) : combine le cas de gauche avec les différents cas du critère de droite. Utile lorsque toutes les combinaisons ne sont pas logiques.

Enfin, lorsqu'un cas n'a pas de sens, il est possible de demander à ne pas le prendre en compte en déclarant le cas !when. Dans ce cas, le test ne doit pas avoir de code, donc pas d'accolades, seulement un point-virgule.

Il existe déjà beaucoup de critères dans la bibliothèque de T#, mais cela ne peut couvrir tout vos besoins. Il est alors très facile de créer les vôtres.

Un critère est comme un type énuméré, mais défini par le mot clé criteria et non pas enum. Les cas d'erreur sont repérés en ajoutant l'attribut [Error] au cas en question.

La convention veut que :

1. le nom du critère se termine par "Criteria", même s'il n'est pas nécessaire de l'ajouter lors de l'utilisation (comme "Attribute" pour les attributs)
2. un cas normal se présente avec un 'Is' ou 'Has'
3. un cas d'erreur se termine par 'Case'

Ainsi, la déclaration de MinIncludedCriteria est la suivante :

public criteria MinIncludedCriteria
{
  [Error]
  BelowMinCase,
  IsMin,
  IsAboveMin,
}

T# vérifie les exceptions comme toute autre vérification :

• en une seule ligne
• avec le mot assert, mais suivi de thrown et du nom de l'exception

Les avantages sont les suivants :

1. garantie que l'exception est bien dans la partie runtest (donc dans le code d'affaires) et non pas avant (préparation) ou après (vérification)!
2. ajout possible d'autres assertions pour garantir que rien d'inattendu n'a été fait avant l'exception (comme changer le prix avant de déclencher l'exception par exemple!)

Ainsi, dans l'exemple précédent, il est nécessaire de tester le cas où le prix affecté au produit est négatif. Comme cela n'a pas de sens, la propriété devrait générer une exception ArgumentOutOfRangeException. Testez-le ainsi :

testclass for Produit
{
  Produit prod;
  testcontext
  {
    prod = new Produit("T#", 123);
    runtest;
  }
  test Prix set
    when MinIncluded.BelowMinCase
  {
    runtest prod.Prix = -12;
    assert thrown ArgumentOutOfRangeException;
    assert prod.Prix == 123; // Le prix n'a pas changé
  }
  ...
}

En fait, cela va simplement vérifier que l'exception est bien générée dans l'instruction runtest. Ce qui est déjà bien. Cependant, il serait bon de pouvoir valider le message d'erreur par exemple.

L'instruction assert thrown <type-exception> peut aussi être suivi d'un nom de variable, comme dans une instruction catch, et d'un bloc de code pour faire autant de vérifications voulues lorsque l'exception est déclenchée. Accédez alors normalement à cette variable pour vérifier tout ce que vous voulez.

testclass for Produit
{
  Produit prod;
  testcontext
  {
    prod = new Produit("T#", 123);
    runtest;
  }
  test Prix set
    when MinIncluded.BelowMinCase
  {
    runtest prod.Prix = -12;
    assert thrown ArgumentOutOfRangeException e
    {
      assert e.Message == "Un prix ne peut être négatif!";
    }
    assert prod.Prix == 123; // Le prix n'a pas changé
  }
  ...
}

La forme la plus simple de vérification relative est celle de la constance d'une expression.

T# offre une nouvelle forme de l'instruction assert : assert !changed <expression>

L'expression sera évalué avant l'instruction runtest, et sa valeur conservée, pour être de comparée par égalité au moment du assert en question.

Ainsi, dans notre exemple, plutôt que de vérifier que le prix du produit est bien 123, il serait préférable de vérifier que le prix n'a pas changé :

testclass for Produit
{
  Produit prod;
  testcontext
  {
    prod = new Produit("T#", 123);
    runtest;
  }
  test Prix set
    when MinIncluded.BelowMinCase
  {
    runtest prod.Prix = -12;
    assert thrown ArgumentOutOfRangeException e
    {
      assert e.Message == "Un prix ne peut être négatif!";
    }
    assert !changed prod.Prix;
  }
  ...
}

La forme la plus sophistiquée de vérification relative est celle de la constance d'un objet. En effet, qui dit que notre code d'affaires n'a pas modifié l'objet avant que de lancer l'exception?

Dans l'instruction assert !changed <expression>, l'expression peut référencer un objet et se terminer par :

1. .* : indique au compilateur T# de vérifier chacune des propriétés publique de l'objet en question. Donc que l'objet n'a pas changé en apparence.
2. .-* : indique au compilateur T# de vérifier chacune des variables (quel que soit le niveau d'encapsulation) de l'objet en question. Donc que l'objet n'a vraiment pas changé.

Note : l'opérateur .- est semblable à l'opérateur . si ce n'est qu'il accède à n'importe quelle déclaration, privée ou non.

Ainsi, dans notre exemple, plutôt que de vérifier que le prix du produit n'a pas changé, il serait préférable de vérifier que l'objet prod n'a pas changé :

testclass for Produit
{
  Produit prod;
  testcontext
  {
    prod = new Produit("T#", 123);
    runtest;
  }
  test Prix set
    when MinIncluded.BelowMinCase
  {
    runtest prod.Prix = -12;
    assert thrown ArgumentOutOfRangeException e
    {
      assert e.Message == "Un prix ne peut être négatif!";
    }
    assert !changed prod.-*; // le produit n'a pas changé
  }
  ...
}

Sur le même principe, vérifiez qu'un changement a été apporté par une assertion relative.

Une assertion relative de changement s'effectue avec l'instruction assert changed <affectation>.

L'affectation se présente sous 3 formes :

1. élément = expression
2. élément op= expression : ainsi, élément += 1 est équivalent à élément = élément + 1
3. élément++ ou element-- : ainsi, élément++ est équivalent à élément += 1 donc à élément = élément + 1

La partie de droite est évaluée avant l'instruction runtest, et conservée, pour être comparée par égalité à la partie de gauche sur le assert correspondant. Ainsi, assert changed élément++ n'incrémente pas élément, mais vérifie que la valeur d'élément ajoutée de 1 avant l'instruction runtest est égale à la valeur d'élément après l'instruction runtest. Ou tout simplement, que l'instruction runtest à bien fait augmenter de 1 la valeur d'élément. Ainsi, c'est l'expression équivalente à une affectation comme précisé, mais seulement des accès en lecture sont effectués. Il est donc possible de l'utiliser avec des propriétés en lecture seule.

Si nous reprenons notre exemple avec notre classe Produit, on pourrait ajouter une classe Inventaire (une collection de Produit)qui aurait donc une méthode Add(Produit) et une propriété Count.

Le test de cette méthode serait :

testclass for Inventaire
{
  Inventaire inventaire;
  testcontext
  {
    inventaire = new Inventaire();
    runtest;
  }
  test Add( Produit p )
  {
    Product produit = new Product( "T#", 123 );
    runtest inventaire.Add( produit );
    assert changed inventaire.Count++; // un produit a été ajouté
    assert inventaire[ inventaire.Count - 1 ] == produit; // le produit a été ajouté en dernier
  }
  ...
}

La forme la plus simple est la vérification du non déclenchement d'un événement.

En T#, la vérification du non-déclenchement d'un événement s'effectue comme toujours en une ligne de code : assert !raised <événement>;

Le compilateur T# génère une variable d'instance et une méthode compatible avec la signature de l'événement. Dans le test, la variable est initialisée à faux, la méthode est enregistrée (+=) auprès de l'événement avant l'instruction runtest et désenregistrée (-=) après l'instruction runtest. La méthode générée va réinitialiser la variable à vrai. L'instruction runtest !raised va vérifier que la variable est toujours à faux.

En supposant que notre classe Produit supporte l'interface INotifyPropertyChanged, nous devrions avoir le test suivant :

testclass for Produit
{
  Produit prod;
  testcontext
  {
    prod = new Produit("T#", 123);
    runtest;
  }
  test Prix set
    when MinIncluded.IsAboveMin && NotifyPropertyChanged.HasSubscribersSetSameValue
  {
    runtest prod.Prix = prod.Prix;
    assert !changed prod.-*;
    assert !raised prod.PropertyChanged;
  }
  ...
}

La forme la plus simple de vérification du déclenchement d'un événement vérifie seulement que l'événement est déclenché.

Comme toujours, T# le vérifie en une seule ligne de code : assert raised <événement>;

Le compilateur T# génère exactement les mêmes choses que pour assert !changed, mais vérifie que la variable est à vrai.

Ainsi, dans notre exemple, nous devrions avoir :

testclass for Produit
{
  Produit prod;
  testcontext
  {
    prod = new Produit("T#", 123);
    runtest;
  }
  test Prix set
    when MinIncluded.IsAboveMin && NotifyPropertyChanged.HasSubscribersSetOtherValue
  {
    assert prod.Prix != 12;
    runtest prod.Prix = 12;
    assert prod.Prix == 12;
    assert raised prod.PropertyChanged;
  }
  ...
}

L'inconvénient de procéder comme dans le chapitre précédent, c'est que cela prouve simplement que l'événement s'est déclenché, pas que :

1. les paramètres associés sont correctement passés. Selon notre exemple, le sender est-il bien le produit modifié? Le second paramètre fait-il bien référence à la bonne propriété?
2. l'état de l'objet est correct au moment de l'événement. Selon notre exemple, le produit est-il bien déjà avec sa nouvelle valeur de prix quand l'événement est déclenché?

Une forme beaucoup plus sophistiquée de test des événements existe : assert raised <événement>(<paramètres>) { <vérifications> } Où :

• <paramètre> représente les paramètres correspondant à la signature de l'événement.
• <vérifications> représente les assertions à vérifier dans la méthode réagissant à l'événement.

Ainsi, le même tests que dans le chapitre précédent, mais complet serait :

testclass for Produit
{
  Produit prod;
  testcontext
  {
    prod = new Produit("T#", 123);
    runtest;
  }
  test Prix set
    when MinIncluded.IsAboveMin && NotifyPropertyChanged.HasSubscribersSetOtherValue
  {
    assert prod.Prix != 12;
    runtest prod.Prix = 12;
    assert prod.Prix == 12;
    assert raised prod.PropertyChanged( object sender, PropertyChangedEventArgs e )
    {
      assert sender == prod;
      assert e.PropertyName == "Prix";
      assert prod.Price == 12;
    }
  }
  ...
}