Faire des tests unitaires avec Visual Studio 2010

• Non-régression entre les « commit » grâce à l'intégration continue

En effet, une modification trop vite faite et/ou mal testée pour un besoin spécifique peut répondre au nouveau besoin, mais est-ce que les anciens sont toujours satisfaits ? Et comment le savoir, à moins de replonger dans la documentation ? Ou bien faire Shift+F12 pour savoir que la méthode est appelée par dix autres ?

• Garder la confiance entre les développeurs et la maintenabilité

Lors d'un travail en équipe, les interventions sur un même fichier ou classe sont monnaie courante. Si un « assembly » doit être modifié/remplacé pour une modification ou satisfaction d'un nouveau besoin, il est nécessaire d'être sûr que les fonctionnalités actuelles soient toujours opérationnelles après la modification. Puis vérifier, sur la machine de « Build » grâce à l'intégration continue, que le « merge » éventuel n'entraîne pas de régression.

Les tests unitaires sont un moyen de le garantir.

• Validation couche après couche d'une architecture :

Cette approche est recommandée pour faciliter les tests sur les développements de la couche en cours plutôt que sur les N-1 précédentes couches.

• Faciliter le débogage : tout ce qui est déjà testé par les TU n'est plus à tester lors de la recherche d'un bogue, la recherche est ainsi écourtée.

Les blocs softwares suffisamment testés permettent de débusquer plus vite la faille, plutôt que de tout reprendre en pas-à-pas depuis le début (par exemple, le clic utilisateur). Même si vous ne pouvez pas faire de pas-à-pas, des TU d'échecs permettent de valider des hypothèses.

• Connaître les performances

Comment prouver de manière confortable que tel « use case » répond à la disponibilité, à une charge maximale, et/ou à un temps demandé ? Par des tests unitaires ! Pour chaque dimension de performance demandée, un test unitaire vous permettra d'être sûr d'avoir atteint l'objectif, d'avoir une trace du résultat du test et comment vous l'avez fait.

« Le test unitaire est un procédé permettant de s'assurer du fonctionnement correct d'une partie déterminée d'un logicielou d'une portion d'un programme (appelée « unité » ou « module »). »

• Son taux de couverture pour un ensemble de tests.
• Sa réutilisabilité : si oui, y a-t-il des difficultés à le réutiliser ?
• Contexte de départ, contexte d'arrivée (par exemple : démarrer un Windows Service, faire le test unitaire puis arrêter le Windows Service).
• Synchronisme : Synchrone/Asynchrone.

• Sa réussite.
• Son temps d'exécution moyen.

• Son Environnement d'exécution : DEV, REC, PREX.

  • MTA/STA.
  • MonoCœur/MultiCœurs.

Elles sont au nombre de quatre, mais les deux premières ont en commun un même ensemble de fonctionnalités :

• afficher un ensemble de tests ;
• les trier ;
• modifier les colonnes ;
• aider à la recherche d'un test.

II-B-1-a. Test View▲

Pour trouver, fabriquez une sélection de test.

II-B-1-b. Test List Editor▲

Qui sert principalement à afficher des ensembles de tests, à en créer, à préparer une sélection et à lancer une session sur cette sélection.

II-B-1-c. Tests Results▲

Pour afficher, lancer/relancer en « Release/Debug » les tests unitaires et connaître leurs états.

x

À noter : vous pouvez même relancer la session de test sans la recompilation. Le gain de temps et la liberté de le faire sont appréciables milkoseck 2014-10-30T09:18:34Deux sujets >> sont appréciables.:

• si un test avait échoué là où une ressource indépendante/extérieure était indisponible ;
• si vous étiez en train de retoucher du code pendant une longue session de test, que vous ne pouvez déployer maintenant sans une recompilation.

II-B-1-d. Test Runs▲

Vous servira surtout si vous pouvez lancer plusieurs sessions de tests. Vous pourrez alors vous y connecter pour suivre le déroulement et annuler une session de tests.

Voici un aperçu d'une classe de test dans Visual Studio :

Une classe de test unitaire se reconnaît grâce à ses attributs. Un attribut est une classe qui fournit des informations au compilateur et est notée entre crochets : [Attribut()]. Le nom de la méthode ou de la classe sous un attribut importe peu, seul l'attribut permet de faire fonctionner les tests. Le fait de mettre un nom de fonction compréhensible est un plus pour la lecture de la classe.

