Tester une application Windows Communication Foundation avec Visual Studio Team System Test Edition

Par Etienne MARGRAFF, Winwise http://blogs.developpeur.org/etienne

Introduction

Tout système se composant d’au moins un service est destiné à être consommé par un certain nombre de clients. Un grand nombre de questions récurrentes reviennent souvent dans ce genre d’architecture et sont souvent une inquiétude de nombreux responsables de projets. Quelle est la charge que peut absorber notre application ? Répondra-t-elle aux exigences en termes de temps de réponse lorsque le nombre d’utilisateurs atteindra les pics estimés ? Où se situent les facteurs limitants ? S’agit-il d’un problème logiciel ou d’une limitation matérielle ? Etc.

Windows Communication Foundation est une brique récente du Framework Microsoft.NET. Elle apporte une nouvelle manière d’appréhender la communication entre applications. Elle unifie plusieurs modèles et permet d’exposer des services via plusieurs modes, notamment sous forme de services web et via le protocole Tcp.

De nos jours de plus en plus d’applications .NET distribuées exposent leurs services via WCF.

Avec Visual Studio Team System Test Edition, il est devenu relativement simple de tester la charge d’une application.  La majorité des systèmes testés avec cet outil sont des applications web. Le but de cet article est de vous montrer que l’effort à faire pour réaliser le même type de test pour une application WCF est à peine plus important.

La première section de cet article montre comment créer des tests unitaires WCF qui permettront de valider la bonne exécution de ceux-ci. Ils pourront être utilisés notamment pour des tests de non régression.

La seconde section présente plus en détails l’aspect test de charge. Ils sont complémentaires aux tests unitaires WCF et permettent de valider la stabilité de l’application en simulant un comportement proche de la réalité en utilisant ces mêmes tests unitaires.

Bien qu’il soit globalement orienté pour des applications WCF, ce document traite de sujets généraux et peut tout à fait être utilisé comme référence pour d’autres types de tests de charge, comme par exemple des tests d’applications web.

NB : L’ensemble de cet article ainsi que ses exemples ont été écrit pour et avec la version 2008 de Visual Studio Team System Test Edition.

Visual Studio Team System Test Edition

Commençons par un rapide aperçu de l’édition Team Test de Visual Studio Team System (2008). Ceci sera certainement un simple rappel pour beaucoup d’entre vous mais il est important que tout le monde  parte avec la même compréhension de cet outil.

Cette version de Visual Studio (VSTT) est apparue avec la version 2005 en parallèle avec les différentes versions Team System Development Edition, Team System Architecture Edition, Team System Database Edition et la version comprenant l’ensemble des fonctionnalités des 4 autres versions : Team Suite.

VSTT présente globalement 6 types de tests et met à notre disposition les outils permettant de les générer, les classer, les exécuter et interpréter les résultats qu’ils auront générés :

• Les tests unitaires (présents également dans les versions Development  et Database)
• Les tests manuels
• Les tests web
• Les tests génériques (permettant d’encapsuler un exécutable et de l’exposer en tant que test Visual Studio standard)
• Les tests ordonnés
• Les tests de charge

Mis à part les tests de charge, chaque type de test représente un scénario unique de test correspondant en général à un cas « unitaire » d’utilisation d’une application.

Les tests de charges se situent à un niveau supérieur. Ils permettent de simuler différents types de charge sur une application en simulant des utilisateurs. Ces utilisateurs virtuels vont tout simplement exécuter les tests définis dans le « scénario de charge » suivant une répartition précise, correspondant au maximum à la réalité.

NB : Il est possible d’insérer n’importe quel type de test dans un scénario de test de charge, sauf les tests manuels.

Généralités sur les tests WCF

Lorsque l’on réalise un test de montée en charge sur une application quelle qu’elle soit, trois étapes majeures sont à réaliser :

• La création des scénarios d’utilisation de l’application
• La création et l’exécution du test de charge (coordonnant les scénarios)
• L’interprétation des résultats

Dans le cadre d’un test de montée en charge d’une application Web, les scénarii d’utilisation sont un ensemble de requêtes HTTP, paramétrées et définies dans un WebTest et représentant un cas d’utilisation de l’application. Dans le cas du test d’une couche de services WCF, les différents cas d’utilisations sont tout simplement les appels aux méthodes d’un ou plusieurs services.

