En conclusion

Ceci est un extrait de l'eBook Unit Testing Succinctly de Marc Clifton, gracieusement fourni par Syncfusion..

Les tests unitaires sont également utiles à d'autres fins.

Comme exemples d'utilisation

L'un des avantages des tests unitaires est la création d'une base de code volumineuse illustrant l'utilisation du code. Par exemple, le code que nous avons vu plus tôt:

[Test] public void FilenameParsingTest () Dictionnaire options = CommandLineParser.Parse ("- f foobar"); Assert.That (options.Count == 1, "Le nombre devrait être 1"); Assert.That (options.ContainsKey ("- f"), "Option attendue '-f'"); Assert.That (options ["- f"] == "foobar");

documente un cas d'utilisation valide attendu pour l'analyseur en ligne de commande. Pensez également à écrire des tests unitaires, non seulement pour votre propre code, mais également pour fournir des exemples à des bibliothèques tierces. (Voir les exemples suivants et les choses intéressantes révélées sur la structure Rectangle.)

Test de la boîte noire

Le test de la boîte noire suppose que vous ne connaissez rien des éléments internes de la classe ou du service et vérifiez son comportement strictement à partir des interfaces exposées publiquement. Ceci est souvent nécessaire lorsque le code n'est pas disponible. Par exemple, lorsque nous travaillions avec une société de gestion des enregistrements, nous devions utiliser un service Web fourni par un organisme gouvernemental pour mettre à jour des enregistrements. En écrivant des tests unitaires pour le service Web, nous avons pu prouver que la documentation qui nous avait été fournie n’avait pas entraîné le comportement attendu du service Web..

Vous pouvez également utiliser cette technique lorsque vous travaillez avec du code fourni par différents départements. Par exemple, le groupe de bases de données peut avoir ses propres tests unitaires de boîte blanche; Cependant, vous devez également vérifier que, du point de vue d'une boîte noire, les déclencheurs et les contraintes ont été programmés correctement en inspectant le résultat des transactions à partir de la fonctionnalité qui vous est exposée..

Testez vos hypothèses

Les tests unitaires peuvent être un moyen simple de mettre en place des tests concernant nos hypothèses sur une API. Prenons le System.Drawing.Rectangle structurer et tester des hypothèses apparemment raisonnables sur la mise en œuvre.

Test des hypothèses du constructeur

Il y en a deux Rectangle constructeurs: un ayant Point et Taille paramètres, l’autre ayant les paramètres x, y, width et height. La documentation n'indique pas si la taille (la largeur ou la hauteur) doit être positive, écrivons donc un test pour vérifier que nous pouvons construire un rectangle avec une largeur ou une hauteur négative:

[Méthode de test] public void RectangleNegativeSizeConstructorTest () Rectangle r = new Rectangle (0, 0, -4, -6);

Tout ce que nous faisons ici dans ce test est de vérifier qu'aucune exception n'est générée lorsque nous construisons le rectangle, et en effet, c'est le cas:

Test du constructeur du rectangle

Tester les hypothèses concernant les valeurs de propriété

Maintenant, testons nos hypothèses sur certaines propriétés. Les propriétés Haut, La gauche, Bas, et Droite sont décrits comme (voir
http://msdn.microsoft.com/en-us/library/system.drawing.rectangle.aspx):

Top: Obtient la coordonnée y du bord supérieur de cette structure Rectangle..

Gauche: Obtient la coordonnée x du bord gauche de cette structure Rectangle.

Bottom: obtient la coordonnée y qui correspond à la somme des valeurs des propriétés Y et Height de cette structure Rectangle..

Droite: obtient la coordonnée x qui correspond à la somme des valeurs des propriétés X et Width de cette structure Rectangle..

Ainsi, avec le rectangle précédent, avec une largeur et une hauteur négatives, et donc des coordonnées [(-4, -6), (0, 0)], nous ferions les hypothèses suivantes:

[TestMethod] public void TestLeft () Rectangle r = nouveau Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Left == -4, "Gauche attendue == -4 mais était" + r.Left);  [TestMethod] public void TestTop () Rectangle r = nouveau Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Top == 0, "Top attendu == 0 mais était" + r.Top);  [TestMethod] public void TestRight () Rectangle r = nouveau Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Right == 0, "Droit attendu == 0 mais était" + r.Right);  [TestMethod] public void TestBottom () Rectangle r = nouveau Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Bottom == -6, "Bottom prévu == -6 mais était" + r.Bottom);

Cependant, ce n'est pas le cas:

Test des hypothèses sur les propriétés du rectangle

En fait, la détermination du haut et du bas semble également totalement arbitraire, car j’ai effectué des tests sur exactement les mêmes dimensions de rectangle et observé des résultats différents dans le même temps. Haut et Bas valeurs de propriété.

Tester les hypothèses sur les résultats de la méthode

La documentation MSDN indique que le Rectangle.Intersect méthode:

Renvoie une troisième structure Rectangle qui représente l'intersection de deux autres structures Rectangle..
S'il n'y a pas d'intersection, un rectangle vide est retourné.

Par conséquent, nous pouvons construire un test simple:

[TestMethod] public void TestIntersection () Rectangle r1 = new Rectangle (0, 0, 10, 10); Rectangle r2 = nouveau rectangle (10, 10, 5, 5); Assert.IsFalse (r1.IntersectsWith (r2), "R1 et R2 attendus ne doivent pas se croiser."); Assert.IsTrue (Rectangle.Intersect (r1, r2) == Rectangle.Empty, "On attend un rectangle d'intersection vide.");

Avec le résultat:

Test de nos hypothèses sur les retours de méthode

Cela nous informe que notre attente, basée sur la documentation, est incorrecte.

En conclusion

Le test unitaire est un outil important dans le processus de test. Alors que les tests d'intégration et d'utilisation sont souvent plus centrés sur le client (rapports, jalons, vérification des exigences de haut niveau), les tests unitaires constituent la première ligne de défense du programmeur, de son équipe et de ses chefs. Si utilisé judicieusement (vous ne voulez pas créer des milliers de jolies lumières vertes), cela peut être un moyen rentable de vérifier l'exactitude du code du calcul, de recréer des bogues et de vérifier qu'ils ont été corrigés..

Cependant, de bonnes pratiques de tests unitaires requièrent une approche disciplinée, un engagement du temps et des efforts nécessaires pour mettre en œuvre et gérer les tests et, du point de vue du codeur, des bonnes pratiques de programmation et l'application de décisions architecturales. Ces dernières peuvent se heurter à des contraintes «il suffit de le faire» (ce qui peut être tout à fait légitime) et avoir un impact potentiel sur les performances. En revanche, les pratiques de programmation et les architectures que les tests unitaires obligent à utiliser sont souvent très utiles pour l’ensemble du processus de développement d’applications, réduisant ainsi les coûts et améliorant la maintenabilité, non pas parce que le code est testé par unité, mais parce que le code est mieux écrit. donc c'est ça pouvez être testé à l'unité.

Code