Compartir a través de


Objetos de depurador nativos en extensiones de JavaScript: consideraciones de diseño y pruebas

En este tema se describen las consideraciones de diseño y pruebas para usar los objetos de depurador nativos en extensiones de JavaScript.

Los objetos de depurador nativos representan diversas construcciones y comportamientos del entorno del depurador. Los objetos se pueden pasar a extensiones de JavaScript (o adquiridas en) para manipular el estado del depurador.

Para obtener información sobre las extensiones javaScript del objeto Debugger, vea Objetos de depurador nativos en extensiones de JavaScript.

Para obtener información general sobre cómo trabajar con JavaScript, consulte Scripting del depurador de JavaScript.

Consideraciones de diseño del modelo de datos del depurador

Principios de diseño

Tenga en cuenta los siguientes principios para que las extensiones del depurador presenten información que se puede detectar, consultar y crear scripts.

  • La información está cerca de dónde se necesita. Por ejemplo, se debe mostrar información sobre una clave del Registro como parte de una variable local que contiene un identificador de clave del Registro.
  • La información está estructurada. Por ejemplo, la información sobre una clave del Registro se presenta en campos independientes, como el tipo de clave, la ACL de clave, el nombre de clave y el valor. Esto significa que se puede acceder a los campos individuales sin analizar texto.
  • La información es coherente. La información sobre los identificadores de clave del Registro se presenta de la forma más similar posible a la información sobre los identificadores de archivo.

Evite estos enfoques que no admitan estos principios.

  • No estructure los elementos en un solo plano "Lavabo de cocina". Una jerarquía organizada permite a los usuarios buscar la información que buscan sin tener conocimiento previo de lo que buscan y admiten la detectabilidad.
  • No convierta una extensión dbgeng clásica al moverla al modelo mientras sigue produciendo pantallas de texto sin formato. Esto no se puede componer con otras extensiones y no se puede consultar con expresiones LINQ. En su lugar, divida los datos en campos consultables independientes.

Instrucciones de nomenclatura

  • La mayúsculas de los campos debe ser PascalCase. Se puede considerar una excepción para los nombres que se conocen ampliamente en otro uso de mayúsculas y minúsculas, como jQuery.
  • Evite usar caracteres especiales que normalmente no se usarían en un identificador de C++. Por ejemplo, evite usar nombres como "Longitud total" (que contiene un espacio) o "[size]" (que contiene corchetes). Esta convención permite un consumo más sencillo de los lenguajes de scripting en los que estos caracteres no se permiten como parte de los identificadores y también permite un consumo más sencillo desde la ventana de comandos.

Directrices de organización y jerarquía

  • No extienda el nivel superior del espacio de nombres del depurador. En su lugar, debe extender un nodo existente en el depurador para que la información se muestre donde sea más relevante.
  • No duplique los conceptos. Si va a crear una extensión de modelo de datos que muestra información adicional sobre un concepto que ya existe en el depurador, extienda la información existente en lugar de intentar reemplazarla por información nueva. Es decir, una extensión que muestra detalles sobre un módulo debe extender el objeto Module existente en lugar de crear una nueva lista de módulos.
  • Los comandos de la utilidad flotante libre deben formar parte del espacio de nombres Debugger.Utility . También deben tener un espacio de nombres secundario adecuado (por ejemplo , Debugger.Utility.Collections.FromListEntry).

Compatibilidad con versiones anteriores y cambios importantes

Un script que se publica no debe interrumpir la compatibilidad con otros scripts que dependen de él. Por ejemplo, si una función se publica en el modelo, debe permanecer en la misma ubicación y con los mismos parámetros, siempre que sea posible.

Sin uso de recursos externos

  • Las extensiones no deben generar procesos externos. Los procesos externos pueden interferir con el comportamiento del depurador y se comportarán incorrectamente en varios escenarios de depurador remoto (por ejemplo, dbgsrv remotes, ntsd remotes y "ntsd -d remotes")
  • Las extensiones no deben mostrar ninguna interfaz de usuario. La visualización de elementos de la interfaz de usuario se comportará incorrectamente en escenarios de depuración remota y puede interrumpir los escenarios de depuración de la consola.
  • Las extensiones no deben manipular el motor del depurador ni la interfaz de usuario del depurador a través de métodos no documentados. Esto provoca problemas de compatibilidad y se comportará incorrectamente en los clientes del depurador con una interfaz de usuario diferente.
  • Las extensiones solo deben tener acceso a la información de destino a través de las API del depurador documentadas. Si intenta acceder a información sobre un destino a través de las API win32, se producirá un error en muchos escenarios remotos e incluso en algunos escenarios de depuración locales a través de los límites de seguridad.

No se usa ninguna característica específica de Dbgeng

Los scripts que están diseñados para usarse como extensiones no deben depender de características específicas de dbgeng siempre que sea posible (por ejemplo, ejecutar extensiones del depurador "clásico"). Los scripts deben ser utilizables sobre cualquier depurador que hospede el modelo de datos.

Probar extensiones del depurador

Se espera que las extensiones funcionen en una amplia gama de escenarios. Aunque algunas extensiones pueden ser específicas de un escenario (como un escenario de depuración de kernel), se espera que la mayoría de las extensiones funcionen en todos los escenarios o que tengan metadatos que indiquen los escenarios admitidos.

Modo kernel

  • Depuración de kernel en vivo
  • Depuración de volcado de kernel

Modo de usuario

  • Depuración en modo de usuario activo
  • Depuración de volcado del modo de usuario

Además, tenga en cuenta estos escenarios de uso del depurador.

  • Depuración de varios procesos
  • Depuración de varias sesiones (por ejemplo, volcado + usuario activo dentro de una sola sesión)

Uso del depurador remoto

Pruebe la operación adecuada con los escenarios de uso del depurador remoto.

  • dbgsrv remotes
  • ntsd remotes
  • ntsd -d remotes

Para obtener más información, vea Depuración mediante CDB y NTSD y Activación de un servidor de procesos.

Pruebas de regresión

Investigue el uso de la automatización de pruebas que puede comprobar la funcionalidad de las extensiones, a medida que se publiquen nuevas versiones del depurador.

Consulte también

Objetos de depurador nativos en extensiones de JavaScript

Objetos de depurador nativos en extensiones de JavaScript: detalles del objeto del depurador.

Scripting del depurador de JavaScript

Scripts de ejemplo del depurador de JavaScript