Archives de catégorie : Test

Découverte de MSTEST V2

Microsoft a annoncé cet été une nouvelle itération de son framework de tests Microsoft Tests avec une V2 annoncée comme ayant comme principales nouveautés : le support du multi-platforme (.net Core, UWP, .net et toute la smala) mais également le support des parameterized tests ! (oui, Enfin !!)

Alors qu’il était possible de créer des tests orientées données via l’attribut DataSource, il était jusqu’à présent impossible (sauf développement custom, ou intégration de librairie tierce) de définir des paramètres sans source de données externe (BDD, csv, etc.)

MS Test V2 permet de faire cela via l’utilisation de deux attributs : DataTestMethod qui doit être utilisé en lieu et place de l’attribut TestMethod afin d’indiquer que les paramètres de la méthode de test seront définis par les valeurs indiquées par l’attribut DataRow.

Exemple :

image

Vous n’avez ainsi pas besoin de décomposer vos tests en plusieurs appels de méthodes pour chaque cas de tests, vous pouvez les généraliser si vous avez un jeu de données fixe et simple.

MSTest V2 est disponible en pre-release via nuget via les deux packages suivants :

image

Et si vous souhaitez l’utiliser dans un projet de tests existant, vous devrez supprimer la référence existante vers Microsoft.VisualStudio.QualityTools.UnitTestFramework afin d’éviter tout conflit avec les classes proposées par MS Test V2.

Une fois toutes ces opérations réalisées vous pourrez bien voir le test adapter en action, le test runner de Visual Studio reconnaît bien vos tests en question :

image

Seul problème, le test runner de Resharper lui ne les reconnaît pas encore, et a un comportement aléatoire au niveau de la découverte de l’exécution de ceux-ci…

continousintegration

Critique : Continous Integration in .net

Comme indiqué dans le titre de l’ouvrage, ce livre traite de la mise en place du principe d’intégration continue au sein de projets .net.

Pour rester général, les auteurs évoquent cette mise en place via 3 environnements : CruiseControl.net, Team Foundation Server et Team City.

Le message distillé au long des plus de 300 pages est clair, la mise en place d’intégration continue ne nécessite pas un investissement financier important (peut être gratuit via les 3 produits cités sous différentes conditions), il nécessite un investissement en montée en compétence, et en temps d’implémentation qui va très vite être rentabilisé.

Gestion des sources, compilation, feedback, mise en place de tests, analyse statique via FxCop, StyleCop et NDepend, gestion des changements de schéma de BDD, génération de projets de setup, et génération de documentation, tous les sujets techniques sont évoqués et décris de manière pratique.

Le parti pris d’évoquer les 3 environnements à certainement pesé sur le fait que l’ouvrage ne décrit pas en profondeur les fondamentaux, ne donne pas la part belle à “la théorie”, au pourquoi du comment, ni aux concepts associés (les feature flags par exemple).

Continuous Integration in NET est un bon ouvrage pour les débutants en intégration continue qui souhaite se mettre de manière pratique via un des 3 environments cités ci-dessus. Ceux d’entre vous qui maitrisent déjà les notions de base et qui cherchent un ouvrage de référence préférerons passer le chemin et se diriger vers un ouvrage plus théorique.

image

Librairie FeatureFlags : Choix de conception

Je vous ai parlé il y a peu de l’utilisation des Feature Flags qui est une technique qui facilite la mise en place d’intégration continue, je vous avais alors indiqué que les différentes implémentations disponibles en .net ne me satisfaisait pas.

imageJ’ai donc débuté le développement d’une librairie appelée tout simplement FeatureFlags.

Avant de mettre le code à disposition sur codeplex, je vais donc partager vous les différents choix de design que j’ai effectué.

J’ai opté pour un principe simple afin de faciliter la maintenance des features : je souhaite que l’utilisation du principe soit le plus fortement typé possible afin que l’on puisse agir directement sur les différents emplacements dans le code où une feature est utilisée.

Ainsi toute suppression de feature (car plus utile, par exemple dans le cas d’une activation définitive), doit lever différentes erreurs de compilation afin de forcer le développeur à supprimer tout le code inhérent.

Niveau UI

Mon besoin étant uniquement orienté autour d’applications WPF, je me suis attardé uniquement sur ce type d’intégration.

L’objectif est de pouvoir afficher ou non n’importe quel contrôle WPF en fonction de l’état d’activation d’une fonctionnalité.

Pour une intégration simple et souple, j’ai opté pour l’implémentation d’une custom MarkupExtension.

Cette solution de lier très simplement une propriété Visibility à une Feature et permet également de rester fortement typé. Si la classe de définiton de la feature est supprimée, nous nous retrouverons avec une erreur de compilation XAML facilement détectable.

image

A noter la possibilité d’afficher des contrôles en fonction de la non activation d’une feature via la définition de la propriété IsEnabled (définie à True par défaut) :

image

D’un point de vue du rafraichissement, j’ai opté pour une récupération de l’état d’activation de la feature en “One Time” uniquement au moment de la récupération de la MarkupExtension. Cela signifie que si l’état d’activation change alors que la fenêtre parent est déjà chargé, l’UI ne sera pas impactée.

