Journée d'un développeur ALM : écriture d'un nouveau code pour un récit utilisateur

Êtes-vous un nouvel utilisateur de Visual Studio Application Lifecycle Management (ALM) et Team Foundation Server (TFS)?Vous demandez-vous comment vous et votre équipe pouvez obtenir l'avantage maximal de la dernière version de ces outils pour générer votre application ?

Effectuez ensuite quelques minutes à la promenade étape par étape dans ce didacticiel à deux chapter et suivez un jour dans les vies de Peter et de Julia, développeurs à la société fictive de Fibres (un de Fabrikam qui fournit de la télévision via câble et des services connexes.Vous verrez des exemples de la façon dont vous pouvez utiliser Visual Studio et TFS au contrôle et à la mise à jour du code, interrompez le travail lorsque vous êtes suspendu, demandez une révision du code, archivez vos modifications, et effectuer d'autres tâches.

L'histoire jusqu'à présent

L'équipe a récemment démarré adoption de Visual Studio et Team Foundation Server pour la gestion du cycle de vie des applications (ALM).Ils ont installé le serveur et les ordinateurs clients, ont créé un journal, organisés une itération, et terminé autre planification nécessaire pour commencer à développer l'application.

Vue d'ensemble de ce chapitre

Peter examine brièvement le journal des travaux en souffrance et sélectionne la tâche qu'il doit travailler à aujourd'hui.Il écrit des tests unitaires pour le code qu'il projette pour développer.En général, il exécute les tests plusieurs fois dans une heure, vous écrivez progressivement des tests plus détaillés et écrivant le code qui les fait passer.Il présente souvent l'interface de son code avec des collègues qui utilisent la méthode qu'il écrit.

[!REMARQUE]

Mes les fonctionnalités de travail et de couverture du code qui sont abordées dans cette rubrique sont uniquement disponibles dans Visual Studio Premium et Visual Studio Ultimate.

Dans cette rubrique

• Passez en revue le backlog personnel et préparer des tâches pour commencer à travailler

• Créer le premier test unitaire

• Créer un stub pour le nouveau code

• Exécuter le premier test

• Acceptez l'API

• Rouge, vert, refactoriser …

• Couverture du code

• Quand avons-nous terminés ?

• Archivage les modifications

Passez en revue le backlog personnel et préparer des tâches pour commencer à travailler

Dans Team Explorer, Peter ouvre la page Mon travail .L'équipe s'est mise d'accord que, pendant le sprint actuel, Peter fonctionne en mode de facture Evaluate, un élément de priorité élevée dans le journal des travaux en souffrance du produit.Peter décide de commencer par les fonctions mathématiques d'implémenter, une tâche enfant de l'élément de priorité élevée journal.Il fait glisser cette tâche de la liste Éléments de travail disponibles dans la liste éléments de travail et modifications en cours .

Pour passez en revue le backlog personnel et préparer des tâches pour commencer à travailler

1. Dans Explorateur d'équipes:

   1. Si vous n'êtes pas déjà connecté au projet d'équipe dans lequel vous souhaitez travailler, connectez-vous au projet d'équipe.

   2. Sélectionnez Accueil, et ensuite sélectionnez Mon Travail.

2. Dans la page Mon travail , faites glisser la tâche de la liste Éléments de travail disponibles à la section éléments de travail en cours .

   Vous pouvez également sélectionner une tâche dans la liste Éléments de travail disponibles puis choisir Démarrer.

Plan de travail incrémentiel d'ébauche

Peter développe généralement le code d'une série de petites.Chaque étape généralement ne dure pas plus d'une heure, et peut prendre seulement dix minutes.Dans chaque étape, il écrit un test unitaire et modifie le code qu'il développe afin qu'il passe le nouveau test, en plus de les tests qu'il a déjà écrits.Parfois il écrit le nouveau test avant de modifier le code, et parfois il modifie le code avant d'écrire le test.Parfois il refactorise.En d'autres termes, il améliore simplement le code sans ajouter de nouveaux tests.Il ne change jamais un test qui passe, à moins qu'elle décide qu'il n'a pas correctement représenté une spécification.

À la fin de chaque petit pas, il effectue tous les tests unitaires qui sont appropriés à cette région du code.Il ne considère pas l'étape complète jusqu'à ce que chaque test réussisse.

Toutefois, il ne vérifie pas le code dans Team Foundation Server jusqu'à ce qu'il a terminé la tâche entière.

Peter note un plan approximatif pour cette séquence de petites étapes.Il sait que les détails et l'ordre exact de les ultérieurs changeront probablement qu'il fonctionne.Voici sa liste initiale des étapes à suivre pour cette tâche particulière :

1. Créez la méthode de test stub-, c'est-à-dire que la signature de la méthode.

2. Contenu un événement classique spécifique.

3. Testez la large gamme.Assurez -vous que le code répond correctement à une plage étendue de valeurs.

4. Exception sur négatif.Cas correctement avec des paramètres incorrects.

5. Couverture du code.Assurez -vous qu'au moins 80% du code est testé par les tests unitaires.

Certains de ses collègues écrivent ce genre de plan dans les commentaires dans leur code de test.D'autres uniquement mémorisent leur plan.Peter trouve qu'il est utile d'écrire la liste d'étapes dans le champ de description de l'élément de travail Tâche.S'il doit désactiver temporairement une tâche plus urgente, il sait où rechercher la liste lorsqu'il peut retourner à celui-ci.

Créer le premier test unitaire

Peter démarre en créant un test unitaire.Il commence par le test unitaire dans la mesure où il souhaite écrire un exemple de code qui utilise sa nouvelle classe.

Il s'agit du premier test unitaire pour la bibliothèque de classes, il est le test, afin qu'il crée un nouveau projet de test unitaire.Il ouvre la boîte de dialogue Nouveau projet et choisit Visual C#, Test, puis projet de test unitaire.

Le projet de test unitaire fournit un fichier C# dans lequel il peut entrer son exemple.À ce stade, il veut seulement illustrer l'une de ses nouvelles méthodes qui sera appelée :

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Fabrikam.Math.UnitTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        // Demonstrates how to call the method.
        public void SignatureTest()
        {
            // Create an instance:
            var math = new Fabrikam.Math.LocalMath();

            // Get a value to calculate:
            double input = 0.0;

            // Call the method:
            double actualResult = math.SquareRoot(input);

            // Use the result:
            Assert.AreEqual(0.0, actualResult);
        }
    }
}

Il écrit l'exemple dans une méthode de test pour, avant qu'il a entré son code, il souhaite l'exemple pour utiliser.

Pour créer un projet de test unitaire et des méthodes

Généralement créer un nouveau projet de test pour chaque projet est testé.S'il existe déjà un projet de test, vous pouvez ajouter les classes et les nouvelles méthodes d'essai.

Cette procédure utilise l'infrastructure de Test unitaire Visual Studio, mais vous pouvez également utiliser des infrastructures à partir d'autres fournisseurs.L'explorateur de tests fonctionne aussi bien avec d'autres infrastructures, si vous installez l'adaptateur approprié.

• Créez un projet de test, s'il n'existe pas déjà.

  • Dans la boîte de dialogue Nouveau projet , choisissez un langage tel que Visual Basic, Visual C++ ou Visual C#.Choisissez Test et ensuite projet de Test unitaire.

• Ajoutez vos tests à la classe de test qui est fournie.Chaque test unitaire est une méthode.

  Chaque test unitaire doit être préfixé par l'attribut d' TestMethod , et la méthode de test unitaire doit avoir un paramètre.Vous pouvez utiliser n'importe quel nom que vous souhaitez pour une méthode de test unitaire :

          [TestMethod]
          public void SignatureTest()
          {...}
  

      <TestMethod()>
      Public Sub SignatureTest()
      ...
      End Sub
  

• Chaque méthode de test doit appeler une méthode de classe d' Assert , pour indiquer si elle a réussi ou a échoué.En général, vous vérifiez que les résultats attendus et réels d'une opération sont égales :

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• Méthodes d'essai peuvent appeler d'autres méthodes ordinaires qui n'ont pas l'attribut TestMethod.