II-B-2-a. Les Attributs▲

[TestMethod()]
[ExpectedException(typeof(Exception))]
public void Test()
{
}

Les tests unitaires ont leur propre fichier de configuration, indépendant des célèbres WebConfig et App.Config. Le réglage par défaut suffit à la plupart des tests unitaires, mais si vous voulez, vous pourrez y configurer :

• le déploiement de fichiers ou répertoires spécifique aux tests, car il faut savoir que pour chaque session de tests, « MSTest » va générer un répertoire d'exécution indépendant du répertoire « Debug » ou « Release ». Ce qui de fait rend un peu plus chaque session de test unique si vous avez par exemple manipulé des fichiers.
• le type d'host : Default ou Asp.net ? 32 ou 64 bits ?
• le « Timeout » au niveau solution : vous pouvez y configurer la possibilité d'annuler toute une session de tests si la session dépasse un temps demandé. Et marquer comme échoué un test qui a duré trop longtemps.
• le lancement de scripts : au début et à la fin de la session de tests.

II-B-3-a. Les différentes manières de créer un test unitaire▲

II-B-3-b. Spécificités de l'outil▲

II-B-3-b-i. Les tests introspectifs▲

Avez-vous un besoin de tester des méthodes privées ? MsTest vous génère de toute façon le squelette de test sans configuration ou paramétrage supplémentaire. Comment fait-il ? MsTest fait de la réflexion pour « décapsuler » temporairement l'encapsulation de la classe. Vous n'avez donc rien à changer sur votre code métier, et ce « décapsuleur » aussi appelé “accessor” fonctionne sur toute la classe.

II-B-3-b-ii. MultiCœur▲

Le fonctionnement en Monocœur est le réglage par défaut de MsTest. Chaque test est exécuté par un cœur. Cela va donc à une certaine vitesse… Quand on modifie le réglage en Multicœur, on peut dérouler au maximum autant de tests en parallèle que la machine a de cœur de processeur, comme quatre sur un Core-i7.

Comparaison du temps total de test : oui, cela va bien quatre fois plus vite, j'ai hâte de lancer mes tests sur notre machine de « Build » qui a 12 cœurs… Toutefois, si vous utilisez un worker de test par cœur, attention à l'utilisation des ressources en simultanée par vos tests.

Voici l'astuce, il faut ouvrir  le fichier *.TestSettings avec un éditeur XML et changer l'attribut « parallelTestCount » au nombre de cœurs que vous voulez utiliser.

II-B-3-b-iii. Gestion Du MTA▲

Définition du MTA : Multi-Threaded Appartment.

C'est l'utilisation de plusieurs threads d'égal à égal à l'intérieur d'un test, et non un « MainThread », plus des « foreground Thread » et « BackGround Thread ».

Voir la figure ci-dessous :

Pour utiliser WaitHandle.WaitAll(WaitHandle[]), le MTA doit être configuré. Cette méthode vous permettra de lancer plusieurs threads d'un coup au travail dans votre test et les attendre en fin de méthode en une seule ligne. Cette dimension est d'autant plus importante si vous voulez faire des tests impliquant des objets COM. Le MTA vous servira pour faire des tests de « Thread-Safe ».

Par exemple :

• tester l'utilisation concurrentielle d'une méthode accédant à une ressource critique ;
• une « webmethod » en WCF, par exemple ;
• voir l'évolution des performances de chaque accès par thread en fonction du nombre d'accès concurrentiels.

À savoir : les performances des tests baissent quand le MTA est activé, donc à n'activer qu'en cas de besoin.

Voici le secret : vous ouvrez le fichier *.TestSettings avec un éditeur XML et ajoutez la balise « Execution Thread » comme indiqué ci-dessous :

 

Sélectionnez

<TestSettings>
  <Execution>
    <!-- ... -->
    <ExecutionThread apartmentState="MTA" />
  </Execution>
</TestSettings>

II-B-3-b-iv. DataDriven Tests : DDT▲

Littéralement en Français : tests pilotés par les données.

Le principe consiste à industrialiser les paramètres possibles d'un même test unitaire. Une fois le TU écris, on attache une data source XML, CSV, Database. Lors de l'exécution du TU, la méthode de test sera appelée avec en paramètre, l'une des lignes de la data source. Un exemple pour illustrer ce genre de test : la multiplication.

J'ai trouvé un intérêt pratique à utiliser le DDT en mission.

