Dépannage de l'exécution de tests

Si un test ne s'exécute pas, vous pouvez analyser l'échec en vérifiant l'environnement de test, y compris la manière dont le test est configuré et les paramètres de tests actifs. Dans certains cas, tels que ceux en rapport avec le déploiement, les échecs sont indépendants du type de test. Dans d'autres cas, le type de test détermine les éléments à étudier et la manière à employer. Pour obtenir des conseils d'investigation par type de test, consultez Détails par type de test.

Les erreurs qui impliquent des tests vous sont signalées à l'un des deux niveaux suivants :

• Erreurs de niveau test. Dans la fenêtre des résultats du test, vous pouvez double-cliquer sur le résultat du test ou cliquer avec le bouton droit sur le résultat du test, puis sélectionner Afficher les détails des résultats des tests. Cela affiche une page [Détails] de test qui affiche des messages d'erreur et d'autres détails, selon le type de test, tels que des informations de trace de la pile pour les tests unitaires. Une erreur de délai d'attente de test constitue un exemple d'erreur de niveau test ; elle se produit si la limite de délai d'attente du test est atteinte.

• Erreurs de niveau d'exécution. Les erreurs de niveau d'exécution, qui incluent les erreurs de configuration de séries de tests, sont signalées par le biais de la fenêtre Résultats des tests. Lorsqu'une erreur de niveau d'exécution se produit, un lien apparaît sur la barre d'état de la fenêtre Résultats des tests. Un clic sur ce lien permet d'afficher davantage de détails à propos de l'erreur sur la page Série de tests [Détails]. Vous pouvez également afficher la page Série de tests [Détails] en cliquant sur Détails de l'exécution dans la barre d'outils de la fenêtre Résultats des tests. Une erreur de délai d'attente d'exécution constitue un exemple d'erreur de niveau d'exécution ; elle se produit si la limite de délai d'attente d'exécution est atteinte.

Tous les problèmes n'entraînent pas l'échec d'exécution d'un test. Une fois que vous avez choisi d'obtenir des données de couverture du code, l'exécution des tests peut générer un avertissement si certains paramètres de génération ont été sélectionnés pour votre projet. Pour plus d'informations, consultez Utilisation du paramètre de génération AnyCPU lors de l'obtention de données de couverture du code.

Erreurs de déploiement

Certaines erreurs peuvent être rencontrées pour tout test qui peut s'exécuter automatiquement, ce qui signifie tout type de test autre que les tests manuels. Ces erreurs sont souvent liées au déploiement de tests. Lorsqu'un test est déployé, le fichier qui le contient est copié dans un autre dossier, à un emplacement sur l'ordinateur local ou un ordinateur distant.

Pour les tests unitaires, par exemple, le fichier .dll qui a été généré à partir du projet de test est le fichier qui doit être déployé. Si ce fichier binaire ne peut pas être déployé, tout test unitaire qu'il contient est marqué immédiatement comme Échec dans la fenêtre Résultats des tests lorsque vous l'exécutez.

Pour corriger cette erreur, vérifiez que les fichiers sont disponibles sur votre ordinateur local et qu'il n'y a pas eu d'erreurs de build la dernière fois que vous avez régénéré vos binaires de test.

Il n'y a pas que les fichiers binaires qui peuvent être déployés. Vous pouvez spécifier qu'un fichier particulier, tel qu'un fichier de données, est requis par un test et doit par conséquent être déployé avec le test. Au moment du déploiement, si ce fichier est introuvable car il a été déplacé ou supprimé, le test ne peut pas s'exécuter correctement et une erreur se produit. Consultez également Détails par type de test pour plus d'informations sur cette erreur quant aux tests génériques.

Pour analyser cette erreur, notez d'abord les fichiers et dossiers spécifiés sur la page Déploiement de la boîte de dialogue utilisée pour modifier les paramètres de test. Pour plus d'informations, consultez Créer des paramètres de test pour exécuter des tests automatisés à partir de Visual Studio. Vérifiez ensuite ces fichiers et dossiers sur le disque afin de vous assurer qu'ils sont présents et que leurs noms sont identiques.