Niveau Code

D’un point de vue code, le flip se fait de manière très simple :

image

Je viendrais dans un prochain post sur la gestion de la persistence de l’état des features en base de données.

N’hésitez pas à me faire part de vos remarques sur ce design par rapport aux autres libraires du marché.

image

Gestion des évolutions grâce aux Feature Flags

Gérer correctement les évolutions dans un projet logiciel n’est pas simple car il faut arriver à gérer le cycle des releases qui en général est beaucoup plus rapide que le rythme de mise à disposition de certaines fonctionnalités qui prennent du temps à être développé.

Il est donc souvent nécessaire de mettre en place certains mécanismes permettant d’arriver à livrer très régulièrement une application “malgré” des développements en cours non finalisés.

Première principe et le plus populaire :

La mise en place de branching

Quelle que soit la stratégie de branching choisie (branche corrective + branche évolutive, branches par version, ou branches par fonctionnalité – je vous recommande d’ailleurs ce guide sur les différentes stratégies de branching que l’on peut mettre en place –), la mise en place de branches ajoute une surcharge de travail qui est gérable mais qui peut être conséquente.

Il y a bien évidemment la surcharge de travail pour les développeurs au niveau des merges entre les différentes branches, mais également une surcharge de travail d’un point de vue des tests.

Il est en effet nécessaire d’effectuer des tests sur la branche sur laquelle le développement a été effectué, mais également sur toutes les autres branches sur lesquelles les modifications vont être fusionnées.

Il s’agit donc d’une technique qui peut avoir un impact sur la vélocité des releases, sur le rythme de mise à disposition de nouvelles fonctionnalités.

Les feature flags

Autre principe plus léger à mettre en place : les feature flags.

imageLe principe est simple : afin d’être capable de gérer les évolutions, il suffit de développer les fonctionnalités et de les livrer même non finalisés dans les différentes releases mais de les désactiver afin de les rendre inacessibles aux utilisateurs.

Il suffira ensuite de les activer ou non directement au runtime par configuration, sans aucune modification de code et donc sans aucun déploiement lorsqu’on le souhaitera.

 

 

Plusieurs avantages à ce principe :

  • On ne ralentit pas la cadence des releases puisqu’on livre les fonctionnalités non terminées (qui resteront masquées)
  • On peut activer ou non certains certains fonctionnalités en fonction des différents clients (selon leur profil par exemple) afin de les faire participer à des phases de tests (alpha, beta, etc.)
  • On n’est capable de revenir en arrière en cas de problème car en général les feature flags doivent pouvoir être accompagnées de logique de rollback

Ce concept a été mis en place et mis en avant par les équipes de Flickr. Je vous invite d’ailleurs à consulter le post de fin 2009 présentant le principe et son application au site web flickr.

Le principe a été ensuite décrit par Martin Fowler via le pattern Feature Toggle.

Il existe différentes implémentations des feature flags dans l’ecosystème .net : FeatureSwitcher, FeatureToggle, NFeature

La plupart des librairies reposent sur le même principe : on active ou désactive les features de l’application en passant par le fichier de configuration de l’application.

D’un point de vue de la représentation des features au niveau du code, la plupart se basent sur des classes implémentant une interface ou une classe de base, ou alors via une Enum qui permet de lister celles-ci.

N’aimant pas particulièrement les fichiers de configuration (ils sont trop compliqués à maintenir, à faire évoluer), je vais bientôt revenir vers vous avec une nouvelle libraire permettant de gérer cela directement en base de données.

Stay tuned !

image

Personnaliser le taskboard de TFS 2012

L’implémentation de SCRUM dans TFS 2012  (une vraie correcte et utile, pas celle proposée par TFS 2010) est de mon point de vue la nouveauté la plus importante de cette version.

Microsoft va proposer un outillage pertinent afin de mettre en place SCRUM au sein d’une équipe de développement.

Dans le nouveau Team Web Access, entièrement redéveloppé, nous disposons donc à présent d’un taskboard présentant l’ensemble des tâches du sprint courant classées de manière traditionnelle dans des colonnes Todo, In Progress, Done :

image

Au sein de l’équipe, nous avons légèrement adapté SCRUM afin de prendre en compte de manière plus ciblée les tests. Nous avons ainsi ajouté une sous-colonne Test dans la colonne In Progress :

image

Si vous souhaitez modifier le taskboard de TFS afin de rajouter des colonnes sachez que cela est tout à fait possible !

La première étape consiste à modifier la définition des work items afin de rajouter un état supplémentaire et de modifier les transitions en conséquences. Pour cela, utiliser les Powertools de TFS afin d’exporter la définition de vos WI et de les modifier :

image

Une fois les work items modifiés, il reste à modifier la gestion des états du taskboard. Pour cela, il faut exporter le fichier CommonConfiguration et cela se passe en ligne de commande :

image

Ajouter l’état Test :

image

