WexLogger
WexLogger fournit une API cohérente pour la journalisation qui couvre le code natif, le code managé et le script. Il est également mis à l’échelle depuis l’exécution de tests unitaires dans une invite de commandes jusqu’aux tests de contraintes long-courriers.
Journalisation via Verify Framework
La plupart des journaux dans un cas de test doivent être effectuées via l’infrastructure Verify . Cela garantit que les tests sont créés de manière plus claire, plus séquentielle et lisible par l’homme. Toutefois, dans certains cas, les auteurs de tests constatent qu’ils ont besoin d’un contrôle plus précis sur ce qui est écrit dans les journaux : d’où la nécessité de l’API WexLogger.
Journalisation dans TAEF
Pour les cas de test s’exécutant dans TAEF, l’auteur du test n’a besoin d’aucune initialisation de l’enregistreur d’événements. Vous pouvez immédiatement commencer à utiliser l’API Log qui est exposée au langage dans lequel vous créez vos tests.
Dans le code C++ natif, il se présente comme suit :
using namespace WEX::Logging;
using namespace WEX::Common;
Log::Comment(L"Rendering to the BufferView");
Log::Comment(L"Render succeeded");
Log::Comment(String().Format(L"Look, a number! %d", aNumber));
#define LOG_OUTPUT(fmt, ...) Log::Comment(String().Format(fmt, __VA_ARGS__))
LOG_OUTPUT(L"Look, a number! %d", aNumber);
Dans le code managé, il se présente comme suit :
using WEX.Logging.Interop;
Log.Comment("Rendering to the BufferView");
Log.Comment("Render succeeded");
Dans JScript, il se présente comme suit :
var log = new ActiveXObject("WEX.Logger.Log");
log.Comment("Rendering to the BufferView");
log.Comment("Render succeeded");
Journalisation en dehors de TAEF
La majeure partie du temps, l’initialisation et l’achèvement de la journalisation seront effectuées par TAEF, de sorte que wexLogger sera prêt à être utilisé pendant la durée du cas de test, comme indiqué ci-dessus, et se terminera correctement. Toutefois, si un client souhaite utiliser WexLogger en dehors de TAEF, il est chargé d’appeler manuellement LogController ::InitializeLogging() et LogController ::FinalizeLogging(). Cette exigence existe uniquement pour le code natif et managé ; les scripts n’ont pas cette exigence supplémentaire. Pour plus d’informations sur l’API LogController, consultez le tableau Méthodes LogController statiques ci-dessous.
Reportez-vous à la section Génération de journaux WTT pour plus d’informations sur la façon de générer des journaux WTT en dehors de TAEF.
WexLogger API
Voici la liste des méthodes de journal C++ natives disponibles.
Il existe des versions équivalentes disponibles pour le code managé et les scripts.
| Méthodes de journal C++ natives | Fonctionnalités |
|---|---|
| Assert(const wchar_t* pszAssert) | Journaliser une assertion de test. |
| Assert(const wchar_t* pszAssert, const wchar_t* pszContext) | Journaliser une assertion de test, avec le contexte. |
| Assert(const wchar_t* pszAssert, const wchar_t* pszFile, const wchar_t* pszFunction, int line) | Journaliser une assertion de test avec des informations de fichier, de fonction et de ligne. |
| Assert(const wchar_t* pszAssert, const wchar_t* pszContext, const wchar_t* pszFile, const wchar_t* pszFunction, int line) | Journalisez une assertion de test, avec le contexte, ainsi que des informations de fichier, de fonction et de ligne. |
| Bug(const wchar_t* pszBugDatabase, int bugId) | Journaliser un numéro de bogue connu. |
| Bug(const wchar_t* pszBugDatabase, int bugId, const wchar_t* pszContext) | Consignez un numéro de bogue connu, avec le contexte. |
| Comment(const wchar_t* pszComment) | Journaliser un commentaire de test. |
| Comment(const wchar_t* pszComment, const wchar_t* pszContext) | Journaliser un commentaire de test, avec le contexte |
| EndGroup(const wchar_t* pszGroupName) | Journaliser la fin d’un groupe de tests ou d’un test spécifique. |
| EndGroup(const wchar_t* pszGroupName, const wchar_t* pszContext) | Journaliser la fin d’un groupe de tests, ou d’un test spécifique, avec le contexte. |
| Error(const wchar_t* pszError) | Journaliser une erreur de test. |
| Error(const wchar_t* pszError, const wchar_t* pszContext) | Journaliser une erreur de test, avec le contexte. |
| Error(const wchar_t* pszError, const wchar_t* pszFile, const wchar_t* pszFunction, int line) | Journaliser une erreur de test avec des informations de fichier, de fonction et de ligne. |
| Error(const wchar_t* pszError, const wchar_t* pszContext, const wchar_t* pszFile, const wchar_t* pszFunction, int line) | Consignez une erreur de test, avec le contexte, ainsi que les informations de fichier, de fonction et de ligne. |
| File(const wchar_t* pszFileName) | Journaliser un fichier de test à enregistrer. Les fichiers sont enregistrés dans <WTTRunWorkingDir>\WexLogFileOutput (si WTTRunWorkingDir est défini), ou <dans CurrentDirectory\>WexLogFileOutput. |
| File(const wchar_t* pszFileName, const wchar_t* pszContext) | Journaliser un fichier de test à enregistrer, avec le contexte. Les fichiers sont enregistrés dans <WTTRunWorkingDir>\WexLogFileOutput (si WTTRunWorkingDir est défini), ou <dans CurrentDirectory\>WexLogFileOutput. |
| Property(const wchar_t* pszName, const wchar_t* pszValue) | Journaliser une paire de propriétés nom/valeur. La valeur peut être au format xml. |
| Property(const wchar_t* pszName, const wchar_t* pszValue, const wchar_t* pszContext) | Journaliser une paire de propriétés nom/valeur, avec le contexte. La valeur peut être au format xml. |
| Result(TestResults ::Result testResult) | Journaliser un résultat de test. |
| Result(TestResults ::Result testResult, const wchar_t* pszComment) | Journaliser un résultat de test avec un commentaire associé. |
| Result(TestResults ::Result testResult, const wchar_t* pszComment, const wchar_t* pszContext) | Journaliser un résultat de test avec un commentaire associé, avec le contexte. |
| StartGroup(const wchar_t* pszGroupName) | Journaliser le début d’un groupe de tests ou d’un test spécifique. |
| StartGroup(const wchar_t* pszGroupName, TestResults ::Result defaultTestResult) | Journaliser le début d’un groupe de tests ou d’un test spécifique ; définit également le résultat du test par défaut. |
| StartGroup(const wchar_t* pszGroupName, const wchar_t* pszContext) | Journaliser le début d’un groupe de tests, ou d’un test spécifique, avec le contexte. |
| StartGroup(const wchar_t* pszGroupName, const wchar_t* pszContext, TestResults ::Result defaultTestResult) | Journaliser le début d’un groupe de tests ou d’un test spécifique ; définit également le résultat du test par défaut. |
| Warning(const wchar_t* pszWarning) | Journaliser un avertissement de test. |
| Warning(const wchar_t* pszWarning, const wchar_t* pszContext) | Journaliser un avertissement de test, avec le contexte. |
| Warning(const wchar_t* pszWarning, const wchar_t* pszFile, const wchar_t* pszFunction, int line) | Journaliser un avertissement de test avec des informations de fichier, de fonction et de ligne. |
| Warning(const wchar_t* pszWarning, const wchar_t* pszContext, const wchar_t* pszFile, const wchar_t* pszFunction, int line) | Journaliser un avertissement de test, avec le contexte, ainsi que des informations de fichier, de fonction et de ligne. |
| Xml(const wchar_t* pszXml) | Données xml du journal. Aucune case activée n’est effectuée pour vérifier qu’elle est bien formée. |
| Xml(const wchar_t* pszXml, const wchar_t* pszContext) | Données xml du journal, avec le contexte. Aucune case activée n’est effectuée pour vérifier qu’elle est bien formée. |
| MiniDump() | Journaliser le mini-vidage du processus actuel. |
Note: « Contexte » est une chaîne supplémentaire que vous pouvez éventuellement fournir avec un appel d’API WexLogger pour fournir plus de contexte ou de détails. Par exemple, vous pouvez choisir de toujours passer « ImageComparator » en tant que contexte lorsque vous effectuez des appels d’API WexLogger à partir de vos méthodes de classe ImageComparator.
Voici les valeurs valides possibles pour l’énumération TestResults ::Result C++ native. Il existe des versions équivalentes disponibles pour le code managé et les scripts.
| TestResults ::Result, énumération C++ native | Fonctionnalités |
|---|---|
| Passed | Test réussi |
| NotRun | Le test n’a pas été exécuté |
| Ignoré | Le test a été ignoré |
| Bloqué | Le test a été bloqué |
| Échec | Échec du test |
Voici la liste des méthodes LogController C++ natives disponibles :
| Méthodes LogController C++ natives | Fonctionnalités |
|---|---|
| HRESULT statique InitializeLogging() | Initialiser la fonctionnalité de journalisation. |
| static HRESULT InitializeLogging(WexLoggerErrorCallback pfnErrorCallback) | Initialisez la fonctionnalité de journalisation et spécifiez la fonction WexLoggerErrorCallback que vous souhaitez utiliser pour être averti des erreurs de journalisation internes. |
| static HRESULT InitializeLogging(const wchar_t* pszLogName) | Initialisez la fonctionnalité de journalisation et spécifiez le nom du fichier journal que vous souhaitez utiliser. Note: Le nom du journal est pris en compte uniquement si WttLogging est activé. |
| static HRESULT InitializeLogging(const wchar_t* pszLogName, WexLoggerErrorCallback pfnErrorCallback) | Initialisez la fonctionnalité de journalisation, spécifiez le nom du fichier journal que vous souhaitez utiliser et spécifiez la fonction WexLoggerErrorCallback que vous souhaitez utiliser pour être informé des erreurs d’enregistreur d’événements internes. Note: Le nom du journal est pris en compte uniquement si WttLogging est activé. |
| bool statique IsInitialized() | Retourne si le LogController a été initialisé ou non pour ce processus. |
| static const unsigned short* GetLogName() | Retourne le nom spécifié pour le journal dans l’appel InitializeLogging (le cas échéant). |
| HRESULT FinaliseLogging() statique | Terminer la fonctionnalité de journalisation. |
Note: Pour plus d’informations sur le mécanisme WexLoggerErrorCallback et comment l’utiliser en dehors de l’infrastructure TAEF, consultez la section Gestion des erreurs C++ ci-dessous.
Note: Il est uniquement nécessaire d’appeler InitializeLogging/FinaliseLogging lors de l’utilisation de WexLogger en dehors de l’infrastructure TAEF, car TAEF gère déjà l’initialisation/l’achèvement de la journalisation.
Note: Il n’est pas nécessaire d’initialiser/terminer la fonctionnalité de journalisation lors de l’utilisation de WexLogger à partir d’un script.
Voici la liste des méthodes C++ RemoteLogContoller natives disponibles :
| Méthodes RemoteLogController C++ natives | Fonctionnalités |
|---|---|
| static HRESULT GenerateConnectionData(WEX ::Common ::NoThrowString& connectionData) | Génère les données de connexion qui doivent être utilisées dans les processus parent et enfant pour permettre au processus enfant de se reconnecter au processus parent. |
| static HRESULT GenerateConnectionData(const wchar_t* pszMachineName, WEX ::Common ::NoThrowString& connectionData) | Utilisé lors du lancement de processus enfants sur un ordinateur distant. Génère les données de connexion qui doivent être utilisées dans les processus parent et enfant pour permettre au processus enfant de se reconnecter au processus parent. |
| HRESULT Statique InitializeLogging(WEX ::Common ::NoThrowString connectionData) | Initialise la fonctionnalité de journalisation dans le processus parent afin que le processus enfant puisse y revenir. |
Note: Consultez la section Journalisation à distance à partir de processus enfants ci-dessous pour plus d’informations sur la journalisation à distance.
Voici la liste des méthodes de journal managées disponibles.
| Méthodes de journal managé | Fonctionnalités |
|---|---|
| Assert(IFormatProvider provider, string format, params object[] args) | Consignez une déclaration de test à l’aide d’un fournisseur d’informations de mise en forme spécifique à la culture, d’une chaîne de format et d’un tableau d’objets qui contient zéro ou plusieurs objets à mettre en forme. |
| Assert(IFormatProvider provider, string format, params object[] args) | Consignez une déclaration de test à l’aide d’un fournisseur d’informations de mise en forme spécifique à la culture, d’une chaîne de format et d’un tableau d’objets qui contient zéro ou plusieurs objets à mettre en forme. |
| Assert(string message) | Consignez une déclaration de test. |
| Assert(string format, object arg0) | Consignez une déclaration de test à l’aide d’une chaîne de format et d’un objet à mettre en forme. |
| Assert(string format, params object[] args) | Consignez une déclaration de test à l’aide d’une chaîne de format et d’un tableau d’objets qui contient au moins un ou plusieurs objets à mettre en forme. |
| Assert(string message, contexte de chaîne) | Consignez une assertion de test, avec le contexte. |
| Assert(string message, string file, string function, int line) | Consignez une assertion de test, ainsi que des informations de fichier, de fonction et de ligne. |
| Assert(string message, string context, string file, string function, int line) | Consignez une assertion de test, avec le contexte, ainsi que les informations de fichier, de fonction et de ligne. |
| Bug(string bugDatabase, int bugId) | Consignez un numéro de bogue connu. |
| Bug(string bugDatabase, int bugId, contexte de chaîne) | Consignez un numéro de bogue connu, avec le contexte. |
| Comment(Fournisseur IFormatProvider, format chaîne, params object[] args) | Consignez un commentaire de test à l’aide d’un fournisseur d’informations de mise en forme propre à la culture, d’une chaîne de format et d’un tableau d’objets qui contient zéro ou plusieurs objets à mettre en forme. |
| Comment(string message) | Journaliser un commentaire de test |
| Comment(string format, object arg0) | Consignez un commentaire de test à l’aide d’une chaîne de format et d’un objet à mettre en forme. |
| Comment(string format, params object[] args) | Consignez un commentaire de test à l’aide d’une chaîne de format et d’un tableau d’objets qui contient zéro ou plusieurs objets à mettre en forme. |
| Comment(string message, contexte de chaîne) | Journaliser un commentaire de test, avec le contexte |
| EndGroup(string groupName) | Journaliser la fin d’un groupe de tests ou d’un test spécifique. |
| EndGroup(string groupName, contexte de chaîne) | Journaliser la fin d’un groupe de tests, ou d’un test spécifique, avec le contexte. |
| Error(IFormatProvider provider, string format, params object[] args) | Consignez une erreur de test à l’aide d’un fournisseur d’informations de mise en forme spécifique à la culture, d’une chaîne de format et d’un tableau d’objets qui contient zéro ou plusieurs objets à mettre en forme. |
| Error(string message) | Consignez une erreur de test. |
| Error(string format, object arg0) | Consignez une erreur de test à l’aide d’une chaîne de format et d’un objet à mettre en forme. |
| Error(string message, string context) | Consignez une erreur de test, avec le contexte. |
| Error(IFormatProvider provider, string format, params object[] args) | Consignez une erreur de test à l’aide d’une chaîne de format et d’un tableau d’objets qui contient zéro ou plusieurs objets à mettre en forme. |
| Error(string message, string file, string function, int line) | Consignez une erreur de test avec des informations de fichier, de fonction et de ligne. |
| Error(string message, string context, string file, string function, int line) | Consignez une erreur de test, avec le contexte, ainsi que les informations de fichier, de fonction et de ligne. |
| File(string fileName) | Consignez un fichier de test à enregistrer. Les fichiers sont enregistrés dans WTTRunWorkingDir\WexLogFileOutput (si WTTRunWorkingDir est défini) ou dans CurrentDirectory\WexLogFileOutput. |
| File(string fileName, contexte de chaîne) | Journaliser un fichier de test à enregistrer, avec le contexte. Les fichiers sont enregistrés dans WTTRunWorkingDir\WexLogFileOutput (si WTTRunWorkingDir est défini), ou dans CurrentDirectory\WexLogFileOutput. |
| MiniDump() | Journaliser le mini-vidage du processus actuel. |
| Property(string name, string value) | Journaliser une paire de propriétés nom/valeur. La valeur peut être au format xml. |
| Property(string name, string value, string context) | Journaliser une paire de propriétés nom/valeur, avec le contexte. La valeur peut être au format xml. |
| Result(TestResult testResult) | Journaliser un résultat de test. |
| Result(TestResult testResult, string comment) | Journaliser un résultat de test avec un commentaire associé. |
| Result(TestResult testResult, string comment, string context) | Journaliser un résultat de test avec un commentaire associé, avec le contexte. |
| StartGroup(string groupName) | Journaliser le début d’un groupe de tests ou d’un test spécifique. |
| StartGroup(string groupName, string context) | Journaliser le début d’un groupe de tests, ou d’un test spécifique, avec le contexte. |
| Warning(IFormatProvider provider, string format, params object[] args) | Consignez un avertissement de test à l’aide d’un fournisseur d’informations de mise en forme spécifique à la culture, d’une chaîne de format et d’un tableau d’objets qui contient zéro ou plusieurs objets à mettre en forme. |
| Warning(string message) | Journaliser un avertissement de test. |
| Warning(string format, object arg0) | Consignez un avertissement de test à l’aide d’une chaîne de format et d’un objet à mettre en forme. |
| Warning(string format, params object[] args) | Consignez un avertissement de test à l’aide d’une chaîne de format et d’un tableau d’objets qui contient zéro ou plusieurs objets à mettre en forme. |
| Warning(string message, string context) | Journaliser un avertissement de test, avec le contexte. |
| Warning(string message, string file, string function, int line) | Journaliser un avertissement de test avec des informations de fichier, de fonction et de ligne. |
| Warning(string message, string context, string file, string function, int line) | Journaliser un avertissement de test, avec le contexte, ainsi que des informations de fichier, de fonction et de ligne. |
| Xml(string xmlData) | Données xml du journal. Aucune case activée n’est effectuée pour vérifier qu’elle est bien formée. |
| Xml(string xmlData, string context) | Données xml du journal, avec le contexte. Aucune case activée n’est effectuée pour vérifier qu’elle est bien formée. |
Voici la liste des méthodes LogContoller gérées disponibles :
| Méthodes Managed LogController | Fonctionnalités |
|---|---|
| static void InitializeLogging() | Initialisez la fonctionnalité de journalisation. |
| static void InitializeLogging(String logName) | Initialisez la fonctionnalité de journalisation et spécifiez le nom du fichier journal que vous souhaitez utiliser. Note: Le nom du journal est pris en compte uniquement si WttLogging est activé. |
| static bool IsInitialized() | Retourne si le LogController a été initialisé ou non pour ce processus. |
| static String GetLogName() | Retourne le nom spécifié pour le journal dans l’appel InitializeLogging (le cas échéant). |
| static void FinalizeLogging() | Terminer la fonctionnalité de journalisation. |
Note: Consultez la section Erreur et exception de code managé ci-dessous pour plus d’informations sur la façon de gérer les erreurs et les exceptions lors de l’utilisation de la couche managée de WexLogger en dehors de l’infrastructure TAEF.
Note: Il est uniquement nécessaire d’appeler InitializeLogging/FinalizeLogging lors de l’utilisation de WexLogger en dehors de l’infrastructure TAEF, car TAEF gère déjà l’initialisation/l’achèvement de la journalisation.
Note: Il n’est pas nécessaire d’initialiser/terminer la fonctionnalité de journalisation lors de l’utilisation du script WexLogger .
Voici la liste des méthodes RemoteLogContoller gérées disponibles :
| Méthodes RemoteLogController gérées | Fonctionnalités |
|---|---|
| static String GenerateConnectionData() | Génère les données de connexion qui doivent être utilisées dans les processus parent et enfant pour permettre au processus enfant de se reconnecter au processus parent. |
| static String GenerateConnectionData(string machineName) | Utilisé lors du lancement de processus enfants sur un ordinateur distant. Génère les données de connexion qui doivent être utilisées dans les processus parent et enfant pour permettre au processus enfant de se reconnecter au processus parent. |
| static void InitializeLogging(String connectionData) | Initialise la fonctionnalité de journalisation dans le processus parent afin que le processus enfant puisse se reconnecter à celui-ci. |
Note: Pour plus d’informations sur la journalisation à distance, consultez la section Journalisation à distance à partir de processus enfants ci-dessous.
Journalisation à distance à partir de processus enfants
WexLogger permet à un ou plusieurs processus enfants de se reconnecter à un processus parent unique, ce qui entraîne la génération de résultats de tests consolidés dans un fichier journal unique.
Les processus enfants peuvent être en cours d’exécution sur la même machine que le processus parent ou à distance sur un autre ordinateur. Pour que la journalisation des ordinateurs distants fonctionne, il incombe au client WexLogger d’ajouter des exclusions de pare-feu TCP pour tous les processus enfants sur l’ordinateur distant. Toutefois, si les processus enfants s’exécutent sur la même machine que le parent, aucune modification du pare-feu n’est nécessaire.
Les étapes suivantes sont nécessaires pour configurer chaque connexion de journalisation à distance :
Processus parent
Appelez RemoteLogController ::GenerateConnectionData() pour générer les données de connexion qui doivent être utilisées par les deux processus pour lancer une connexion de journalisation.
Note: Veillez à case activée la valeur de retour de cet appel.
NoThrowString connectionData; Throw::IfFailed(RemoteLogController::GenerateConnectionData(connectionData));Communiquez les données de connexion avec le processus enfant en les définissant dans son bloc d’environnement ou en les transmettant en tant qu’argument à l’invite de commandes. Par exemple :
Passez en tant qu’argument nommé à l’invite de commandes que WexLogger comprend :
/wexlogger_connectiondata=[données de connexion]Note: Si cette option est utilisée, l’étape 1 de la section Processus enfant ci-dessous n’est pas nécessaire.
Passez en tant que variable d’environnement nommée que WexLogger comprend :
[YourAppName_cmd]=/wexlogger_connectiondata=[données de connexion]Note: Si cette option est utilisée, l’étape 1 de la section Processus enfant ci-dessous n’est pas nécessaire.
Passer à traiter dans un format arbitraire (autre paramètre de commande, variable d’environnement, etc.)
Note: Si cette option est utilisée, l’étape 1 de la section Processus enfant ci-dessous est nécessaire.Note: Pour des raisons pratiques, la valeur « /wexlogger_connectiondata= » est définie comme une constante dans les RemoteLogControllers natifs et managés :
WEX ::Logging ::c_szWexLoggerRemoteConnectionData, dans LogController.h
RemoteLogController.WexLoggerRemoteConnectionData, dans Wex.Logger.Interop.dll
Lancer le processus enfant avec les données de connexion
Appelez RemoteLogController ::InitalizeLogging([données de connexion créées à l’étape 1]). Cet appel doit être effectué après le lancement du processus enfant, car il expire si l’enfant n’appelle pas LogController ::InitializeLogging() en temps opportun.
Note: Veillez à case activée la valeur de retour de cet appel.
// ...launch child process with connection data... Throw::IfFailed(RemoteLogController::InitializeLogging(connectionData));Attendez le processus enfant, etc.
Processus enfant
Si les données de connexion n’ont pas été passées au processus enfant en tant qu’argument nommé à l’invite de commandes que WexLogger comprend (voir l’étape 2 ci-dessus), vous devez définir une variable d’environnement en tant que telle :
[YourAppName_cmd]=/wexlogger_connectiondata=[données de connexion]
Par exemple :
// App name is mytestapp.exe ::SetEnvironmentVariable(L"mytestapp_cmd", String(c_szWexLoggerRemoteConnectionData).Append(connectionData));Appelez LogController ::InitializeLogging() pour initialiser la journalisation pour ce processus. En interne, cela tirera parti de la variable d’environnement définie à l’étape 1 ci-dessus (ou à l’étape 2 de la section Processus parent ) pour lancer une connexion de journalisation au processus parent.
Journal, etc. toutes les traces sont renvoyées au processus parent.
Appelez LogController ::FinalizeLogging() pour terminer la journalisation de ce processus.
Détermination du résultat du test
Bien qu’une méthode soit fournie pour indiquer explicitement le résultat prévu d’un cas de test (Log ::Result()), il n’est pas nécessaire qu’un cas de test utilise cette méthode dans la plupart des cas.
Par exemple, si un cas de test n’appelle pas explicitement Log ::Result() et ne consigne pas d’erreur (via Log ::Error()), par défaut, il est considéré comme un cas de test réussi ; s’il enregistre une erreur, il s’agit d’un cas de test défaillant.
Toutefois, si un cas de test appelle explicitement Log ::Result(TestResults ::TestPassed), mais enregistre également une erreur dans le cas de test, le test est toujours comptabilisé comme un échec, car une erreur s’est produite dans le test.
À l’intérieur de l’infrastructure TAEF, ce comportement peut être remplacé en étiquetant votre test avec un résultat de test par défaut différent. Vous trouverez plus d’informations à ce sujet dans le document « Création de tests TAEF ».
Ce comportement peut également être remplacé en appelant explicitement Log ::StartGroup() pour vos propres groupes de tests/cas de test, avec un résultat de test par défaut de votre choix.
Génération de journaux WTT
Trois méthodes existent pour générer des journaux WTT via WexLogger. Toutes nécessitent que WttLog.dll soit présent dans le répertoire d’exécution ou dans votre chemin d’accès.
Si vous exécutez dans le laboratoire, avec le client wtt installé, les journaux wtt sont automatiquement générés pour vous. Cela est dû au fait que WexLogger recherche l’existence de deux variables d’environnement qui ne doivent exister que dans un environnement lab : « WttTaskGuid » et « WTTRunWorkingDir ». Si ces deux éléments existent, la journalisation wtt est automatiquement activée.
Si vous exécutez dans TAEF en dehors d’un environnement lab, transmettez /enablewttlogging à l’invite de commandes à votre cas de test. Exemple :
te my.test.dll /enablewttloggingSi vous consommez WexLogger en dehors de l’infrastructure TAEF et que vous n’exécutez pas dans un environnement lab, vous devez définir la <variable d’environnement YOUR_PROCESS_NAME>_CMD pour qu’elle contienne cette option avant d’appeler LogController ::InitializeLogging().. Exemple :
Environment.SetEnvironmentVariable("<YOUR_PROCESS_NAME>_CMD", "/enablewttlogging"); LogController.InitializeLogging();Environment.SetEnvironmentVariable("consoleapplication4_cmd", "/enablewttlogging"); LogController.InitializeLogging();Si vous souhaitez ajouter à un fichier journal wtt existant au lieu de le remplacer, spécifiez également l’option /appendwttlogging en plus de /enablewttlogging.
te my.test.dll /enablewttlogging /appendwttloggingEnvironment.SetEnvironmentVariable("<YOUR_PROCESS_NAME>_CMD", "/enablewttlogging /appendwttlogging"); LogController.InitializeLogging();Environment.SetEnvironmentVariable("consoleapplication4_cmd", "/enablewttlogging /appendwttlogging"); LogController.InitializeLogging();
Il est également possible de remplacer ou d’ajouter complètement à la chaîne d’appareil WttLogger par défaut en spécifiant l’une des options de commande suivantes :
/WttDeviceString :<new device string>
Remplace complètement le WttDeviceString utilisé par WexLogger lors de l’initialisation de WttLogger.
/WttDeviceStringSuffix :<value à ajouter à la chaîne d’appareil>
Ajoute la valeur spécifiée au WttDeviceString par défaut utilisé par WexLogger lors de l’initialisation de WttLogger. Ignoré si « /WttDeviceString » est également spécifié.
Le tableau suivant répertorie la façon dont WexLogger TestResults est mappé aux résultats WttLogger :
| WexLogger | WttLogger |
|---|---|
| Passed | WTT_TESTCASE_RESULT_PASS |
| NotRun | WTT_TESTCASE_RESULT_BLOCKED |
| Ignoré | WTT_TESTCASE_RESULT_SKIPPED |
| Bloqué | WTT_TESTCASE_RESULT_BLOCKED |
| Échec | WTT_TESTCASE_RESULT_FAIL |
Dépendances de l’enregistreur d'
L’enregistreur d’événements C++ natif (Wex.Logger.dll) dépend deWex.Common.dll et Wex.Communication.dll.
L’enregistreur d’événements managé (Wex.Logger.Interop.dll) dépend deWex.Logger.dll, Wex.Common.dll et Wex.Communication.dll.
En outre, WttLog.dll est nécessaire lorsque la journalisation Wtt est activée.
Données d’erreur supplémentaires
Dans le cas où une erreur est enregistrée, vous pouvez activer WexLogger pour inclure un ou plusieurs des éléments suivants en plus de l’erreur elle-même :
- MiniDump
- ScreenCapture
- StackTrace
te my.test.dll /minidumponerror
te my.test.dll /screencaptureonerror /stacktraceonerror
Une ou plusieurs de ces options activées, vous recevez une sortie supplémentaire chaque fois que Log ::Error() est appelé.
Remarque : Si vous consommez WexLogger en dehors de l’infrastructure TAEF, vous devez définir la <variable d’environnement YOUR_PROCESS_NAME>_CMD pour qu’elle contienne ces options avant d’appeler LogController ::InitializeLogging(). Exemple :
Environment.SetEnvironmentVariable("<YOUR_PROCESS_NAME>_CMD", "/screencaptureonerror /minidumponerror /stacktraceonerror");
LogController.InitializeLogging();
Environment.SetEnvironmentVariable("consoleapplication4_cmd", "/screencaptureonerror /minidumponerror /stacktraceonerror");
LogController.InitializeLogging();
Gestion des erreurs C++
Afin de protéger les auteurs de cas de test de la charge de vérification des valeurs de retour pour chaque appel d’API Log, WexLogger signale des conditions d’erreur inattendues via l’utilisation d’un mécanisme de rappel facultatif ; une fonction WexLoggerErrorCallback . Lors de l’initialisation de WexLogger (via LogController ::InitializeLogging()), les clients peuvent choisir de spécifier une fonction WexLoggerErrorCallback à appeler si des conditions d’erreur inattendues se produisent dans le WexLogger. La fonction WexLoggerErrorCallback doit utiliser la signature suivante :
void __stdcall MyLoggerErrorCallback(const unsigned short* pszMessage, HRESULT hr);
Une utilisation courante de la fonction WexLoggerErrorCallback consiste à écrire les messages d’erreur dans la console (si votre harnais de test est une application console). Par exemple, l’infrastructure TAEF est un client de WexLogger et implémente un WexLoggerErrorCallback qui écrit du texte rouge dans la console lorsque des erreurs WexLogger se produisent.
Compatibilité de .NET 4.0
Wex.Logger.Interop est compilé en tant que binaire NetFx 2/3/3.5, de sorte qu’il peut être chargé dans les processus NetFx 2/3/3.5 et NetFx 4. Cela permet à TAEF d’exécuter tous les assemblys managés au-dessus de NetFx 2. Si vous utilisez Wex.Logger en dehors de TAEF, vous devez ajouter un fichier de configuration pour votre exe afin de configurer le runtime NetFx 4 afin de charger les binaires NetFx 2/3/3.5 dans son processus. Le fichier de configuration doit contenir les éléments suivants :
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Gestion des erreurs et des exceptions dans le code managé
Afin de protéger les auteurs de cas de test de la charge de vérification des valeurs de retour pour chaque appel d’API Log , la couche managée de WexLogger signale des conditions d’erreur inattendues via l’utilisation de l’événement LoggerController.WexLoggerError . Vous pouvez vous abonner à cet événement à tout moment en implémentant votre propre WexLoggerErrorEventHandler et en utilisant la syntaxe familière suivante pour l’abonnement aux événements C# :
LogController.WexLoggerError += new WexLoggerEventHandler(My_WexLoggerErrorHandler);
Voici un exemple de ce à quoi votre gestionnaire d’événements peut ressembler :
static void LogController_WexLoggerError(object sender, WexLoggerErrorEventArgs e)
{
ConsoleColor originalColor = Console.ForegroundColor;
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine("LogController_WexLoggerError: " + e.Message);
Console.ForegroundColor = originalColor;
}
En outre, les méthodes LogController ::InitializeLogging() et LogController ::FinalizeLogging() elles-mêmes lèvent WexLoggerException en cas de défaillance. Cela fournit des informations détaillées sur l’erreur et vous permet également d’abandonner la série de tests avant qu’elle ne commence. Les auteurs de cas de test n’auront jamais à se soucier d’intercepter ces exceptions : elles doivent être attendues/gérées pendant l’initialisation/l’achèvement de WexLogger uniquement.