Votre solution peut avoir plusieurs fichiers de paramètres de tests. Si c'est le cas, veillez à examiner les paramètres de tests qui étaient actifs lorsque l'erreur de test s'est produite. Pour déterminer quels paramètres de tests étaient actifs, examinez cette série de tests sur la page Détails de la série de tests.

Pour plus d'informations sur les fichiers de paramètres de test actifs, consultez Comment : appliquer des paramètres de test à partir de Microsoft Visual Studio.

Erreurs dans le signalement des résultats de tests distants

Lorsque vous exécutez des tests à distance, les résultats des tests peuvent ne pas s'afficher. Cette erreur est probablement liée à la nature distante de la série de tests.

Tout comme les résultats des séries de tests locales, les résultats des séries de tests distantes vous sont signalés localement. Le signalement de certains résultats de tests distants dépend de la capacité de Visual Studio Ultimate à copier les fichiers de résultats de tests générés de l'ordinateur de test distant vers votre ordinateur local.

Si des erreurs se produisent avec les résultats de tests distants, commencez par déterminer si la connexion réseau entre l'ordinateur distant et l'ordinateur sur lequel vous exécutez Visual Studio a été interrompue.

Pour plus d'informations, consultez Configuration d'ordinateurs de test pour exécuter des tests ou collecter des données.

Erreurs d'instrumentation

Pour activer la création de rapport de couverture du code, les fichiers binaires qui sont testés doivent être instrumentés puis déployés avant que des tests soient exécutés sur eux.

La non-instrumentation du fichier binaire provoque l'échec de la création de rapport de couverture du code. Une fois la série de tests terminée, la page Détails de la série de tests affiche un message d'erreur qui signale que le rapport de la couverture du code n'a pas pu être créé ainsi que la cause de l'échec.

Les causes possibles de l'échec d'instrumentation d'un fichier binaire sur place sont son marquage en lecture seule ou son utilisation actuelle par un autre processus. Pour corriger l'erreur liée à un fichier binaire en lecture seule, examinez d'abord les attributs du fichier binaire afin de vous assurer qu'il est accessible en écriture. Pour savoir quels fichiers binaires vérifier, ouvrez la page Couverture du code des paramètres de tests actifs ; c'est à cet endroit que vous avez spécifié les fichiers pour l'instrumentation. Pour plus d'informations, consultez Comment : obtenir des données de couverture du code.

Une autre cause d'échec de couverture du code lors du recours à une instrumentation sur place peut se produire lorsque vous utilisez un ou plusieurs tests unitaires avec un test manuel. Pendant le test manuel, le testeur exécute le code de production qui est testé. Si le testeur appuie sur F5 ou CTRL+F5 pour démarrer ou déboguer le code, le fichier exécutable du projet est régénéré, ce qui supprime l'instrumentation.

Assurez-vous également qu'aucun autre processus n'utilise le fichier binaire. Par exemple, assurez-vous que le fichier n'est pas ouvert dans une autre instance de Visual Studio.

Lorsque vous instrumentez des Assemblys avec nom fort, vous pouvez rencontrer d'autres erreurs liées à la nouvelle signature de l'assembly. Pour plus d'informations, consultez Instrumentation et nouvelle signature d'assemblys.

Utilisation du paramètre de génération AnyCPU lors de l'obtention de données de couverture du code

Vous ne pouvez obtenir des données de couverture du code que lorsque vous testez du code dans des assemblys 32 bits. Pour garantir cette condition, définissez une propriété de génération particulière :

• Pour les projets C#, affectez la valeur x86 à la plateforme cible. Pour plus d'informations, consultez Comment : définir les propriétés de la génération (C#).

• Pour les projets Visual Basic, affectez la valeur x86 à l'unité centrale cible. Pour plus d'informations, consultez Paramètres avancés du compilateur, boîte de dialogue (Visual Basic).

Si vous générez votre projet avec la valeur AnyCPU, les tests exécutés sur l'assembly obtenu produisent des données de couverture du code, mais la série de tests génère également un avertissement. Vous pouvez consulter le texte de l'avertissement sur la page Détails de la série de tests :

