Objets débogueur natifs dans les extensions JavaScript - Considérations relatives à la conception et aux tests

Cette rubrique décrit les considérations relatives à la conception et au test pour l’utilisation des objets de débogueur natifs dans les extensions JavaScript.

Les objets débogueur natifs représentent différents constructions et comportements de l’environnement du débogueur. Les objets peuvent être passés dans (ou acquis dans) des extensions JavaScript pour manipuler l’état du débogueur.

Pour plus d’informations sur les extensions JavaScript de l’objet Débogueur, consultez Objets de débogueur natifs dans les extensions JavaScript.

Pour obtenir des informations générales sur l’utilisation de JavaScript, consultez Script du débogueur JavaScript.

Considérations relatives à la conception du modèle de données du débogueur

Principes de conception

Tenez compte des principes suivants pour que vos extensions de débogueur présentent des informations détectables, interrogeables et scriptables.

• Les informations sont proches de l’endroit où elles sont nécessaires. Par exemple, les informations sur une clé de Registre doivent être affichées dans le cadre d’une variable locale qui contient un handle de clé de Registre.
• L’information est structurée. Par exemple, les informations sur une clé de Registre sont présentées dans des champs distincts, tels que le type de clé, la liste de contrôle d’accès de clé, le nom de la clé et la valeur. Cela signifie que les champs individuels sont accessibles sans analyser le texte.
• Les informations sont cohérentes. Les informations sur les handles de clé de Registre sont présentées de la même manière que possible avec les informations sur les descripteurs de fichiers.

Évitez les approches qui ne prennent pas en charge ces principes.

• Ne structurez pas vos articles en un seul « évier de cuisine ». Une hiérarchie organisée permet aux utilisateurs de rechercher les informations qu’ils recherchent sans avoir connaissance préalable de ce qu’ils recherchent et prend en charge la détectabilité.
• Ne convertissez pas une extension dbgeng classique en la déplaçant simplement vers le modèle tout en sortant des écrans de texte brut. Cela n’est pas composable avec d’autres extensions et ne peut pas être interrogé avec des expressions LINQ. Au lieu de cela, divisez les données en champs distincts et interrogeables.

Directives de nommage

• La majuscule des champs doit être PascalCase. Une exception peut être envisagée pour les noms qui sont largement connus dans une autre casse, comme jQuery.
• Évitez d’utiliser des caractères spéciaux qui ne seraient normalement pas utilisés dans un identificateur C++. Par exemple, évitez d’utiliser des noms tels que « Longueur totale » (qui contient un espace) ou « [taille] » (qui contient des crochets). Cette convention facilite la consommation à partir des langages de script où ces caractères ne sont pas autorisés dans le cadre des identificateurs, ainsi que la consommation à partir de la fenêtre de commande.

Instructions relatives à l’organisation et à la hiérarchie

• N’étendez pas le niveau supérieur de l’espace de noms du débogueur. Au lieu de cela, vous devez étendre un nœud existant dans le débogueur afin que les informations s’affichent là où elles sont les plus pertinentes.
• Ne dupliquez pas les concepts. Si vous créez une extension de modèle de données qui répertorie des informations supplémentaires sur un concept qui existe déjà dans le débogueur, étendez les informations existantes plutôt que d’essayer de les remplacer par de nouvelles informations. En d’autres termes, une extension qui affiche des détails sur un module doit étendre l’objet Module existant au lieu de créer une liste de modules.
• Les commandes de l’utilitaire flottant libre doivent faire partie de l’espace de noms Debugger.Utility . Ils doivent également être sous-espaces de noms appropriés (par exemple , Debugger.Utility.Collections.FromListEntry)

Compatibilité descendante et changements cassants

Un script publié ne doit pas interrompre la compatibilité avec d’autres scripts qui en dépendent. Par exemple, si une fonction est publiée dans le modèle, elle doit rester au même emplacement et avec les mêmes paramètres, dans la mesure du possible.

Aucune utilisation de ressources externes

• Les extensions ne doivent pas générer de processus externes. Les processus externes peuvent interférer avec le comportement du débogueur et se comportent mal dans différents scénarios de débogueur distant (par exemple, les distances dbgsrv, les distances ntsd et les « ntsd -d remotes »)
• Les extensions ne doivent pas afficher d’interface utilisateur. L’affichage des éléments de l’interface utilisateur se comporte incorrectement dans les scénarios de débogage distant et peut interrompre les scénarios de débogage de console.
• Les extensions ne doivent pas manipuler le moteur de débogueur ou l’interface utilisateur du débogueur par le biais de méthodes non documentées. Cela entraîne des problèmes de compatibilité et se comporte incorrectement sur les clients du débogueur avec une interface utilisateur différente.
• Les extensions doivent accéder aux informations cibles uniquement par le biais des API de débogueur documentées. La tentative d’accès aux informations sur une cible via les API win32 échouera pour de nombreux scénarios distants, et même pour certains scénarios de débogage local au-delà des limites de sécurité.

Aucune utilisation des fonctionnalités spécifiques de Dbgeng

Les scripts destinés à être utilisés en tant qu’extensions ne doivent pas s’appuyer sur des fonctionnalités spécifiques à dbgeng dans la mesure du possible (par exemple, l’exécution d’extensions de débogueur « classiques »). Les scripts doivent être utilisables par-dessus tout débogueur qui héberge le modèle de données.

Test des extensions du débogueur

Les extensions sont censées fonctionner dans un large éventail de scénarios. Bien que certaines extensions puissent être spécifiques à un scénario (comme un scénario de débogage de noyau), la plupart des extensions doivent être censées fonctionner dans tous les scénarios ou avoir des métadonnées indiquant les scénarios pris en charge.

Mode noyau

• Débogage du noyau dynamique
• Débogage du vidage du noyau

Mode utilisateur

• Débogage en mode utilisateur actif
• Débogage de vidage en mode utilisateur

En outre, envisagez ces scénarios d’utilisation du débogueur

• Débogage multiprocessus
• Débogage multisession (par exemple, vidage + utilisateur actif au sein d’une seule session)

Utilisation du débogueur distant

Testez le bon fonctionnement avec les scénarios d’utilisation du débogueur distant.

• dbgsrv remotes
• ntsd remotes
• ntsd -d remotes

Pour plus d’informations, consultez Débogage à l’aide de CDB et de NTSD et Activation d’un serveur de processus.

Effectuer des tests de régression

Examinez l’utilisation de l’automatisation des tests qui peut vérifier les fonctionnalités de vos extensions, à mesure que de nouvelles versions du débogueur sont publiées.

Voir aussi

Objets débogueur natifs dans les extensions JavaScript

Objets débogueur natifs dans les extensions JavaScript - Détails de l’objet débogueur.

Script du débogueur JavaScript

Exemples de scripts de débogueur JavaScript