Faire des Tests Unitaires avec Visual Studio 2010

Tests Unitaires Sous Visual Studio 2010 Professional

Visual Studio 2010

Vous avez entendu parler des tests unitaires, vous voulez en faire, mais il vous manque le comment ?

D’accord pour faire des tests unitaires, mais sans écrire des milliers de lignes de codes, sans réinstaller autre chose ?

Visual Studio, votre IDE favori a déjà la solution.

Tout d’abord, nous allons rappeler des notions de bases sur les Tests unitaires, puis présenter l’outil, ce qu’il offre. Puis on va le comparer avec la concurrence.

L’article s’ouvrira enfin sur l’opportunité de passer à une licence supérieure avec les coûts associés et enfin les apports du passage à Visual Studio 2012 en ce qui concerne les TU.

Je vous proposerai alors des retours d’expériences sur l’usage que j’ai pu en faire lors de mes missions.

Périmètre :

Visual Studio 2010 Professional.

On parlera essentiellement de l’outil, moins de la manière d’écrire des tests Unitaires.

Pourquoi Tester ?

Les Raisons liés au Projet :

Pour des raisons politiques : l’ordre vient d’en haut (du N+2, par exemple), on n’en connaît pas forcément les raisons.

Risque de pertes financières : un distributeur de produits financiers qui s’arrête même quelques secondes peut potentiellement entraîner des conséquences pécuniaires.

Risque létal : un automate embarqué dans un avion

Produit grand Public : pas d’écran bleu.

Études : pour valider un POC.

Pour l’équipe :

  • 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 se replonger dans la documentation ? Ou bien faire Shift+F12 pour savoir que la méthode est appelée par 10 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 unitaire sont un moyen de le garantir.

Pour vous-mêmes :

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

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 ne sont pas plus à tester lors de la recherche d’un bug, 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). Ou 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

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.

Ce qu’est un Test unitaire :

Définition :

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

Ses caractéristiques à la définition :

-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.

Ses caractéristiques à l’exécution :

Sa réussite.
-Son temps d’exécution moyen.
-Son Environnement d’exécution : DEV, REC, PREX.
            MTA/STA.
            Mono-Cœur/Multi-Cœurs.

Présentation de MS Test

Historique

L’infrastructure xUnit a été introduite comme concept de base de l’eXtreme Programming en 1998. Cette méthode définissait un mécanisme efficace pour aider les développeurs à créer des tests unitaires automatisés performants et structurés lors de leurs activités courantes de développement. Depuis lors, cette infrastructure a évolué en véritable norme pour les infrastructures de tests unitaires automatisés. Un des problèmes spécifiques de la mise en place de tests unitaires automatisés et structurés vient de la quantité de code nécessaire pour l’accomplissement de ces tâches. (Il faut beaucoup de code pour tester votre code !) Le concept de générateur de code, simplement défini comme « logiciel qui crée du logiciel », s’impose de plus en plus au sein des bureaux de développement informatique des entreprises.

Concept de l’infrastructure xUnit Équivalent VS 2005 (voir les attributs ci-dessous) Description
Test TestMethod Ce sont vos tests. Fournit la logique pour vérifier que le résultat est bien celui prévu et vous informe si le résultat n’est pas atteint. Imaginez qu’il s’agit de votre « méthode ».
Contexte du test (Fixture) TestClass Regroupement logique d’un à plusieurs tests. Imaginez qu’il s’agit de votre « classe ».
Suite de tests Test List ** Regroupement logique d’un à plusieurs contextes de test. Imaginez qu’il s’agit de votre « bibliothèque de classes ». Remarque : Cette liste n’a pas besoin d’attribut.
Testeur Infrastructure de tests unitaires VS 2005 VSTS GUI/Application de console chargée de découvrir, d’exécuter et de présenter les résultats des tests. Dans cet article, Visual Studio 2005 Team System servira de testeur.

Fonctionnement de l’outil

Les vues :

Elles sont au nombre de 4, 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.

-Test View :

Pour trouver, fabriquer une sélection de Test. TestView

-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. TestEditor

-Tests Results :

Pour afficher, lancer/Relancer en Release/Debug les Tests unitaires et connaître leurs états.Run Tests A noter : vous pouvez même relancer la Session de Test sans la recompilation. Le gain de temps et la liberté de le faire est appréciable : -si un test avait échoué là où une ressource indépendante/Extérieure était indisponible. -si vous étiez entrain de retoucher du code pendant une longue session de test, que vous ne pouvez déployer maintenant sans une recompilation.

-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 test. test Runs

Anatomie d’un Test Unitaire

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

Additional Test Attirbutes

Une classe de test unitaire se reconnait 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.

Les Attributs
TestClass

Cet attribut indique que la classe est une classe contenant des tests. Elle sera donc prise en compte lors de l’exploration lors de la rechercher des TU dans la solution, et lors de l’exécution des tests.

ClassInitialize

La méthode taggée avec cet attribut sera appelée avant le premier test de la classe. Cela permet de créer des informations qui peuvent être reprises dans les tests. Par exemple : on peut créer des fichiers sur le disque nécessaires aux tests.

ClassCleanup

Cet attribut indique que la méthode sera appelée après l’exécution du dernier test de la classe. Par exemple : on peut supprimer les fichiers créés sur le disque.

TestInitialize

Méthode qui sera exécutée avant chaque test présent dans la même classe. Différent de “ClassInitialize”, il est exécuté avant chacun des tests lancés, seul ou en groupe. Donc si par exemple, on doit initialiser des listes, instances et champs de base de données, on pourrait le faire dans cette méthode.

TestCleanup

Méthode qui sera exécutée après la fin de chacun des tests exécutés appartenant à la même classe. Si on roule plusieurs tests en groupe, cette méthode sera exécutée à la fin de chaque test. Donc par exemple, si on veut remettre un champ de base de données à sa valeur initiale, car on l’a modifié durant le test, on pourrait le faire dans cette méthode.

Comme vous pouvez le constater, il est possible de gérer finement vos tests en leur créant un environnement, que ce soit pour la classe complète (ClassInitialize et ClassCleanup) ou au niveau des tests eux-mêmes (TestInitialize et TestCleanup).

TestMethod

Voici l’attribut qui sera le plus utilisé. Il définit un test. Une bonne pratique de test est la méthode des trois A (Arrange/Act/Assert) : Chaque méthode que la classe Assert permet de tester un aspect du test unitaire. Si une vérification échoue, une exception spécifique est levée. Ceci signifie que le test a échoué. Chaque test unitaire est traité séparément, les autres tests vont donc continuer. Chaque méthode a une version prenant en paramètre  une chaine de caractère. Cette chaine sera incluse en cas d’erreur de vérification.

ExceptionExpected

Cet attribut est utilisé sur une méthode de test (attribut TestMethod) afin de tester que l’appel de la méthode à tester génère bien la bonne exception. Cela évite de créer un test unitaire contenant un bloc try…catch.

Exemple :

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

Pour résumer les Principaux Attributs, voici dans quel ordre les différents attributs seront appelés si je lance le Test numéro 1 et 2 en une session :

  • [ClassInitialize()]
  • [TestInitialize()]
  • [TestMethod()]
  • Test numéro 1…
  • [TestCleanup()]
  • [TestInitialize()]
  • [TestMethod()]
  • Test numéro 2….
  • [TestCleanup()]
  • [ClassCleanup()]

Vous n’avez normalement pas à gérer vous-mêmes l’ajout des attributs, Visual Studio les ajoutera lui-même lorsqu’il les crée lors d’une génération.

Configuration des tests unitaires

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 test, 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 64Bits ?

-Le Timeout au niveau solution :

Vous pouvez y configurer la possibilité d’annuler toute une session de test 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 Test.

Les différentes manières de créer un test unitaire :
Créer des Tests à partir de Rien. (classe de test)
Créer des Tests à partir d’une méthode :

La Méthode la plus couramment utilisée : un clic droit sur la méthode,” créer un projet de test” ou” sélectionner un projet de test existant”. Et le “skeleton” de la méthode de test sera écrit à l’endroit voulu avec tous les attributs nécessaires.

Créer des Listes de tests :

Permet de regrouper vos tests par secteurs fonctionnels, classes ou assembly… En effet, quand vous regardez la liste des tests d’une solution, c’est bien tous les tests de chacun des projets de test que vous verrez, vous aurez ainsi vite besoin de les classer, les regrouper selon des critères à définir.

Séquences de Test Ordonnées :
  • permet de mémoriser, exécuter une Suite de tests, dont l’enchaînement a un intérêt.
  • Faire des scénarii de Tests : par exemple j’ai pu simuler le comportement d’un utilisateur dans une méthode, puis je l’ai réutilisé pour simuler 50 utilisateurs accédant à ma DAO en cours de développement.
Spécificités de l’outil :
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.

Multi-Cœurs

Le fonctionnement en Mono-cœur est le réglage par défaut de MsTest. Chaque test est exécuté un par un cœur. Cela va donc à une certaine vitesse… Quand on modifie le réglage en Multi-Cœur, on peut dérouler au maximum autant de test en parallèle que la machine a de cœur de processeur, comme 4 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œur que vous voulez utiliser.

MultiCore

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 :

MTAV2 MTAV3-legends

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 concurrentiel.

A 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 :

<TestSettings>
  <Execution>
    <!-- ... -->
    <ExecutionThread apartmentState="MTA" />
  </Execution>
</TestSettings>
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 datasource 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. DDT2

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 PROD 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 calculs, 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.

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émenter la liste List<T>, vous la nommez GenericList<T>.

Et elle implémente l’interface suivante :

Genericstest

 

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 :

testgenericsGeneration

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ériques 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 type non spécifique. 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 :

MetodHelperForgenerics

 

 

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é.

MsTest face à ses concurrents :

Ses avantages Face à NUnit :

Le TestContext sert à porter des informations d’un test à l’autre, et écrire dans le log du résultat de test.

AreEqual<T> pour faire des tests d’égalité entre objets, utile notamment si vous utilisez Entity Framework.

Assert.Inconclusive est automatiquement ajouté, lors d’une session de tests massifs, ceux marqués comme inconclusive sont considérés aussi comme échoués. Vous savez donc quels tests restent à implémenter.

Pouvoir renseigner les bons contextes de départ et d’arrivée pour les sessions de tests. L’aspect réutilisable d’un test (utilisé seul, ou dans une batterie de test).

Son Intégration :

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.

Complètement multithread, et Multi-Cœurs :

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 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 Listes ordonnées de Test.

Les Test 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 le 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)

Ses limites :

Un léger coût de démarrage de session de test au démarrage.

Pas d’assertion sur la présence des fichiers et répertoires.

L’intégration continue est moins facile en dehors des Outils Microsoft.

DataDriven Test : il faut au moins écrire un CSV au minimum pour les tests alors que NUnit supporte l’écriture paramétrique des méthodes de test avec les différentes combinatoires en attributs.

Sur les Tests Web : les tests unitaires vous permettront de valider les couches moyenne et basse, mais pas celle de l’UI, d’autre outils de TU vous seront plus adaptés comme WatiN. MSTest ne fournit pas de Mocks, mais l’on pourra cependant compter sur NMock3 (Net 3.5, Net 4.0) et Moq (.Net 4.0). Attention à RhinoMocks (.Net 3.5), plusieurs remontées de bugs incompréhensibles sur stackOverflow ou SocialMsdn ont été signalées.

Pour faire une synthèse : Comparatif MsTest NUnit

Mon retour d’Expérience :

Expérience chez un intégrateur de produits embarqués Automobiles :

Je faisais partie d’une équipe développant un SDK visant un déploiement public pour des applications embarquées sur des voitures. Il présentait de nombreuses fonctionnalités asynchrones, utilisait plusieurs threads, offrait l’accès à des ressources critiques.

Mon retour :

-Le séquençage de test : 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 Longues :

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 test 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.

Le retour de mon Client :

“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.”

Expérience chez un Client en E-Mailing Marketing:

Objectif de la mission : Construction d’un serveur WCF de calcul de cible marketing.

Problématiques :

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

Deux lots à réaliser :

-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.

Les fonctionnalités des tests unitaires ont été :

-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 multi-thread pour simuler une demande massive de calcul.

Retour Client :

« Les découvertes de bugs 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 Bug en Production aurait été quasi impossible, car le nombre de couches logicielles à tester aurait été beaucoup plus élevés qu’en période de tests unitaires »

Mon retour :

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 bug, je cherchai 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 toute les caractéristiques du premier lot fini avant d’attaquer le deuxième.

Et les autres versions de Visual Studio ?

Les plus de la licence Pro/Ultimate

Combien ça coûte ?

Comparatif de prix VS

Et si le chef peut sortir le chéquier…

Comparatif Visual Studio 2010

•      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é.

Visual Studio 2012

VS2012 menu Contextuel

Visual Studio 2012 reprends beaucoup de fonctionnalités de VS2010. On en voit quelques nouvelles, comme explicité sur cette copie d’écran on peut désormais relancer un sous-ensemble de tests en fonction de leur statuts (échoués, réussis, non exécutés…)

Code Clone Detection :

Si vous avez l’impression de revoir souvent les mêmes blocs de code, cette fonctionnalité vous ravira !

Analyseur de code :

Sert à l’analyse de la qualité du code d’une application sans l’exécuter. L’analyseur examine votre code à la recherche d’un ensemble d’erreurs courantes et du non-respect d’une bonne approche en matière de programmation

Microsoft Fakes isolation framework :

Enfin du Mocking ! MSTest ne le fournissait pas de base dans VS2010, voilà un manque comblé.

Extend the unit test type :

Comme son nom l’indique, permet de faire des Extensions du Framework de MSTest, ce que NUnit proposait déjà.

MSTest & NUnit utilisable tous les deux en totale transparence :

Visual Studio 2012 permet d’utiliser paraît-il, les deux aussi facilement, et en toute transparence.

Quelques liens Web :

http://dangerz.blogspot.fr/2012/01/converting-nunit-to-mstest.html http://blogs.developpeur.org/etienne/archive/2009/05/23/visual-studio-2010-quoi-de-neuf-pour-les-tests-web.aspx http://bradwilson.typepad.com/blog/2010/07/testing-routing-and-url-generation-in-aspnet-mvc.html#more

Nombre de vue : 702

AJOUTER UN COMMENTAIRE