Avertissement VSP2013 : L'instrumentation de cette image requiert que cette dernière soit exécutée en tant que processus à 32 bits. Les indicateurs d'en-tête du CLR ont été mises à jour pour refléter cette condition.

Cet avertissement signifie que l'assembly a été recompilé avec la propriété x86 appliquée pour obtenir des données de couverture du code pendant cette série de tests. Pour éviter cet avertissement, compilez les assemblys pour lesquels vous souhaitez des données de couverture du code avec le paramètre x86.

L'exécution de tests unitaires peut verrouiller un assembly de test C++/CLI

Vous pouvez rencontrer une situation dans laquelle le moteur d'exécution de tests ouvre et verrouille un assembly dans votre projet de test. Lorsque cela arrive, vous ne pouvez pas, par exemple, enregistrer les modifications effectuées dans l'assembly. Ce problème peut se produire dans les situations suivantes :

• Cas 1 : vous avez désactivé le déploiement de votre projet de test, ProjetTestA. ProjetTestA a été compilé en C++/CLI. Le code de ProjetTestA définit une classe d'attributs et cet attribut décore au moins l'une des méthodes de test de ProjetTestA. À ce stade, lorsque vous exécutez des tests unitaires dans ProjetTestA, le moteur d'exécution de tests ouvre ProjetTestA.DLL et peut le quitter dans un état verrouillé.

• Cas 2 : votre projet de test, ProjetTest1, contient une DLL qui a été compilée à partir d'un deuxième projet de test, ProjetTest2. ProjetTest2 a été compilé en C++/CLI. Le code de ProjetTest2 définit une classe d'attributs et cet attribut décore au moins l'une des méthodes de test de ProjetTest2. À présent, lorsque vous exécutez des tests unitaires dans ProjetTest1, le moteur d'exécution de tests ouvre ProjetTest2.DLL et peut le quitter dans un état verrouillé.

Dans ces deux cas, la solution peut être composée de deux parties. En premier lieu, exécutez les étapes suivantes.

1. Dans le menu Outils, sélectionnez Options.

   La boîte de dialogue Options s'ouvre.

2. Développez Outils de test et cliquez sur Exécution de tests.

3. Sous Performances, désactivez la case à cocher en regard de Maintenir le fonctionnement du moteur d'exécution des tests entre les séries de tests.

Après avoir effectué ces étapes, si le problème persiste, procédez comme suit :

Modifiez votre code afin que le projet de test compilé en C++/CLI n'ait pas à être chargé dans l'AppDomain par défaut. Une façon de faire ceci consiste à déplacer les définitions des attributs personnalisés que vous utilisez dans un assembly séparé implémenté en C#.

Détails par type de test

Certaines erreurs se produisent fréquemment ou principalement pendant que vous exécutez des types de tests particuliers, comme décrit dans cette section.

• Tests ordonnés Les erreurs rencontrées avec les tests ordonnés impliquent souvent le déploiement de fichiers. Pour que le moteur de test puisse exécuter un test ordonné, il doit rechercher puis déployer tous les fichiers de test de tous les tests contenus, en plus de tous les autres fichiers requis. La non-exécution de cette opération pour tout test provoque une erreur.

• Tests génériques Des erreurs de déploiement peuvent également se produire lorsque vous exécutez des tests génériques. Vous pouvez spécifier des fichiers à déployer pour les tests génériques de deux manières : sur la page Déploiement des paramètres de tests et sur la page de création du test générique. Le test peut échouer si vous négligez de répertorier tous les fichiers nécessaires ou si les fichiers sont introuvables aux emplacements spécifiés.

  Ces deux manières différentes de déployer des fichiers provoquent l'apparition d'erreurs à différents niveaux. Si l'erreur de déploiement est liée à un fichier spécifié dans la page de création du test générique, elle fera surface au niveau du test. Si l'erreur de déploiement est liée à un fichier spécifié dans les paramètres de tests, elle apparaîtra au niveau de la série de tests.

Voir aussi

Tâches

Comment : définir des limites de temps pour l'exécution des tests

Concepts

Instrumentation et nouvelle signature d'assemblys

Examen des résultats des tests