Une fois que mon serveur de calcul WCF était prêt, je voulais voir s'il acceptait toujours des calculs demandés dans le passé.

Aussi ai-je demandé un dump de la base de production sur la base de recette pour lancer un test massif utilisant des paramètres de calcul passés.

J'ai pu me rendre compte à la fois des performances de calculs sur chaque calcul, faire une moyenne du temps des calculs, et … me poser la question pourquoi certains calculs plantaient… mais voir aussi que mon serveur survivait au plantage des calculs quelle qu'en soit la raison.

II-B-3-b-iv-I. Les tests génériques :▲

Comment ça les tests génériques ? Vous voulez dire tester les méthodes avec des <T>?

Oui, ces méthodes peuvent être testées aussi.

Prenons un exemple :

Imaginez que vous réimplémentez la liste List<T>, vous la nommez GenericList<T>.

Et elle implémente l'interface suivante :

Pour une première approche, on ne pose pas de contraintes sur le <T>.

Quand on utilise la génération automatique de tests sur la méthode AddHead(), voici ce que nous sort Visual Studio :

Encore une fois, il nous mâche plutôt bien le travail, il génère ainsi la testMethod(), mais aussi une méthode générique intrigante avec Helper à la fin, qui utilise default et est appelée avec GenericParameterHelper.

Bon d'abord, permettez-moi de présenter GenericParameterHelper, car ce type n'existe pas dans les librairies classiques.

Il appartient à l'« Assembly » : Microsoft.VisualStudio.TestTools.UnitTesting.

C'est une classe qui nous aide à tester des types génériques en nous permettant de transmettre des arguments de types non spécifiques. Ainsi, si vous hésitez encore sur les contraintes de type à appliquer sur vos méthodes génériques, vos tests eux, seront déjà prêts.

Mais voici l'explication du pourquoi cette méthode additionnelle :

Puisque les méthodes génériques fonctionnent avec plusieurs types différents, pourquoi réécrire le même test pour la même méthode, même si seuls les types diffèrent ?

Illustration par l'exemple :

J'ai enrichi un petit peu la méthode d'aide en appelant plusieurs fois le « AddHead » et surtout en vérifiant que les éléments insérés étaient présents avec l'Enumerator.

Mais vous aurez surtout remarqué que j'appelle la même méthode plusieurs fois avec des types différents : du temps a encore été gagné.

Tout d'abord son Intégration à Visual Studio, le temps de mise en place est donc réduit, et le temps de passage entre un test et un codage classique réduit. Pour une intégration similaire avec « NUnit », il faut sortir 160 $ au moins.

Pour l'exécution de chaque méthode de test, un thread est créé, un répertoire d'exécution est créé ; ce qui garantit une bonne isolation entre chaque session de test et permet d'utiliser intelligemment tous les cœurs des processeurs.

• Génération automatique des Skeletons : il génère automatiquement un Skeleton compilable et prêt à l'emploi directement à partir d'un « assembly » ou d'une méthode, moins de code à écrire donc.
• Maîtrise sur trois niveaux du contexte(Vs Xunit) : en effet, vous pouvez paramétrer les contextes de fin et d'arrivée au niveau tests, chaque classe, et même « Assembly ».
• Les l istes ordonnées de t est s .
• Les t est s introspectifs.
• Supporte le MTA.
• « Timeout » au niveau solution : le TimeOut peut être appliqué à un « Assembly » ou à une méthode.
• Méthodes génériques : c'est seul outil de test que je connais qui peut faire ce genre de test, et ce, alors que le framework 4.0 est sorti depuis 2 ans.

L'exploitation des résultats (le fichier de résultat est un XML) (-Test Unitaires application MVC : http://msdn.microsoft.com/fr-fr/library/ff936235.aspx).

-Le séquençage de tests : pour simuler un comportement utilisateur sur l'interface bluetooth de la librairie que je codais, j'ai pu énumérer facilement plusieurs cas métiers et prouver à mon chef l'exhaustivité de ceux-ci, puisqu'il y avait accès aussi.

-La possibilité d'écrire les tests juste avec la nouvelle interface du service à implémenter pour les tierces parties. J'avais donc mes tests prêts avant le codage lui-même.

-Le temps limite d'exécution : en effet, les tests duraient souvent plusieurs minutes, et il était nécessaire de préférer faire échouer toute la session de tests si une ressource venait à manquer, plutôt que d'attendre inutilement.

