Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

Exécuter des tests dans votre processus de génération

Vous pouvez utiliser Team Foundation Build pour exécuter des tests automatisés et analyser l'impact des modifications du code sur vos tests dans le cadre de votre processus de génération. Par exemple, vous pouvez définir un processus de génération à utiliser comme exécution de test de vérification de build planifiée régulièrement par votre équipe. Vous pouvez également exécuter des tests automatisés et effectuer des tâches de test à partir de vos processus de génération personnalisés.

Remarque Remarque

Si vous souhaitez déployer votre application dans le cadre de votre processus de génération, vous devez utiliser un flux de travail de déploiement et de test et un environnement lab. Vous pouvez ensuite exécuter des tests automatisés dans le cadre du flux de travail, ou vous pouvez exécuter des tests séparément après la fin du flux de travail. Pour plus d'informations, consultez Flux de travail de génération, de déploiement et de test automatisé.

Voici ce que vous pouvez faire avec Team Foundation Build

Avant d'exécuter des tests dans votre processus de génération, vous devrez peut-être préparer tout d'abord vos tests et votre système de génération.

Préparer vos tests : assurez -vous que votre solution et vos fichiers de test sont archivés dans le contrôle de version. Consultez Utiliser un contrôle de version.

Classez vos tests par catégorie et par ordre de priorité (facultatif) : vous pouvez assigner des catégories et des priorités à vos tests, puis filtrer sur ces attributs lorsque vous les exécutez dans votre build. Vous pouvez ainsi créer une catégorie de test appelée CI, puis spécifier cette catégorie dans vos builds d'intégration continue. Vous pouvez créer une autre catégorie pour vos tests de vérification de build, intitulée bvt, puis spécifier cette catégorie dans les builds planifiées, telles que votre build nocturne. Pour plus d'informations, consultez Définition de catégories de test pour regrouper vos tests, TestCategoryAttribute et PriorityAttribute.

Préparer votre serveur de build : certains genres de test peuvent être exécutés uniquement par un agent de build sur un ordinateur de build qui est configuré de manière spécifique. Par exemple, si vous exécutez les tests codés de l'interface utilisateur, vous devez configurer votre agent de build pour qu'il s'exécute en mode interactif. Avant d'essayer d'utiliser votre processus de génération pour exécuter des tests, assurez-vous que ces derniers peuvent être exécutés sur le serveur de builds que vous prévoyez d'utiliser. Pour plus d'informations, consultez Utilisation de votre agent de build pour l'exécution de tests.