Dans la pratique, un scénario de test d’une méthode d’un service WCF se concrétisera par un test unitaire. C’est ce test unitaire qui contiendra le code qui effectuera l’appel à la méthode du service et sera bien évidemment accompagné des différents contrats (interfaces) et proxies nécessaires à cet appel.

L’utilité de ce type de tests est double. Ils vous permettent :

• De tester unitairement le bon fonctionnement de chaque méthode
• D’intégrer ces tests unitaires dans des scénarii de tests de charge.

Un des aspects les plus importants lors de l’exécution d’un test de charge est l’interprétation des résultats. Plus nous avons d’indicateurs à notre disposition, plus l’analyse sera pertinente. Visual Studio Team System Test Edition et plus particulièrement sa partie LoadTest offre deux types d’indicateurs pour l’analyse de résultats de charge :

• Les métriques relevées lors de l’exécution par Visual Studio ou les agents de charge (ex. Temps de réponse, nombre d’utilisateurs simulés, etc.)
• L’historisation de listes de compteurs de performance issus des machines cibles

WCF met à notre disposition un nombre important de compteurs de performance qui vont nous permettre d’évaluer et d’interpréter un résultat de charge.

Création des scénarios de tests WCF : les tests unitaires créés « manuellement »

L’application testée contient deux services :

• Le service CalculatorService exposant la méthode Add qui permet d’additionner deux nombres
• Le service EmployeeService exposant la méthode GetEmployeesNames qui renvoie une liste de noms

La création d’un service WCF sort du cadre de cet article, c’est pourquoi nous ne nous attarderons pas sur les différents aspects de cette technologie. Vous pouvez retrouver la solution complète en fichier attaché à cet article.

Créer un test unitaire simulant un appel vers une méthode d’un service WCF n’est pas plus complexe que de créer la partie cliente réelle de l’application qui consomme ce service.

Dans une solution vierge, créez un nouveau projet de type Test :

C’est dans ce projet que tous les tests vont être créés et manipulés. Pour plus de clarté j’ai tendance à créer un répertoire par type de test.

Normalement, lorsque l’on teste une application WCF, les différentes classes « proxy » permettant d’encapsuler les appels aux méthodes de ce service existent déjà (si ce n’est pas le cas, vous pouvez réaliser très simplement cette opération avec l’outil svcUtil). Il suffit alors d’ajouter le ou les fichiers C# (par exemple) contenant les différents proxies et contrats (interfaces) nécessaires à la consommation de vos différents service WCF.

Dans le cas de l’exemple nous avons un proxy pour chacun des deux services CalculatorService et EmployeeService.

L’étape suivante consiste à créer les tests unitaires. Pour cela nous allons créer deux classes (une par service). Chacune de ces classes contiendra les méthodes que l’on désire tester pour le service qu’il représente (Clic droit sur le répertoire > Add > New Test) :

Une classe de test unitaire doit posséder l’attribut [TestClass]. Chacune de ces méthodes marquées de l’attribut [TestMethod] seront des tests unitaires distincts.

L’idée est donc de créer une TestMethod par méthode de service WCF que l’on veut tester. Dans le cadre de l’exemple, nous allons créer un test unitaire par type de binding proposé par notre host WCF (NetTcp et wsHttp).

Voici par exemple, le contenu de la méthode effectuant un appel via le protocole net.tcp vers la méthode GetEmployeeNames() du service EmployeeService.

[TestMethod]
public void NetTcpBindingGetEmployeesNamesTest()
{

EmployeesClient client = new EmployeesClient ("netTcpBinding_IEmployee");
int expectedEmployeeCount = 3;
int  actualEmployeeCount;
IList<string> clientList = client.GetEmployeesNames();
actualEmployeeCount = clientList.Count;
Assert.AreEqual(expectedEmployeeCount, actualEmployeeCount);

}

La classe statique Assert vous permet de vérifier la validité de vos tests. Le test sera considéré comme échoué si un test d’assertion n’est pas vérifié. La classe EmployeesClient est bien évidemment le proxy permettant de dialoguer avec le service EmployeeService.

Il nous suffit maintenant de créer un fichier pour la configuration de la consommation des services. Voici un extrait du fichier de configuration utilisé pour l’exemple :

<system.serviceModel>
<bindings>
<netTcpBinding>
<binding name="netTcpBindingConf" sendTimeout="00:01:00" />
</netTcpBinding>
</bindings>
<client>
<endpoint 
address="net.tcp://localhost:1664/LoadSamples/Service/EmployeeService"
binding="netTcpBinding" bindingConfiguration="netTcpBindingConf"
contract="IEmployees" name="netTcpBinding_IEmployee">
</endpoint>
</client>
</system.serviceModel>

Vous devriez maintenant arriver à une configuration comme celle-ci :

Ouvrez la fenêtre Test View (Test > Windows > Test View), lancez vos tests pour vérifier que chaque test s’exécute correctement individuellement :

Vous devriez obtenir ceci :

Création des scénarii de tests WCF : L’outil WCF Load Test

L’outil WCF Load Test (http://www.codeplex.com/WCFLoadTest), créé par Robert Jarrat, a pour but de nous simplifier la vie lors de tests WCF. Globalement, il se comporte comme le Web Test Recorder de Visual Studio. Il s’agit d’un analyseur de log WCF qui interprète les échanges entre les clients et services WCF et créé automatiquement les scénarii correspondants.

L’installation de l’outil se fait très simplement via un fichier .msi. Il s’intègre alors à Visual Studio et ajoute un nouveau type de test que l’on peut créer.

Commençons par créer un test de type WCF Test :
(Clic droit sur le répertoire > Add > New Test)

Un assistant s’exécute. L’étape « capture trace » va vous permettre de lancer l’exécutable de votre choix correspondant à votre client WCF habituel (celui destiné aux utilisateurs standards de l’application).

Cliquez sur « Run » effectuez les opérations que vous voulez (tout est tracé dans un fichier exploitable par l’outil). Vous pouvez également utiliser un fichier de trace pré enregistré. Ces fichiers correspondent aux fichiers de logs générés par une application hébergeant des services WCF lorsque la trace est activée pour cette application.

Fermez l’application une fois que vous avez terminé.

L’étape suivante vous permet d’avoir la liste des différents appels détectés lors de votre jeu de test. Vous pouvez sélectionner les appels de votre choix. Pensez également à cocher « Include unit test for each service call » qui créera un test unitaire par méthode en plus du test unitaire global simulant le scénario enregistré.

La dernière étape vous demande d’indiquer le chemin vers la ou les assemblies qui contiennent le ou les proxies nécessaires.

L’assistant créé alors deux fichiers qui contiennent la définition d’une classe partielle. Le premier (d’extension .cs) contient le code effectuant les appels aux méthodes des services WCF (les tests unitaires). Le second (d’extension .Custom.cs) contient la partie qui nous est destinée : celle où nous allons personnaliser les tests.

C’est dans la méthode InitializeTest() que sont créées les différentes instances des clients. Pour notre exemple, nous allons simplement indiquer quel est le nom de l’élément de configuration dans le fichier App.config qui devra être utilisé pour configurer le client :

Intéressons nous maintenant à une des TestMethod générée par l’outil :

private double Add()
{

double d1 = 1;
double d2 = 2;
this.CustomiseAdd(ref d1, ref d2);
_testContext.BeginTimer("GeneratedServiceTEsts_Add");
try
{
return calculatorClient.Add(d1, d2);
}
finally
{
_testContext.EndTimer("GeneratedServiceTEsts_Add");
}

}

La méthode CustomiseAdd, définie dans le fichier d’extension « .Custom.cs » est vide lors de sa génération. Vous pouvez ajouter votre propre logique pour rendre dynamique les paramètres de la méthode. On pourrait par exemple imaginer que les paramètres d1 et d2 proviennent d’une source de données et sont récupérés aléatoirement. Pourquoi ne modifions-nous pas ces paramètres directement dans la méthode Add() ? Tout simplement parce que ce code est susceptible d’être régénéré et donc d’écraser vos modifications. Il existera automatiquement une méthode CustomiseNomDeMethode pour chaque méthode unitaire créée.

J’aimerais également attirer votre attention sur les méthodes du contexte d’un test unitaire : BeginTimer et EndTimer. Lorsque l’on exécute un test via Visual Studio, celui-ci possède une liste de timers nommés qu’il affiche dans le rapport et dans les graphiques d’analyse (nous verrons cela plus loin dans cet article). Vous pouvez contrôler le temps d’exécution d’une portion de votre code de test en créant un timer de la même manière que dans le code généré ci-dessus.

Création et configuration du test de charge

Une fois que nous avons une batterie de tests unitaires permettant de simuler tous les comportements utilisateurs, ou du moins une grande partie, nous allons créer et définir le test de charge qui simulera une utilisation standard de l’application.

Avant de réaliser un test de montée en charge, plusieurs éléments sont indispensables à connaître et évaluer. Le plus important d’entre eux est la répartition des profils d’utilisation de l’application. En effet, les utilisateurs virtuels simulés par le test de charge vont exécuter les scénarii configurés pour ce test de charge et ne vont les exécuter ni dans l’ordre ni à fréquence égale (sauf si défini comme tel). Ils vont les exécuter selon la répartition que vous aurez définie. Cette répartition doit être réaliste, l’idéal étant d’obtenir des statistiques réelles d’utilisation de l’application. Dans le pire des cas, imaginez une répartition qui vous semble logique par rapport à la finalité de chaque fonctionnalité (par exemple, une fonction de recherche sera sûrement plus utilisée qu’une fonction de suppression d’utilisateur…).

Dans la version 2008 de VSTT, il existe 3 modes de répartitions des scénarios :

• Basé sur un objectif de nombre d’exécutions de chaque test (en %)
• Basé sur un objectif de nombre d’utilisateurs exécutant chaque test (en %)
• Basé sur un nombre de fois qu’un utilisateur exécute chaque test par heure

La répartition la plus utilisée est sans doute la première, elle permet de répondre à des conditions telles que : « 70% du temps, mes utilisateurs effectuent une recherche. ».

La seconde est à utiliser lorsque vous avez des profils bien définis et distincts d’utilisateurs. Par exemple, un comptable n’effectuera pas la même chose qu’un commercial. Si on sait qu’on a 10% d’utilisateurs qui sont comptables et 60% qui sont commerciaux, on répartira de manière adéquate pour que 10% des utilisateurs effectuent les opération comptables et 60% les opérations commerciales.

La dernière répartition est une autre façon d’aborder la première. La principale différence est qu’on est sûr que chaque utilisateur effectuera le même nombre de type de tests que les autres utilisateurs.

Créer un test de charge dans Visual Studio se fait en deux étapes :

• La pré configuration via l’assistant
• La configuration

Les étapes sont les suivantes :

• Ajoutez un nouveau test de type LoadTest
• Un assistant s’ouvre :
  • à l’étape Load Pattern, choisissez une charge constante à 1 utilisateur (pour les premiers essais)
  • à l’étape Test Mix Model, choisissez la première option qui correspond à la première répartition présentée précédemment
  • à l’étape Test Mix ajoutez vos différents scénarii et distribuez-les en fonction de leur utilisation métier suivant vos estimations
  • Nous configurerons le reste hors de l’assistant, terminez la création

Vous devriez obtenir une arborescence qui ressemble à celle-ci :

Un test de charge Visual Studio est organisé en 3 parties :

• Les scénarii de charge
• Les sets de compteurs
• Les configurations d’exécution

Les scénarios de charge représentent chacun un ensemble de scénarii « unitaires » (et leur répartition) qui peuvent être n’importe quel type de Test Visual Studio, sauf les tests manuels. Ils définissent également le type de charge qui sera effectuée. En sélectionnant le nœud « Constant Load Pattern » on peut modifier ce type de charge en  3 types :

• Une charge constante qui simulera un nombre constant d’utilisateurs tout au long du test
• Une charge par paliers qui prendra un nombre d’utilisateurs de départ et qui augmentera d’un nombre d’utilisateurs à des pas de temps définis
• Une charge par objectifs, plus particulière, qui permet de laisser Visual Studio augmenter ou diminuer le nombre d’utilisateurs de façon à ce qu’un compteur de performance soit entre une valeur minimale et maximale définie (par exemple, pour connaitre le nombre d’utilisateurs acceptés par l’application sans qu’elle ne consomme plus de 80% d’utilisation du processeur)

En général on utilise une charge constante avec un utilisateur pour tester la bonne exécution du test de charge puis on modifie le type de charge avant la vraie exécution.

Les ensembles de compteurs sont des listes de compteurs de performance Windows. Il en existe par défaut et il est possible de les personnaliser et d’en ajouter de nouvelles. Ces ensembles seront plus tard assignés aux machines pour lesquelles nous voudrons suivre et historiser les valeurs des compteurs compris dans ces listes. Nous allons créer une catégorie  « WCF » qui contiendra l’ensemble des compteurs proposés par WCF.

Pour cela il suffit de faire un click droit sur le nœud « Counter Sets » puis « Add Custom CounterSet ». On renomme ensuite le set via ses propriétés et y ajoute les compteurs souhaités (click droit puis « Add Counters »).

Sélectionnez une machine qui contient ces compteurs (peut importe laquelle, l’assignation aux machines à analyser se fera par la suite, il s’agit juste ici de créer la liste). Choisissez ServiceModelEndPoint 3.0.0.0 et sélectionnez « All Counters » et « All Instances ». Cette deuxième option permet de ne pas avoir à se préoccuper des instances d’applications WCF à suivre, il prendra toutes celles qu’il trouve lors de l’exécution.

Faites de même pour les deux autres catégories : ServiceModelOperation 3.0.0.0 et ServiceModelService 3.0.0.0.

Chacune de ces 3 catégories regroupe des informations relevées à différents niveaux de WCF :

• Au niveau de chaque service
• Au niveau de chaque endpoint de chaque service
• Au niveau de chaque opération (méthode) de chaque service

Un compteur sera créé pour chaque service, endpoint et opération.

On retrouvera dans chaque catégorie les informations sur les appels telles que : le nombre total d’appels, le nombre d’appels en cours de traitement la durée moyenne d’un appel, mais également des informations spécifiques à chaque niveau. On notera par exemple : le nombre d’instances actuelles et le nombre d’instances créées par seconde, chacun par service. On retrouvera de même des mesures au niveau de la sécurité, des transactions et des files d’attente.

Pour plus d’informations sur les compteurs de performance maintenus par WCF, je vous invite à vous rendre sur la section de la MSDN correspondante.

NB : Pour avoir accès aux compteurs de performances Windows d’une machine du domaine, il faut que l’utilisateur qui exécute Visual Studio soit membre du groupe local « Performance Monitor Users » de la machine en question.

Par défaut, les compteurs de performance de ServiceModel sont présents mais ne sont pas mis à jour. Pour cela il faut que les applications hébergeant un ou plusieurs services WCF que vous voulez contrôler soient configurées pour renseigner ces compteurs. Il suffit d’ajouter l’élément XML suivant dans le nœud <system.serviceModel> du fichier de configuration :

La dernière section d’un test de charge définit les différentes configurations d’exécutions pour le test. Il y en a une par défaut, mais vous pouvez en créer de nouvelles. Elles permettent de définir un certain nombre d’informations par rapport à l’exécution d’un test, notamment :

• La durée du test (Run Duration)
• Le taux d’échantillonnage (Sample Rate) qui définit la fréquence à laquelle les valeurs des compteurs de performance seront récupérées sur les différentes machines.
• Le temps de chauffage et de refroidissement (WarmUp et CoolDown)
• Le nombre d’erreurs pour lesquelles on garde en mémoire le détail

C’est également dans cette section que nous allons définir les compteurs à analyser pour les machines que l’on désire, via le nœud « Counter Set Mappings ». (Click droit puis « Manage Counter Sets »).

Ajoutez un ordinateur à la liste et saisissez son nom. Sélectionnez la ou les listes de compteurs que vous voulez suivre pour cette machine.

Exécution et analyse du test

NB : Avant l’exécution d’un test de charge, il est nécessaire de configurer une base de données qui permettra de stocker les résultats. Pour cela il faut créer cette base de données dans une instance SQL Server grâce au script  « loadtestresultsrepository.sql » que vous trouverez dans le répertoire Program Files/Microsoft Visual Studio 9.0/Common7/IDE. Il suffit ensuite de préciser la chaîne de connexion via le menu Test > Administer Test Controller et de modifier le champ « Load Test Result Store ».

Tout est maintenant prêt pour l’exécution du test de charge. Choisissez judicieusement le type de charge et le nombre d’utilisateurs pour les premiers tests : vous ne savez pas encore comment va se comporter l’application ! Commencez avec une charge constante à 1 utilisateur pour valider que tout se déroule correctement, puis effectuez un autre test avec une charge par paliers d’1 utilisateur toutes les 30 secondes et regardez ou se situe le point de rupture. Si vous n’en voyez pas après quelques minutes, augmentez le nombre d’utilisateurs par paliers, et ainsi de suite.

Lorsqu’un test se termine, il nous présente un résumé de l’exécution. Une des parties les plus intéressantes est le tableau présentant les temps de réponse moyen par test.

Dans cet exemple, on peut constater que la version de chaque méthode consommée via un Binding net.tcp est plus rapide que la version wsHttp.

L’outil d’analyse graphique de résultats de charge met à notre disposition 4 catégories principales, chacune regroupant un ensemble de valeurs que l’ont pourra ajouter sur des graphiques personnalisés :

• Overall : Contient des informations générales sur l’exécution du test comme par exemple l’évolution du nombre d’utilisateurs, le temps de réponse moyen des tests, etc.
• {NomDuScenarioDeCharge} (Il y en aura autant que de scénarii de charge) : Contient des informations plus précises par scénario unitaire pour chaque scénario de charge comme par exemple le temps moyen d’exécution d’un test
• Computers : Contient une liste d’ordinateurs qui ont été sélectionnés et les listes de compteurs de performances dont on a demandé le suivi.
• Errors : Contient des informations sur les erreurs

Chaque compteur, que ce soit un des compteurs de performances Windows récoltés, ou un des compteurs internes à Visual Studio (comme le temps de réponse d’un test) est historisé. On peut ainsi construire tous les graphiques d’analyse nécessaires même après l’exécution du test.

Du fait que chaque application a ses particularités, il est très difficile de donner une méthode générale d’analyse d’un résultat de test de montée en charge. Ceci dit, on peut tout de même découper cette analyse en deux parties :

• Trouver le point de rupture de l’application. Il s’agit du moment où l’on peut considérer que l’application ne répond plus correctement à la demande utilisateur. Il s’agit en général du temps de réponse de l’application. Si vous ne trouvez pas un tel point de rupture, ré-exécutez un nouveau test avec des paliers d’utilisateurs plus importants.
• Trouver le facteur limitant. Cette étape est en générale la plus délicate. Il faut mettre en parallèle le moment ou l’application ne répond plus correctement et les différentes composantes applicatives, systèmes ou matérielles ne se comportent pas correctement.

Voici un exemple de graphique d’analyse :

On remarque bien l’augmentation du nombre d’appels à ce service proportionnellement au nombre d’utilisateurs. De même pour le nombre d’instances WCF.

Conclusion

Réaliser des tests sur des services WCF est une opération très simple grâce aux outils fournis par Visual Studio Team Test. L’avantage d’utiliser les tests unitaires est double :

• Exécutés de manière isolée, ils permettent de valider le bon déroulement de l’exécution d’une méthode d’un service. Il est envisageable de les utiliser, par exemple, pour effectuer des tests de non régression avant une livraison.
• Regroupés et répartis dans un test de charge, ils permettent d’analyser finement le comportement global de l’application les hébergeant

Visual Studio Team System Test Edition offre souplesse et simplicité pour réaliser à la fois ces tests unitaires mais également le test de charge qui les regroupe. L’outil WCF Load Test rend possible l’automatisation d’une grande partie de l’écriture de ces tests et facilite ainsi encore plus le travail du testeur.

L’analyse des résultats de tests est grandement facilitée par les compteurs de performance intégrés à WCF. Par contre, s’ils permettent une étude fine de la majorité des problèmes pouvant survenir lors de l’exécution d’applications de ce type, je vous conseille de créer vos propres compteurs dans une catégorie personnalisée. Cette pratique, qui d’ailleurs est valable pour tout type d’application, permet d’obtenir des indicateurs beaucoup plus précis car conçus spécifiquement pour l’application testée.

Références

Voici quelques lectures que je vous conseille concernant les tests de charge :

• L’incontournable Performance Testing Guidance qui est un des documents “Pattern & Practices” de Microsoft, disponible sur CodePlex
• L’outil WCF Load Test également disponible sur CodePlex
• Le Software Tester Team Center de la MSDN

Remerciements

Je tiens à remercier Eric Le Loc’h et  Julien Corioland pour leur relecture. Je remercie également Winwise et plus particulièrement Florent Santin, responsable du pôle Génie Logiciel et Team System, pour m’offrir l’opportunité d’intervenir sur des technologies et des outils tels que ceux présentés dans cet article.

A propos de l’auteur

Je suis passionné par les nouvelles technologies et plus particulièrement le développement. Après obtention du diplôme de l’IUT Robert Schuman j’intègre l’école SUPINFO au sein de laquelle je me découvre une passion pour les technologies .NET. Je deviens alors formateur pour le laboratoire .NET de cette école et ai le plaisir d’en gérer l’équipe recherche et développement lors de ma dernière année.

J’ai rejoint il y a quelques mois l’équipe de l’entreprise Winwise, Microsoft Gold Partner, spécialisée dans le développement et les outils Microsoft et fais actuellement partie du pôle Génie Logiciel et Team System.

Je maintiens également un blog technique principalement orienté autour de l’outil Visual Studio Team Test, que vous pourrez retrouver à l’adresse suivante : http://blogs.developpeur.org/etienne