• Vous pouvez organiser vos tests en plusieurs classes.Chaque classe doit être préfixé par l'attribut TestClass.

  [TestClass]
  public class UnitTest1
  { ... }
  

  <TestClass()>
  Public Class UnitTest1
  ...
  End Class
  

Pour plus d'informations sur l'écriture des tests unitaires en C++, consultez Écriture de tests unitaires pour C/C++ à l'aide de l'infrastructure de tests unitaires Microsoft pour C++.

Créer un stub pour le nouveau code

Ensuite, Peter crée un projet Bibliothèque de classes pour son nouveau code.Il existe désormais un projet pour le code en cours de développement et un projet pour les tests unitaires.Il ajoute une référence de projet au projet de test au code en cours de développement.

Dans le nouveau projet, il ajoute la nouvelle classe et une version minimale de la méthode qui permet au moins testée pour générer avec succès.Le moyen le plus rapide pour ce faire consiste à générer un stub de classe et la méthode à partir de l'appel dans le test.

        public double SquareRoot(double p)
        {
            throw new NotImplementedException();
        }

Pour générer des classes et méthodes depuis des tests

Tout d'abord créer le projet dans lequel vous souhaitez ajouter la nouvelle classe, sauf si elle existe déjà.

Pour générer une classe.

1. Placez le curseur sur un exemple de la classe que vous voulez générer, par exemple, LocalMath.Dans le menu contextuel, sélectionnez Générer le code, Nouveau type.

2. Dans la boîte de dialogue Nouveau type, affectez Projet au projet de Bibliothèque de classes.Dans cet exemple, c'est Fabrikam.Math.

Pour générer une méthode.

• Placez le curseur sur un appel à la méthode, par exemple, SquareRoot.Dans le menu contextuel, sélectionnez Générer le code, Stub de méthode.

Exécuter le premier test

Peter génère et exécute le test en appuyant sur CTRL+R, puis sur T.Le résultat de test affiche un indicateur rouge et le test s'affiche dans la liste Échec des tests.

Il apporte une modification simple pour le code :

       public double SquareRoot(double p)
        {
            return 0.0;
        }

Il exécute à nouveau le test et il réussit :

Pour exécuter des tests unitaires

• Dans le menu Test , choisissez Exécuter, Tous les tests.

  - ou -

• Si l'explorateur de tests est ouvert, sélectionnez Exécuter tout.

  - ou -

• Placez le curseur dans un fichier de code de test et appuyez CTRL+R, T.

• Si un test s'affiche sous Échec des Tests.

  Ouvrez le test, par exemple, en double-cliquant sur le nom.

  Le point à partir duquel le test a échoué s'affiche.

Pour afficher une liste complète des tests, choisissez Afficher tout.Pour retourner au résumé, choisissez la vue ACCUEIL .

Pour afficher les détails d'un résultat de test, sélectionnez le test dans l'explorateur de tests.

Double-cliquez surPour accéder au code d'un test, double cliquez sur le test dans l'explorateur de tests, ou choisissez Ouvrir un test dans le menu contextuel.

Pour déboguer un test, ouvrez le menu contextuel pour un ou plusieurs tests, puis choisissez Déboguer les tests sélectionnés.

Toggle Exécuter des tests après générationdePour exécuter des tests en arrière-plan lorsque vous générez la solution, .Tests qui ont échoué sont exécutés en premier.

Acceptez l'Interface

Peter appelle sa collègue Julia sur Lync et partage son écran.Elle utilisera son composant.Il montre l'exemple initial.

Julia pense que l'exemple est OK, mais commentes, « de nombreuses fonctions passeraient ce test. »

Réponses de Peter, « le premier test est juste pour vous assurer que le nom et les paramètres de la fonction sont corrects.Maintenant nous pouvons écrire un test qui capture la spécification principale de cette fonction. »

Jeu ils écrivent le test suivant :

  
      [TestMethod]
        public void QuickNonZero()
        {
            // Create an instance to test:
            LocalMath math = new LocalMath();

            // Create a test input and expected value:
            var expectedResult = 4.0;
            var inputValue = expectedResult * expectedResult;

            // Run the method:
            var actualResult = math.SquareRoot(inputValue);

            // Validate the result:
            var allowableError = expectedResult/1e6;
            Assert.AreEqual(expectedResult, actualResult, allowableError,
                "{0} is not within {1} of {2}", actualResult, allowableError, expectedResult);
        }

Conseil

Pour cette fonction, Peter utilise le premier développement de test, dans lequel il écrit en premier le test unitaire pour une fonctionnalité, puis écrit le code qui répond au test.Dans d'autres cas, il détecte que cette pratique n'est pas réaliste, de sorte à la place, il écrit les tests après son écrire du code.Mais il considère très important pour écrire l'unité test si avant ou après code parce qu'ils contiennent le code stable.

Rouge, vert, refactoriser…

Peter suit un cycle dans lequel il écrit à plusieurs reprises un test et le confirme qu'il, écrit le code n'est pas passer le test, puis considère refactorisation-, c'est-à-dire améliorant le code sans modifier les tests.

Rouge

Peter appuie sur CTRL+R, puis sur T pour exécuter le test qu'il a créé avec Julia.Une fois qu'il écrire tout test, il s'exécute toujours il pour vous assurer qu'il échoue avant d'écrire du code qui le fait passer.C'est une pratique qu'il a apprise après qu'il a oublié de définir des assertions dans certains tests il avait écrits.Voyant le résultat échec lui affecte la confiance qui lorsqu'il le fait passer, le résultat du test correct indique qu'une spécification a été satisfaite.

Une autre pratique est utile de définir Exécuter des tests après génération.Cette option exécute les tests en arrière-plan chaque fois que vous générez la solution, afin d'obtenir un rapport continuel de l'état de test de votre code.Peter était au premier méfiant qu'elle peut effectuer à Visual Studio lent pour répondre, mais il détecte que cela se produit rarement.

Vert

Peter entré premier test au code de la méthode qu'il développe :

    public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate;
                estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }
        

Peter exécute les tests de nouveau et tous les tests réussissent :

Refactorisation

Maintenant que le code remplit sa fonction principale, la de Peter au code pour rechercher un moyen de le faire effectuent mieux, ou pour simplifier pour modifier dans le futur.Il s'aperçoit qu'il peut réduire le nombre de calculs effectués dans la boucle :

public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate; 
                estimate = (estimate + x / estimate) / 2;
                //was: estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }

Il vérifie que les tests réussissent toujours :

Conseil

Chaque modification apportée lorsque vous développez le code doit être une refactorisation ou une extension : Signifie que vous ne modifiez pas les tests car vous n'ajoutez pas de nouvelles fonctionnalités de refactorisation. L'extension signifie ajouter des tests et apporter des modifications du code nécessaires pour passer les tests existants et nouveaux. Si vous mettez à jour le code existant aux spécifications qui ont changé, vous supprimerez également les tests anciens qui ne représentent les spécifications plus récentes. Évitez de modifier les tests qui ont déjà réussit.Au lieu de cela, ajoutez de nouveaux tests.Entrez uniquement les tests qui représentent une vraie spécification. Exécutez les tests après chaque modification.

… et répéter

Peter reprend sa série d'étapes d'extension et de refactorisation, à l'aide de sa liste de petites comme guide sommaire.Il n'effectue pas toujours une étape de refactorisation après chaque extension, et il effectue parfois plusieurs étape de refactorisation à la suite.Mais il s'exécute les tests unitaires après chaque modification du code.

Quelquefois il ajoute un test qui ne requiert aucune modification au code, mais qui ajoute à la confiance que son code fonctionne correctement.Par exemple, il souhaite vérifier que la fonction s'exécute sur une large gamme d'entrée.Il écrit des tests, tels que celui-ci :

        [TestMethod]
        public void SqRtValueRange()
        {
            LocalMath math = new LocalMath();
            for (double expectedResult = 1e-8;
                expectedResult < 1e+8;
                expectedResult = expectedResult * 3.2)
            {
                VerifyOneRootValue(math, expectedResult);
            }
        }
        private void VerifyOneRootValue(LocalMath math, double expectedResult)
        {
            double input = expectedResult * expectedResult;
            double actualResult = math.SquareRoot(input);
            Assert.AreEqual(expectedResult, actualResult, expectedResult / 1e6);
        }

