Démarrer avec Specflow

L'article suivant vous propose de vous lancer avec Specflow en langage gherkin pour les francophones. Specflow est la version destinée à Visual Studio de Cucumber.

Installation dans Visual Studio

Dans Visual Studio 2010, 2012 ou 2013, depuis les extensions et mises à jour de Visual Studio Gallery, chercher « specflow » et l’installer.

Redémarrer ensuite Visual Studio 2013

Créer un projet de test

Il faut créer un projet de test pour intégrer les différents cas de test.
(Plusieurs framework de test unitaire sont supportés dont MsText, NUnit, xUnit, mbUnit)
Cliquer sur Ajouter au niveau de la solution et ajouter un projet de test unitaires :

Supprimer le fichier TestUNit1.cs créé automatiquement dans le projet.
Pour fonctionner avec MSTest, il faut installer le package NuGet SpecFlow dans le projet (Pour Nunit, remplacer par SpecFlow.NUnit). Il suffit de lancer la commande suivante dans le Nuget Package Manager  :

PM> Install-Package SpecFlow -ProjectName MonAppli.Extranet.Specs

ou l'installer via l'interface de Package Manager

La référence TechTalk.SpecFlow doit apparaître dans le projet de test :

Dans le fichier App.config, il faut modifier la configuration afin :

• d'ajouter le langage par défaut en fr-FR pour écrire les Feature en francais (en-US par défaut)
  

  <language feature="fr-FR" />

• d'indiquer le framework MsTest comme celui à utiliser pour générer les tests
  

  <unitTestProvider name="MsTest" />

Pour le détail des configurations possibles se reporter à la page de documentation suivante http://go.specflow.org/doc-config.

Créer une première feature

Cliquer droit sur le projet pour ajouter un nouvel élément. Choisir le SpecFlow Feature File et cliquer sur Add.

Ouvrir le fichier et modifier les mots clés par ceux correspondant au français.
"fr": {
 "name": "French",
 "native": "français",
 "feature": "Fonctionnalité",
 "background": "Contexte",
 "scenario": "Scénario",
 "scenario_outline": "Plan du scénario|Plan du Scénario",
 "examples": "Exemples",
 "given": "*|Soit|Etant donné|Etant donnée|Etant donnés|Etant données|Étant donné|Étant donnée|Étant donnés|Étant données",
 "when": "*|Quand|Lorsque|Lorsqu'<",
 "then": "*|Alors",
 "and": "*|Et",
 "but": "*|Mais"
},
Une aide contextuelle (Intellisense) permet de retrouver facilement les mots-clés :

Générer les étapes et exécuter les tests

Pour construire les tests unitaires sous-jacents, il suffit de générer les étapes en cliquant droit sur le fichier et choisissant Generate Step Definitions , puis en sélectionnant les étapes à générer et cliquer sur Generate.

Vous  pouvez alors choisir le fichier et la classe (existante ou à générer) qui accueillera ces étapes.

Une fois le squelette du code généré, lancer une compilation du projet en cliquant sur Projet > Générer. Chaque scénario peut être lancé depuis la fenêtre de Test de Visual Studio.

Il reste alors à implémenter le code de test puis le code réalisant la fonctionnalité.
N’oubliez pas de supprimer la ligne avec ScenarioContext.Current.Pending();

Pour aller plus loin

Pour bien coder et tirer parti des fonctionnalités de specflow, la page suivante permet de pointer sur les pratiques les plus importantes : http://www.specflow.org/getting-started/beyond-the-basics/
La page des ressources est aussi intéressante notamment les blogs Posts concernant ASP .Net MVC.
http://www.specflow.org/resources/

L'intégration à la build TFS est aisée. Comme des tests unitaires sont générés (MsTest, NUnit, …)., il n’est pas nécessaire d’ajouter de la configuration supplémentaire au niveau de la Build (si ce n’est l’exécution des tests unitaires, normalement configuré par défaut).

Pour des fonctionnalités plus avancées, il faut utiliser SpecFlow+ Runner qui est payant.
Il permet aussi de :

• Afficher les titres des scenarios dans le résultat de l’exécution
• Générer un rapport HTML détaillé et personnalisable
• Permettre de filtrer les scenarios dans la définition de Build

have a nice day.

Migrer de TFS 2008 SP1 vers TFS 2012

Si vous avez encore votre serveur TFS en version 2008 SP1, il faudra migrer d'abord celui-ci vers TFS 2012 avant éventuellement de le migrer vers TFS 2013. Voici un résumé des principales étapes pour cette migration et celle de votre contenu SharePoint (WSS3.0).

1. Préparer les nouvelles machines avec : (Dans la plupart des cas, il n'est pas possible de migrer sur place)
1. Windows 2008 R2 SP1
2. SQL Server 2008 R2 SP2
3. SharePoint 2010 SP2
4. TFS 2012 Update 3 (une de mes migrations avec l'update 4 a échouée)
2. Préparer les outils et Team Build
1. migrer vers VS2012 autant que possible les solutions.
2. migrer vos taches et outils de Build vers vers le nouveau modèle objet client.
3. migrer une build .Net : à priori pas ou peu d'actions (sauf migration optionnelle de MsTest vers Test Runner et des personnalisations du 2.)
4. migrer une build Cpp en conservant une solution et projets VS2008  :
   Voici les points que j'ai rencontré, vous en aurez surement de supplémentaires,
   Sur la machine de Build :
   • Installer Windows SDK 6.1A
   • Installer la fonctionnalité du serveur .Net 3.5.1
   • Installer VS2008 avec Team Explorer puis le SP1
   • Ajouter au PATH : "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64"
   Sur la définition de Build et les projets, il faut parfois s’assurer que l'"OutDir" personnalisée soit utilisée (et les fichiers bien envoyés dans le répertoire de dépôt)
   • Si l'OutDir est commun aux solutions et projets, modifier simplement la règle de l'activité "Create OutputDirectory Per Platform and Configuration" du process par défaut.
   • Sinon,  il faut supprimer la valeur passée en global à OutDir par Team Build dans l'activité  "Run MSBuild for Project". Puis, il faut passer un nouveau paramètre au travers des "MSBuild Arguments". Celui-ci permettant de distinguer la compilation avec VS de celle avec Team Build et d'ajuster en conséquence le répertoire de sortie "OutputPath"
   • Quelques solutions : http://stackoverflow.com/questions/2784335/how-can-i-get-tfs-2010-to-build-each-project-to-a-separate-directory
     http://blogs.msdn.com/b/jimlamb/archive/2010/04/13/customizableoutdir-in-tfs-2010.aspx
3. Sauvegarder, puis Restaurer les bases vers le nouveau serveur de base de données
• tfsXXX (toutes les bases de TFS)
• Wss_Content (la base de contenu SharePoint)
• ReportServer et ReportServertempdb (base des rapports).
  Cette restauration est à réaliser si vous avez des rapports personnalisés. Les nouveaux rapports sont créés automatiquement lors de la migration.
4. Migrer les bases TFS en choisissant l'option Mise à jour dans la boite de dialogue.
   Suivre les instructions pour migrer les bases TFS et le reporting. (Je préfères migrer SharePoint séparément)
   La migration est longue voire très longue suivant la taille de votre base de code et le nombre d'éléments de travail. L'idéal est de la tester une première fois avant de réaliser la migration définitive.
5. Configurer SharePoint 2010.
   Lancer une configuration standard en créant une nouvelle ferme de serveur et un nouveau site d’administration centrale. Puis lancer l'assistant d'installation pour configurer les applications et service, sauter la création d'un site de haut niveau.
6. Installer les extensions TFS pour SharePoint depuis la console d'administration de TFS.
   (Ou les installer directement depuis les sources TFS si SharePoint est sur un serveur séparé)
7. Ajouter la base de données de contenu. Pour cela, il faut utiliser la ligne de commande  (impossible de puis l'administration centrale)
   cd c:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\BIN
   stsadm.exe -o addcontentdb -url http://SPSserveur/ -databasename WSS_Content -databaseserver DBServeur
8. Vérifier l’association du serveur SharePoint avec le serveur TFS depuis la console d’administration de TFS, activer l'association si nécessaire. Fixer les liens entre les projet d''équipe TFS et leur site SharePoint depuis la section Paramètres de Visual Studio Team Explorer 2012. 
9. Si vous migrez de domaine, changer les identités dans TFS et SharePoint.
   Mon billet disponible ici détaille les opérations.
10. Vous pouvez alors appliquer l'update 4 de TFS sur les serveurs.
    Ou bien choisir de migrer vers TFS 2013, la procédure sera plus simple et détaillée sur MSDN.
11. Pour bénéficier des nouvelles fonctionnalités du Web Access dans vos projets d'équipes existants, il vous faudra bien-sûr suivre la procédure de mise à niveau.

have a nice day.

10 astuces pour garder son TFS en bonne santé

Dans un article et dans le livre Professional TFS 2012, Grant Holliday explique comment bien maintenir une instance de TFS. Même s'il indique des priorités, la liste des actions est très longue. Je souhaite proposer ici une liste restreinte et ordonnée d'astuces qui permettent de conserver une instance TFS 2010/2012/2013 fonctionnelle pour une équipe jusqu'à 20 personnes.
Pour ce type d'instance, la personne dédiée à l'administration de TFS a souvent très peu de temps à y consacrer, il s'agit rarement de son travail principal. Il lui faut aller à l'essentiel. J'ai donc mis de côté tout ce qui concerne des installations complexes ou l'optimisation des performances.

1. Sauvegarder l'instance TFS
• cela vous permettra de restaurer votre instance en cas de crash
• les bases sont paramétrées par défaut pour une restauration complète, cela signifie qu'un fichier journal de transactions est généré, si vous ne sauvegardez pas régulièrement ceux-ci, ils vont prendre une taille énorme.
• la sauvegarde est très facile avec l'outil de sauvegarde et restauration. (inclus dans TFS2012/2013, pour 2010 installer les TFS Power Tools Dec. 2011, pour le réaliser à la main suivez bien les instructions ici)
2. Exécuter l'outil Best Practice Analyser (chaque mois)
• il permet de détecter des problèmes dans votre architecture
• l'outil est inclus dans les TFS Power Tools, et s'exécute en quelques minutes seulement. 
3. Mettre à jour les machines SQL Server et TFS
• la mise à jour des machines permet d'éviter des failles de sécurité et une mise à jour très longue au moment d'une montée de version.
• pour TFS l'idéal est d'être toujours sur la dernière mise à jour un mois après sa sortie. Il arrive qu'une ou 2 régressions soient corrigées rapidement. Profitez-en pour mettre aussi à jour Visual Studio sur les postes de développement.
• installer la version la plus récente possible de SQL Server (TFS 2010 = SQL2008R2SP3, TFS 2012.4 = SQL2012 SP1, TFS 2013 = SQL2012 SP1)
4. Installer un environnement de taille suffisante
• sans rechercher la performance, il faut un minimum de puissance, de mémoire, et d'espace disque ! Suivez les indications du TFS Planning Guide 
• la santé des disques hébergeant les fichiers des bases de données est souvent un facteur clé du bon fonctionnement. Vous pouvez les surveiller en effectuant un échantillonnage à l'aide de l'analyseur de performance sur l'objet "Disque logique" ou "Disque physique" et le compteur en pour 1000 "Moyenne disque s/transfert" (échantillonner toutes les 30 secondes). Les résultats ne doivent pas dépasser 0.050.
5. Vérifier la bonne santé de l’instance de bases de données SQL Server
• la majorité de la logique de TFS est implémentée dans des procédures SQL. La santé de TFS est donc largement dépendante de celle de l’instance des bases de données SQL Server.
• exécuter régulièrement DBCC CHECKDB pour vérifier leur intégrité
• vous pouvez aussi utiliser les DMV (Dynamic Management Views) à partir du script de Jimmy May disponible ici pour vérifier qu'il n'y pas de problème majeur.
6. Vérifier et modifier les paramètres du pool d'application IIS
• passer le paramètre de délai d'inactivité de 20 minutes à 0 pour éviter que le pool s’arrête et redémarre. Cette optimisation est d'autant plus intéressante que l'équipe de développement est petite...
• planifier le recyclage en dehors des heures de travail du pool d'application.
7. Vérifier régulièrement le journal d'activité et les travaux depuis http://monserveur:8080/tfs/_oi/
• cela permet de vérifier si des travaux posent problèmes
• cela permet aussi de verifier la santé de l'entrepôt de données et et du cube OLAP
8. Vérifier et sauvegarder les Builds
•  sauvegarder régulièrement le répertoire de dépôt des Builds TFS (sauvegarder aussi votre répertoire de symboles, si vous en avez un)
• vérifier aussi que l'espace disponible sur les machines de Build est suffisant.
9. Vérifier ou désactiver les journaux IIS
• cela permet d'éviter de remplir le disque ...
• pour les désactiver, exécuter  la commande suivante sur l'application-Tier en tant qu'administrateur local :
  %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpLogging /dontLog:"True"  /commit:apphost
10. Nettoyer les éléments non utilisés de TFS
• avec Team Foundation Sidekicks, supprimer les espaces de travail et mises sur étagères non utilisés.
• avec witadmin, lister puis supprimer les champs inutilisés :
  witadmin listfields /unused /collection:http://monserveur:8080/tfs/DefaultCollection
  witadmin deletefield /n:referencechamp /collection:http://monserveur:8080/tfs/DefaultCollection
• avec le Test Attachement Cleaner, supprimer les fichiers attachés inutiles. Il est inclus dans les TFS Power Tools. Le détail des opérations est bien expliqué ici.

Il existe d'autres astuces que je trouve aussi intéressantes dans ce cadre, mais il faut tenir la limite.
Qu'en pensez-vous ? A votre avis, quelle autre astuce devrait se trouver dans cette liste ?

have a nice day.

Supprimer le Lab Management de la configuration

Un client avait configuré le Lab Management pour tester ses fonctionnalités. L'équipe a ensuite décidée de stopper son utilisation car la solution de virtualisation au niveau entreprise, fraîchement choisie, n'est pas SCVMM. Cette fonctionnalité n'est donc plus utilisée. Après un changement de domaine et une migration vers TFS 2012, une erreur était déclenchée très régulièrement sur les jobs intitulés LabManager VMM Server Background Synchronization Job

La description de l'erreur est assez claire "TF259194: System Center Virtual Machine Manager Admin Console is not installed on your Team Foundation server"
J'ai essayer de supprimer la configuration Lab Management via la console ou l'utilitaire TFSConfig Lab. La même erreur apparaît. Les étapes suivantes permettent de stopper ces erreurs puis supprimer les objets et configuration du Lab Management de TFS 2012.

Installer le SCVMM Administrator Console

Votre compte MSDN vous permet de télécharger le produit "System Center Virtual Machine Manager 2008 R2" (TFS 2012) . Il vous faut l'installer sur une de vos machines Application Tier. Lancer le setup.exe et dans la page d'accueil sélectionner VMM Administrator Console. Suivez les instructions et réaliser l'installation.
Une fois l'installation réalisée les erreurs s'arrêtent. Et vous pouvez à nouveau configurer le Lab Management.

Naviguer vers http://serveurTFS:8080/tfs/_oi/_jobMonitoring puis défiler vers le bas jusqu'au dernier graphique.

Supprimer les objets Lab Management au niveau des collections

Pour cela il suffit d'utiliser la commande suivante  sur chaque collection :

cd "C:\Program Files\Microsoft Team Foundation Server 11.0\Tools"
.\TfsConfig Lab /Delete /CollectionName:NomdelaCollection

Une fois l'ensemble des suppressions réalisées, vous avez alors le message suivant dans la console d'administration :

Supprimer complètement le Lab Management

Cette possibilité ne semble pas offerte par la console d'administration ou l'outil TfsConfig. La commande suivante fonctionne mais ne change pas la configuration en réalité :

.\TfsConfig Lab /Settings /ScVmmServerName:"" /NetworkLocation:"" /IpBlock:"" /DnsSuffix:""

Pour la supprimer, il est possible réaliser une modification directement dans la base de données de configuration, je ne le recommande pas évidemment. L'autre possibilité, plus laborieuse mais utilisant les outils fournis, est de réaliser une nouvelle configuration sur place :

• Se connecter sur un serveur application Tier en tant qu'adminitrateur de TFS et lancer une console PowerShell avec les droits élevés

  cd "C:\Program Files\Microsoft Team Foundation Server 11.0\Tools"

• Arrêter les services TFS et sauvegarder les bases de données

  .\TfsServiceControl quiesce
  .\TfsBackup

• Supprimer les objets Lab Management des collections comme ci-dessus
• Détacher toutes les collections (cela permet de les rendre portables)

  .\TfsConfig Collection /detach /collectionName:NomdelaCollection

• Désinstaller les configurations (pour reconfigurer les Application-tier)

  .\TfsConfig Setup /uninstall:ALL

• Supprimer la base de configuration actuelle,
• Configurer à nouveau le serveur TFS à l'identique, pour configurer sur place lancer

  .\TfsMgmt configure

• Attacher à nouveau toutes les collections

  .\TfsConfig Collection /attach /collectionName:NomdelaCollection /collectionDB:"Machine\SqlInstance;NomBasedeDonnees"

• Vérifier, configurer pour chaque collection l'intégration à SharePoint, Reporting Services, et les contrôleurs et agents de Build

Mais cela n'est en rien gênant sauf si vous souhaitez absolument pouvoir désinstaller SCVMM Administrator Console.

have a nice day.

Changer le compte de domaine associé à une identité dans TFS

Depuis la version TFS 2010, l'ensemble des identités est listé dans la base Tfs_configuration.
Tous les comptes et groupes ayant un droit d'accès à TFS ont automatiquement une identité créée (qu'ils s'y soient un jour connectés ou non). Il n'est pas possible de supprimer ou fusionner des identités. Cependant il est possible de modifier le compte/groupe de domaine associé à une identité.

Pour cela, il suffit d'utiliser la commande suivante sur un des serveurs Application-Tier :

cd "C:\Program Files\Microsoft Team Foundation Server 11.0\Tools"
.\TFSConfig identities /change /fromdomain:olddomain /todomain:newdomain /account:oldlogin /toaccount:newlogin

Si vous migrez de domaine, vous pouvez utiliser la commande simplifiée suivante. Elle permet de changer les comptes/groupes pour toutes les identités listées à condition que les nouveaux logins soient identiques aux anciens (il faut aussi qu'ils soient d'abord créés dans le nouveau domaine).

cd "C:\Program Files\Microsoft Team Foundation Server 11.0\Tools"
.\TFSConfig identities /change /fromdomain:olddomain /todomain:newdomain

Il arrive parfois qu'une nouvelle identité soit créée par erreur, souvent par ricochets via les groupes Windows. Le nouveau compte cible newdomain\newdidier est alors déjà connu dans TFS. La migration de l'ancien compte olddomain\olddidier vers newdomain\newdidier ne fonctionnera pas.

Comme l'utilisateur newdomain\newdidier n'a en fait réalisé aucune action dans TFS, il est facile de supprimer ce doublon en utilisant un compte local temporaire srvTFS\tmpdidier.

cd "C:\Program Files\Microsoft Team Foundation Server 11.0\Tools"
.\TFSConfig identities /change /fromdomain:newdomain /todomain:srvTFS /account:newdidier /toaccount:tmpdidier
.\TFSConfig identities /change /fromdomain:olddomain /todomain:newdomain /account:olddidier /toaccount:newdidier

Affecter le compte intermédiaire srvTFS\tmpdidier à l'identité créée par erreur de newdomain\newdidier permet de supprimer ce dernier de la liste. Il suffit alors de migrer normalement l'identité de olddomain\didier vers newdomain\newdidier.
Lors d'une migration, j'ai eu un problème de synchronisation des comptes au niveau des éléments de travail. Le Job plante sur une identité, l'accès aux éléments de travail n'est alors plus disponible pour certains utilisateurs. Pour l'éviter, il suffit de forcer après le changement d'une identité la synchronisation en lançant le Job correspondant (ne pas changer 2 fois de suite une identité sans exécuter ce job). Un billet de Neno Loje explique comment ici.

Nous avons aussi souvent un serveur SharePoint associé au TFS et les noms de comptes suivent souvent une règle différente en changeant de domaine. Je vous propose un script PowerShell permettant de migrer rapidement les comptes individuellement. 

Param(
     [string] $csvlogins = "C:\mappageLogins.csv",
     [string] $domainOld = "olddomain",
     [string] $domainNew = "newdomain",
     [string] $SharepointWebApp = "http://srvsps"
    )

$TFSConfig = "$Env:ProgramFiles\Microsoft Team Foundation Server 11.0\Tools\TFSConfig.exe"

$loginList=IMPORT-CSV -Path $csvlogins -delimiter ";"

Foreach ($Account in $loginList) {
    $old = $Account.AncienLogin
    $new = $Account.NouveauLogin
    write-output "$domainOld\$old"
    & $TFSConfig identities /change "/fromdomain:$domainOld" "/todomain:$domainNew" "/account:$old" "/toaccount:$new"
    $user = Get-SPUser -web $SharepointWebApp -Identity "$domainOld\$old"
    Move-SPUser -Identity $user -NewAlias "$domainNew\$new" -IgnoreSID -Confirm:$false
}

Le script fonctionne si TFS est installé sur le serveur et les commandlets de SharePoint sont chargées dans la console PowerShell. Pour lister les identités actuelles de TFS, il suffit d'exécuter TFSconfig identities. Ensuite, il vous suffit de créer un fichier CSV avec les colonnes "AncienLogin" et "NouveauLogin" :

AncienLogin;NouveauLogin

didier;newdidier

Comme toujours, soyez prudents, les changements d’identités peuvent avoir des effets de bord. Vous ne devez jamais utiliser ces commandes sur votre instance de production sauf si vous les avez testées sur l’environnement de test au préalable.

have a nice day.

Mise à jour 01/12/2013 : Ajout remarque sur la synchronisation des identités au niveau des éléments de travail.