-Automatisation de procédure de test Longue.

Jugez plutôt : allumer l'interface bluetooth, lister les téléphones disponibles, se connecter à un téléphone, télécharger tout le contactbook, déconnecter, recommencer avec l'autre… et éteindre l'interface. Et le temps pour chaque téléphone s'il vous plaît.

-Le chronométrage était essentiel pour certains « uses cases », mon client avait un engagement contractuel sur le temps mis pour récupérer des données dans le contactBook. Je pouvais ainsi me rendre compte plus facilement du gain de temps en modifiant un seul des blocs de code nécessaire à cette demande et en relançant les tests.

-Le séquençage de tests m'a permis de simuler un utilisateur qui connecte son téléphone en bluetooth, passe un appel, raccroche.

Tout cela juste en réutilisant des tests unitaires existants. L'historique des tests me permettait de me rendre compte de l'évolution des performances. Les séances de tests peuvent coûter du temps en exécution, sauf que je faisais autre chose entre temps et réagissait plus vite en cas d'erreur => car un clic sur l'échec du test mène droit à la méthode de test.

« L'écriture des tests a eu un coût certain, mais cela a permis de se poser les bonnes questions à propos de la compréhension du fonctionnel et de vérifier si les cas métiers ont bien été tous prévus.

La génération de code a eu un gain de temps de développement non négligeable sur l'écriture des tests comparé à ce qui avait été tenté avec NUnit. La méthode des tests unitaires par MsTest a eu un succès suffisamment grand dans l'équipe d'Alexandre pour que les autres équipes s'y intéressent et accélèrent leur passage à Visual Studio 2008 pour en bénéficier. »

Recherche de la performance, souci récurrent d'accès concurrentiels, mise en cache de données grande en taille (en cumulé >8 Go, ~5 Mo en moyenne par unité de cache). Pérennité paramétrable de la validité des calculs. Mise en file du calcul (un calcul dure 15 minutes en moyenne), engagement chiffré sur la disponibilité du service.

• Système de mise en cache de données volumineuses avec accès concurrentiels, réglage du délai de validité du cache.
• Système de priorisation d'accès aux caches en lecture ou écriture selon les droits configurés des clients accédants.

• L'utilisation du MTA
• Le Chronométrage
• Les Stress Tests

Pour vérifier l'aspect « thread-safe » d'accès au cache.

-Recherche des limites du service par des tests unitaires appelant d'autres tests unitaires en boucle, et multithread pour simuler une demande massive de calcul.

« Les découvertes de bogues ont été bien plus précoces, donc plus faciles à corriger, car les tests ont été faits en parallèle du développement de la couche testée. »

« La recherche du même bogue en production aurait été quasi impossible, car le nombre de couches logicielles à tester aurait été beaucoup plus élevé qu'en période de tests unitaires ».

Au moment de bâtir une architecture d'accès « thread-safe » niveau après niveau, j'ai choisi de valider soigneusement, à l'aide des tests unitaires, la couche en cours, avant d'attaquer la suivante. Ainsi, en cas de bogue, je cherchais d'abord à remettre en cause le niveau en cours de développement. La connaissance des performances a été essentielle dans cette mission, car le développement s'est fait en deux lots : tout d'abord une mise en cache sur disque dur, puis une priorisation des flux de demande de calcul en fonction de la charge logicielle et des règles métier. Il était donc essentiel de bien connaître toutes les caractéristiques du premier lot fini avant d'attaquer le deuxième.

• Combien ça coûte ?

  

• Et si le chef peut sortir le chéquier…

  

• Code metrics : dans notre cas, permet de cerner rapidement les codes les plus complexes et les plus critiques à tester.

• Code Coverage : donne une idée de la couverture de vos tests sur votre code.
• Database Unit Test : vérifie le comportement d'objets en base comme les procédures stockées.
• Test Impact Analysis : savoir que la modification d'un code métier aura un impact sur vos tests.
• Test Data Generation : générateur personnalisé pour remplir vos tables afin de mener vos tests.
• Web Testing : le must du must, vous manipulez votre site Web comme un utilisateur et celui-ci enregistre et rejoue à volonté votre scénario qui est modifiable et extensible. Attention toutefois de ne pas chercher à manipuler des types trop complexes sur la page Web, des retours d'expérience ont montré que cela ne fonctionnait plus au-delà d'une certaine complexité.