Ce test réussit la première fois qu'il fonctionne :

Vérifier que ce résultat n'est pas une erreur, il introduit temporairement une petite erreur dans son test pour le faire échouer.Après avoir observé l'échec, il résout à nouveau.

Conseil
Faites toujours un test échoue avant de le sauf passer.

Exceptions

Peter se déplace maintenant à écrire des tests pour les entrées exceptionnelles :

[TestMethod]
        public void RootTestNegativeInput()
        {
            LocalMath math = new LocalMath();
            try
            {
                math.SquareRoot(-10.0);
            }
            catch (ArgumentOutOfRangeException)
            {
                return;
            }
            catch
            {
                Assert.Fail("Wrong exception on negative input");
                return;
            }
            Assert.Fail("No exception on negative input");
        }

Ce test met le code dans une boucle.Il doit utiliser le bouton Annuler dans l'explorateur de tests.Ceci termine le code dans les 10 secondes.

Peter veut s'assurer qu'une boucle infinie peut se produire pas sur le serveur de build.Bien que le serveur applique un délai d'attente à une passe entière, il s'agit d'un délai d'attente très long, et provoquerait le délai partie.Par conséquent, il ajoute un délai d'expiration explicite à ce test :

        [TestMethod, Timeout(1000)]
        public void RootTestNegativeInput()
        {...

Le délai d'expiration explicite fait le test échoue.

Peter met ensuite à jour le code pour traiter ce cas exceptionnel :

       public double SquareRoot(double x)
        {
            if (x <= 0.0) 
            {
                throw new ArgumentOutOfRangeException();
            }

Régression

Le test réussit, mais il existe une régression.Un test qui a réussi maintenant échec :

Peter trouve et corrige l'erreur :

      public double SquareRoot(double x)
        {
            if (x < 0.0)  // not <=
            {
                throw new ArgumentOutOfRangeException();
            }

Une fois qu'il est fixe, tous les tests réussissent :

Conseil
Vérifiez toutes les séries de tests après chaque modification apportée au code.

Couverture du code

À intervalles pendant son travail, et enfin avant qu'il archive le code, Peter obtient un rapport Couverture du code.Cela indique quelle quantité de code a été testé par les tests.

l'équipe de Peter vise pour la couverture au moins de 80%.Ils détendent cette spécification du code généré, parce qu'il peut être difficile d'accomplir une couverture élevée pour ce type de code.

Une bonne couverture n'est pas garantie que les fonctionnalités complètes du composant a été testée, et il ne garantit pas que le code s'exécutera pour chaque plage de valeurs d'entrée.Toutefois, il existe une corrélation assez proche entre la couverture des lignes de programmation et la couverture de l'espace comportemental d'un composant.Par conséquent, la bonne couverture améliore la confiance de l'équipe qu'ils testent la majeure partie du comportement qu'ils doivent.

Pour obtenir un rapport de couverture du code, dans le menu Tests , choisissez Exécuter, Analysez la couverture du code pour tous les tests.Réexécutez ensuite tous les tests.

Peter obtient une couverture total de 86%.Lorsqu'il augmente le total dans le rapport, il indique que le code qu'il a développe la couverture de 100%.Cela s'avère satisfaite, car la note est important pour le code sous test.Les sections non couverts sont effectivement dans les tests eux-mêmes.En basculant le bouton Coloration de couverture du code show , Peter peut voir quelles parties du code de test n'ont pas été testées.Toutefois, elle décide que ces sections sont sans importance de la couverture car ils sont dans le code de test et seraient uniquement utilisées si une erreur est détectée.

Pour vérifier qu'un test spécifique atteint dans les branches spécifiques du code, vous pouvez définir Coloration de couverture du code show puis exécuter le test à l'aide de la commande Exécuter dans le menu contextuel.

Quand avons-nous terminés ?

Peter continue de mettre à jour le code à petit pas jusqu'à ce qu'il soit satisfait de:

• Tous les test unitaires disponibles passent

  Dans un projet avec un grand ensemble de tests unitaires, Il peut être difficile pour le développeur d'attendre l'exécution des ses derniersAu lieu de cela, le projet opère un service de réservation fermé, dans lequel tous les tests automatisés sont exécutés pour chaque jeu de réservations archivé avant qu'il est fusionné dans l'arborescence source.L'archivage est rejeté si la série échoue.Cela permet au développeur pour exécuter un jeu minimal de tests unitaires sur son propre ordinateur, puis reprend l'autre travail, sans exécuter le risque d'arrêter la génération.Pour plus d’informations, consultez Définir un processus de génération d'archivage contrôlé pour la validation des modifications.

• La couverture du code satisfait les normes de l'équipe.75% est un prérequis type de projet.

• Ses tests unitaires simulent chaque aspect du comportement requis, y compris les entrées standard et exceptionnelles.

• Son code est facile à comprendre et à étendre.

Lorsque tous ces critères sont terminés, Peter est prêt à charger son code dans le source control.

Principes du développement de code à des tests unitaires

Peter applique les principes suivants lorsqu'il développe le code:

• Développez les tests unitaires avec le code, et les exécuter fréquemment pendant le développement.Les tests unitaires représentent les spécifications de votre composant.

• Ne modifiez pas les tests unitaires, à moins que les spécifications ont changé ou les tests étaient erronés.Ajoutez de nouveaux tests progressivement à mesure que vous étendez les fonctionnalités du code.

• Faites en sorte que pour au moins 75% de votre code soit par les tests.Examinez les résultats de couverture du code à intervalles, et avant que vous chargiez votre code source dans le source control.

• Archivez vos tests unitaires avec le code, afin qu'ils peuvent être exécutés par les générations continues ou régulières du serveur.

• Lorsque cela est possible, pour chaque partie de fonctionnalité, écrivez le test unitaire en premier.Cette opération avant que vous avez développé le code qui le contenu.

Archivage des modifications

Avant d'archiver ses modifications, Peter utilise de nouveau Lync pour partager son écran avec son collègue Julia qui peut officieusement et interactivement examiner avec lui ce qu'il a créé.Les tests continuent à être le centre de leur discussion car Julia est principalement intéressée par ce que le code fait, pas son fonctionnement.Julia valide que ce que Peter a écrit répond à ses besoins.

Peter archivent toutes les modifications qu'il a apportées, y compris les tests et le code, et les associent à la tâche qu'il a terminée.L'archivage met en file d'attente le système automatisé de Build de l'équipe pour valider les modifications à l'aide deu processus de génération de CI de l'équipe.Ce processus de génération aide l'équipe à réduire les erreurs dans leur code en générant et testant dans un environnement propre séparé de leur machines de développement chaque modification de l'équipe.

Peter est notifié lorsque la génération est terminée.Dans la fenêtre des résultats de build, il constate que la génération a réussi et tous les tests ont réussi.

Pour archiver les modifications

1. Dans la barre de menu, choisissez Affichage, cliquez sur Team Explorer.

2. Dans Team Explorer, choisissez Accueil, puis choisissez Mon travail.

3. Dans la page Modifications en attente, choisissez Archiver.

4. Passez en revue le contenu de la page Modifications en attente pour vous assurer que:

   • Toutes les modifications appropriées sont répertoriées dans Modifications incorporées

   • Tous les éléments de travail pertinents sont répertoriés dans Les éléments de travail associés.

5. Spécifiez un Commentaire pour aider votre équipe à comprendre le but de ces modifications lorsqu'ils regardent l'historique de contrôle de version des fichiers et des dossiers modifiés.

6. Choisissez Archiver.

Pour intégrer continuellement le code

Pour plus d'informations sur le processus de build exécutant des tests, consultez Définir un processus de génération pour prendre en charge une intégration continue.Après avoir installé ce processus de génération, vous pouvez choisir d'être notifié sur les résultats des builds d'équipe.

Pour plus d’informations, consultez Exécuter, surveiller et gérer des builds.

(Interrompez ensuite le travail, résolvez un bogue, puis routez une révision du code)