Microsoft Visual Studio doit être installé sur le serveur de builds pour les scénarios suivants :

  • Pour générer un projet de test CPP, vous devez installer Visual Studio Professional ou une version ultérieure.

  • Pour exécuter des tests unitaires ou des tests codés de l'interface utilisateur, vous devez installer Visual Studio Professional ou une version ultérieure.

  • Pour utiliser les adaptateurs de données et de données de diagnostic :

    1. Couverture du code : Visual Studio Premium ou version ultérieure.

    2. Impact des tests : Visual Studio Ultimate.

    3. IntelliTrace : Visual Studio Ultimate.

  • Pour générer des applications modernes sur un ordinateur de build : Visual Studio Ultimate ou Visual Studio Express pour Windows 8 (le système d'exploitation sur le serveur de builds doit être Windows 8).

  • Pour compiler et exécuter des tests pour un projet avec un faux assembly : Visual Studio Ultimate.

Vous pouvez effectuer une ou plusieurs séries de tests dans votre build qui est basée sur le modèle par défaut. Pour chaque série, vous pouvez spécifier les paramètres suivants :

  • quels tests sont exécutés ;

  • quels paramètres sont utilisés pour exécuter les tests ;

  • si la build doit échouer en cas d'échec d'un test.

  1. Dans Team Explorer, choisissez Accueil, puis Builds (raccourci clavier : Ctrl + 0, B).

  2. Dans la page Builds, choisissez Nouvelle définition de build ou ouvrez le menu contextuel pour la build ou la définition de build que vous avez choisie, puis choisissez Modifier la définition de build.

    La fenêtre de définition de build s'affiche.

  3. Sous l'onglet Processus de votre définition de build, sélectionnez la zone Tests automatisés, puis choisissez le bouton de sélection (...).

    La boîte de dialogue Tests automatisés s'affiche.

  4. Effectuez l'une des étapes suivantes :

    • Pour ajouter un ensemble de tests, sélectionnez Ajouter.

    • Pour modifier un ensemble de tests, choisissez-le, puis choisissez Modifier.

    La boîte de dialogue Ajouter/Modifier un test s'affiche.

  5. (Facultatif) Spécifiez le Nom de la série de tests. Ce nom apparaît dans la fenêtre de résultats de la build. Si vous ne spécifiez pas de nom, le système le génère automatiquement.

  6. Si vous voulez que la build échoue si l'un des tests de cette série de tests échoue, cochez la case Faire échouer la build en cas d'échec du test. Si vous n'activez pas cette case à cocher et qu'un test échoue, la build terminée aura le statut Succès partiel.

  7. Spécification de fichier d'assembly de test

    Spécifiez les fichiers binaires qui contiennent les tests à exécuter. Conservez la valeur par défaut (**\*test*.dll) pour que l'agent de build recherche de manière récursive tous les fichiers .dll qui correspondent à *test*.dll dans le sous-répertoire binaries du répertoire de travail de l'agent de build. Vous avez également la possibilité de modifier la spécification de fichier en fonction de vos besoins.

  8. Si vous souhaitez que l'exécution de test collecte et publie des données de couverture du code, affectez à Options la valeur Activer la couverture du code.

    Sinon, vous pouvez utiliser l'option Personnalisé pour spécifier un fichier .runsettings. Pour plus d'informations, consultez Personnalisation de l'analyse de couverture du code.

  9. Dans le menu Plateforme cible sélectionnée pour l'exécution de tests, choisissez x86 pour tester vos binaires 32 bits, ou x64 pour tester vos fichiers binaires 64 bits.

  10. Vous pouvez spécifier des critères pour les tests exécutés.

Vous pouvez spécifier des paires nom/valeur pour filtrer les tests exécutés. Si vous utilisez des catégories de test et des attributs de priorité pour organiser et mettre des priorités à vos tests, vous pouvez filtrer les tests que vous exécutez en utilisant les noms TestCategory et Priority.

Vous pouvez spécifier des catégories de test selon l'une des méthodes suivantes :

  • Spécifiez une paire nom/valeur à inclure. Supposons que vous possédiez une catégorie de test nommée bvt. Vous définiriez Filtre de cas de test à TestCategory=bvt pour exécuter uniquement les tests de cette catégorie.

  • Spécifiez plusieurs catégories de test à l'aide de || (opérateur « or »). Par exemple, vous pouvez spécifier TestCategory=quick||TestCategory=gui pour exécuter les tests qui font partie de la catégorie quick et les tests qui font partie de la catégorie gui.

Si vous devez désactiver temporairement les tests sans supprimer l'ensemble qui les contient, développez le nœud Avancé et affectez à Désactiver les tests la valeur True. Réaffectez la valeur False lorsque vous voulez à nouveau activer les tests.

Vos testeurs et développeurs peuvent avoir besoin de savoir de quelle façon les modifications de code comprises dans une build terminée affectent vos tests. Lorsque vous activez l'analyse d'impact des tests dans une build, le système analyse, puis signale comment les modifications de code ont affecté vos tests dans le rapport de la build terminée.

Pour activer l'analyse d'impact des tests dans un processus de génération basé sur le modèle par défaut

  1. Configurez l'analyse d'impact des tests dans un fichier de paramètres de test.

    Pour plus d'informations, consultez Comment : collecter des données pour vérifier quels tests doivent être exécutés après les modifications de code.

  2. Créer une série de tests configurée pour utiliser le fichier de paramètres de test.

    Pour plus d'informations, consultez Exécuter des tests automatisés plus haut dans cette rubrique.

  3. Développez le nœud Avancé et assurez-vous que le paramètre Analyser l'impact des tests a la valeur True et que Désactiver les tests a la valeur False.

Vous pouvez configurer autant de séries de tests que vous le souhaitez afin de satisfaire les exigences de processus de génération et de test de votre équipe. Par exemple, vous devrez peut-être définir plusieurs séries de tests dans une seule build dans les scénarios suivants :

  • Vous souhaitez utiliser Test Runner de Visual Studio pour tester une solution qui produit des binaires à 32 bits et 64 bits.

  • Vous possédez deux jeux de tests :

    • Un jeu de tests principaux de priorité élevée qui doivent réussir. Vous définissez une série de tests qui inclut une Priorité de test minimale et une Priorité de test maximale de 1. Vous activez la case à cocher Faire échouer la build en cas d'échec du test.

    • Un jeu de tests moins importants que vous voulez exécuter mais qui ne sont pas requis pour que la build soit utilisable. Vous définissez une série de tests qui inclut une Priorité de test minimale de 2 et une Priorité de test maximale de 3. Vous n'activez pas la case à cocher Faire échouer la build en cas d'échec du test.

  • Vous souhaitez exécuter le même jeu de tests avec des paramètres de test différents.

  • Vous voulez que le jeu principal d'assemblys que vous générez soit soumis à une couverture du code. Toutefois, vous possédez un autre jeu d'assemblys d'une source externe qui ne requiert pas de couverture du code. Pour activer ce genre de processus, vous pouvez utiliser deux séries de tests configurées pour utiliser deux groupes de fichiers de paramètres de test.

Votre processus de génération peut exécuter des tests unitaires basés sur des infrastructures de tests unitaires tierces uniquement si vous avez fourni à votre contrôleur de build un accès aux assemblys d'infrastructure tiers.

  1. Recherchez, ou si nécessaire, spécifiez le chemin d'accès du contrôleur de build aux assemblys personnalisés.

  2. Recherchez, ou si nécessaire, créez un mappage du dossier d'assembly personnalisé sur le serveur dans un dossier local de votre espace de travail.

  3. Obtenez un plug-in de test unitaire tiers :

    Adaptateur

    Langage

    Boost

    C++

    Chutzpah

    JavaScript

    Google

    C++

    MbUnit

    C#

    MSpec

    MSpec

    nUnit

    C#

    Outils Python pour Visual Studio

    Python

    Silverlight

    Silverlight

    TSTestAdapter

    TypeScript

    VsNodeTest

    Node.js

    xUnit.net

    C#

    xUnit++

    C++

  4. Renommez le fichier du plug-in .vsix dans un fichier .zip. Par exemple, utilisez l'invite de commandes comme suit :

    C:\Downloads>ren NUnitTestAdapter.vsix NUnitTestAdapter.zip
    
  5. Décompressez le contenu du fichier .zip dans le dossier d'espace de travail local que vous avez mappé dans l'étape 2.

  6. Archivez les fichiers.

    Conseil Conseil

    Pour que les stratégies utilisent des fichiers binaires tiers dans le contrôle de version, consultez Utilisation de fichiers binaires tiers non générés par votre code.

[Visual Studio 2012.3] inclut une amélioration pour les infrastructures de test unitaire tierces pour automatiser leur inclusion dans les définitions de build.

Mise en garde Attention

Vous devrez peut-être installer la version la plus récente des packages NuGet pour l'infrastructure de test unitaire tierce pour vous assurer que l'infrastructure inclut des améliorations de la définition de build.

Activer une infrastructure de test unitaire tierce sur un contrôleur de build – [Visual Studio 2012.1]

  1. Dans l'Explorateur de solutions, ouvrez le menu contextuel du projet de test, puis choisissez Gérer les packages NuGet.

  2. Dans la boîte de dialogue Gérer les packages NuGet, dans la colonne gauche, choisissez En ligne.

  3. Sélectionnez le package NuGet pour l'infrastructure de test unitaire tierce et choisissez Installer.

  4. Une fois l'installation du package de NuGet terminée, sélectionnez Fermer.

  5. Dans l'Explorateur de solutions, ouvrez le menu contextuel de la solution, puis choisissez Ajouter la solution au contrôle de code source.

  6. Vous pouvez maintenant mettre en file d'attente votre build et vos tests avec l'infrastructure de test unitaire tierce s'exécuteront automatiquement.

Si votre équipe a besoin d'un processus de génération avec des fonctions plus profondément personnalisées, vous pouvez exécuter des tests et effectuer d'autres tâches liées aux tests depuis votre processus de génération personnalisé. Pour plus d'informations, consultez :

Utiliser le modèle par défaut pour un processus de build fournit plus d'informations sur la création d'une définition de build basée sur le modèle par défaut. Cette rubrique inclut des informations sur les paramètres de nombre de bits Plateforme que vous pouvez utiliser lors de la compilation votre code.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft