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

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

Les objets débogueur natifs représentent différentes constructions et comportements de l’environnement du débogueur. Les objets peuvent être transmis à des extensions JavaScript (ou acquis dans celles-ci) 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 Débogueur de scripts JavaScript.

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

Principes de conception

Tenez compte des principes suivants pour rendre vos extensions de débogueur présenter 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.
• Les informations sont structurées. Par exemple, des 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 clé et la valeur. Cela signifie que les champs individuels sont accessibles sans analyse de texte.
• Les informations sont cohérentes. Les informations sur les descripteurs de clé de Registre sont présentées de la manière la plus similaire possible à celle des informations sur les descripteurs de fichiers.

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

• Ne structurez pas vos articles en un seul « récepteur de cuisine ». Une hiérarchie organisée permet aux utilisateurs de rechercher les informations qu’ils recherchent sans connaissance préalable de ce qu’ils recherchent et prennent en charge la détectabilité.
• Ne convertissez pas une extension dbgeng classique en la transférant simplement vers le modèle tout en continuant à afficher 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.

Instructions d’affectation de noms

• La majuscule des champs doit être PascalCase. Une exception peut être prise en compte pour les noms 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 permet une consommation plus facile à partir des langages de script où ces caractères ne sont pas autorisés dans le cadre d’identificateurs, et permet également une consommation plus facile à 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 soient affichées là où elles sont les plus pertinentes.
• Ne pas dupliquer 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 plutôt que de créer une nouvelle liste de modules.
• Les commandes de l’utilitaire flottante 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 sur le modèle, elle doit rester dans le même emplacement et avec les mêmes paramètres, dans la mesure du possible.

Aucune utilisation des 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, dbgsrv remotes, ntsd remotes et « ntsd -d remotes »)
• Les extensions ne doivent pas afficher d’interface utilisateur. L’affichage des éléments d’interface utilisateur se comporte incorrectement sur les scénarios de débogage à distance 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 via des méthodes non documentées. Cela provoque des problèmes de compatibilité et se comporte incorrectement sur les clients du débogueur avec une autre interface utilisateur.
• Les extensions doivent accéder aux informations cibles uniquement via les API de débogueur documentées. La tentative d’accès aux informations relatives à une cible par le biais d’API win32 échoue pour de nombreux scénarios distants, et même certains scénarios de débogage locaux 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 (telles que l’exécution d’extensions de débogueur « classique »). Les scripts doivent être utilisables au-dessus de n’importe quel débogueur qui héberge le modèle de données.

Test des extensions de débogueur

Les extensions sont censées fonctionner dans un large éventail de scénarios. Même si certaines extensions peuvent être spécifiques à un scénario (par exemple, 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 en direct
• Débogage de vidage du noyau

Mode utilisateur

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

En outre, tenez compte de ces scénarios d’utilisation du débogueur

• Débogage multiprocesseur
• Débogage multi-sessions (par exemple, dump + utilisateur en direct dans une seule session)

Utilisation du débogueur distant

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

• dbgsrv remotes
• connexions à distance ntsd
• ntsd -d télécommandes

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

Test de régression

Examinez l’utilisation de l’automatisation de test 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.

Scriptage du débogueur JavaScript

Exemples de scripts du débogueur JavaScript