Et importer le fichier modifié à l’aide de la commande suivante :

image

Et voilà le résultat :

image

image

3 bonnes raisons d’utiliser différents frameworks de tests – Tips #1 Bis

Suite au relai de mon post sur le très bon test runner proposé par Visual Studio 11 et son support de différents frameworks de tests par Richard Clark, celui-ci se posait la question de l’intérêt de supporter différents frameworks de tests au sein (par exemple) d’une même solution.

image

Je vous propose donc aujourd’hui 3 bonnes raisons d’utiliser différents frameworks de tests :

  • La possibilité de réutiliser, sans migrer, des tests existants tout en switchant (pour tout ou partie) les nouveaux tests sur un nouveau framework. Vous appréciez l’intégration de MS Test mais ne supportez pas le non respect du pattern AAA pour les tests liés à la gestion d’exception ? Continuez d’utiliser MS Test, et utilisez un autre framework comme xUnit qui vous permettra d’avoir des tests de meilleure qualité.
  • Le support de frameworks de tests ciblants différents langages. Exemple : Je développe un site web ASP.net et je souhaite créer et exécuter des tests unitaires et d’intégration pour mon code VB ou C# mais également pour du code javascript. Je peux donc utiliser à présent MS Test, xUnit, nUnit ou autres pour le code managé, mais également Chutzpah pour les tests du code JS.
  • Le support de frameworks de tests proposant différents types de tests. On utilise en effet généralement un seul et même framework pour développer tests unitaires et tests d”intégration, mais il existe d’autres types de framework permettant d’écrire des tests se rapprochant au plus près de la définition des spécifications (comme MSpec), ou proposant une syntaxe naturelle pour les assertions. Il est donc possible de les utiliser de manière complémentaire avec les frameworks plus “traditionnels” avec Shoudly par exemple.
image

L’exécution automatique de tests avec VS 11 – Tips #2

Après la présentation hier de l’ouverture de VS 11 à tous les frameworks de tests qui permet d”éviter d’avoir différents tests runner et surtout de développer des tests basés sur plusieurs frameworks de tests, je vous propose aujourd’hui une astuce toute bête mais bien pratique : l’exécution automatique de tests.

image

Il est à présent possible d’exécuter les tests présents dans votre solution de manière automatique juste après une simple compilation.

Un petit Ctrl+Shift+B et une fois la compilation réussie l’exécution de tests se lance :

image

A noter qu’une sélection des tests à exécuter est réalisée par Visual Studio. Contrairement à mon screenshot qui présente un cas simple, Visual Studio 11 décide quels tests sont à exécuter en priorité. Ceux qui ne sont pas exécutés se retrouvent avec une icône légèrement grisée afin d’indiquer qu’ils n’ont pas été ré-exécutés.

image

Le support des framework de test dans VS 11

La beta de Visual Studio 11 est disponible depuis hier, je vais donc à présent essayer de vous présenter quelques nouveautés présentes dans cette beta.

Une des nouveautés les plus intéressantes concerne le support de différents frameworks de test directement dans Visual Studio 11.

Il était bien évidemment possible de développer des tests unitaires et d’intégration en utilisant d’autres framework que MS Test, mais l’utilisation de ces frameworks nécessitaient jusqu’à présent l’utilisation de tests runners dédiés ou génériques plus ou moins bien intégrés avec Visual Studio. Une des références dans le domaine est le test runner de ReSharper qui permet d’exécuter des tests MS Test mais aussi des tests nUnit.

Visual Studio 11 propose à présent d’intégrer simplement n’importe quel framework de tests via une API qui permet de développer des adapters.

En autres mots, le test runner de Visual Studio 11 est à présent totalement découplé de MS Test.

Prenons comme premier exemple, une classe bateau :

image

Si vous avez installé xUnit, vous pouvez à présent installer le runner de xUnit compatible avec Visual Studio 11. Ce test runner n’est pas un test runner indépendant, il s’agit en réalité d’un simple adapter qui permet de se plugger au test runner de Visual Studio 11 :

image

Il est évidemment possible de créer un test en suivant les principes de ce framework :

image

Et lorsque l’on exécute le test, on retrouve ensuite le résultat de ce test directement l’explorateur de tests de VS 11.

image

Ce qui rend encore plus intéressant avec cette ouverture vers d’autres frameworks de tests, est qu’il est tout à fait possible de créer des tests en utilisant d’autres frameworks de test tout en restant dans le même projet !

Ainsi l’ajout d’un test basé sur MS Test :

image

permet d’avoir directement le résultat de ce test intégré avec les autres tests :

image

Fini donc les frustrations d’utiliser tel ou tel framework de test, ou les potentielles difficultés de switcher vers tel ou tel framework de test, il est possible d’utiliser simultanément ceux qui vous conviennent le mieux !

Et bien évidemment, l’outil de couverture de code de Visual Studio 11 prend en compte l’intégralité des tests :

image

Vous pouvez consulter la liste des adapters déjà disponibles sur ce lien, à savoir que d’autres adapters pour d’autres framework devraient arriver très prochainement.