Oggetti debugger nativi nelle estensioni JavaScript - Considerazioni sulla progettazione e sul test

In questo argomento vengono descritte le considerazioni relative alla progettazione e al test per l'uso degli oggetti debugger nativi nelle estensioni JavaScript.

Gli oggetti debugger nativi rappresentano vari costrutti e comportamenti dell'ambiente del debugger. Gli oggetti possono essere passati o acquisiti nelle estensioni JavaScript per modificare lo stato del debugger.

Per informazioni sulle estensioni JavaScript dell'oggetto Debugger, vedere Oggetti debugger nativi nelle estensioni JavaScript.

Per informazioni generali sull'uso di JavaScript, vedere Scripting del debugger JavaScript.

Considerazioni sulla progettazione del modello di dati del debugger

Principi di progettazione

Considera i seguenti principi per far sì che le estensioni del debugger presentino informazioni individuabili, interrogabili e scriptabili.

• Le informazioni sono vicine alla posizione in cui sono necessarie. Ad esempio, le informazioni su una chiave del Registro di sistema devono essere visualizzate come parte di una variabile locale che contiene un handle di chiave del Registro di sistema.
• Le informazioni sono strutturate. Ad esempio, le informazioni su una chiave del Registro di sistema vengono presentate in campi separati, ad esempio il tipo di chiave, l'ACL della chiave, il nome della chiave e il valore. Ciò significa che è possibile accedere ai singoli campi senza analizzare il testo.
• Le informazioni sono coerenti. Le informazioni sugli handle delle chiavi del Registro di sistema vengono presentate in modo analogo alle informazioni sugli handle di file.

Evitare questi approcci che non supportano questi principi.

• Non organizzare gli elementi in un unico contenitore "Kitchen sink". Una gerarchia organizzata consente agli utenti di cercare le informazioni che cercano senza conoscere in precedenza ciò che cercano e supportano l'individuabilità.
• Non convertire un'estensione dbgeng classica semplicemente spostandola nel modello, continuando a visualizzare output di testo grezzo. Questo non è componibile con altre estensioni e non può essere sottoposto a query con espressioni LINQ. Suddividere invece i dati in campi separati ed interrogabili.

Linee guida per la denominazione

• Lo stile di capitalizzazione dei campi deve essere PascalCase. È possibile considerare un'eccezione per i nomi ampiamente conosciuti in un'altra tipografia di maiuscole e minuscole, ad esempio jQuery.
• Evitare di usare caratteri speciali che normalmente non verrebbero usati in un identificatore C++. Ad esempio, evitare di usare nomi come "Total Length" (che contiene uno spazio) o "[size]" (che contiene parentesi quadre). Questa convenzione consente un utilizzo più semplice dai linguaggi di scripting in cui questi caratteri non sono consentiti come parte degli identificatori e consente anche un utilizzo più semplice dalla finestra di comando.

Linee guida per l'organizzazione e la gerarchia

• Non estendere il livello principale dello spazio dei nomi del debugger. È invece consigliabile estendere un nodo esistente nel debugger in modo che le informazioni vengano visualizzate dove sono più rilevanti.
• Non duplicare i concetti. Se si sta creando un'estensione del modello di dati che elenca informazioni aggiuntive su un concetto già esistente nel debugger, estendere le informazioni esistenti anziché provare a sostituirle con nuove informazioni. In altre parole, un'estensione che visualizza i dettagli su un modulo deve estendere l'oggetto Module esistente anziché creare un nuovo elenco di moduli.
• I comandi di utilità a fluttuazione libera devono far parte dello spazio dei nomi Debugger.Utility. Devono anche essere sottospaziati correttamente (ad esempio Debugger.Utility.Collections.FromListEntry)

Compatibilità con le versioni precedenti e modifiche di rilievo

Uno script pubblicato non deve interrompere la compatibilità con altri script che dipendono da esso. Ad esempio, se una funzione viene pubblicata nel modello, deve rimanere nella stessa posizione e con gli stessi parametri, quando possibile.

Nessun uso di risorse esterne

• Le estensioni non devono generare processi esterni. I processi esterni possono interferire con il comportamento del debugger e si comporteranno in modo errato in vari scenari del debugger remoto (ad esempio dbgsrv remoti, ntsd remoti e "ntsd -d remoti")
• Le estensioni non devono visualizzare alcuna interfaccia utente. La visualizzazione degli elementi dell'interfaccia utente si comporta in modo non corretto negli scenari di debug remoto e può interrompere gli scenari di debug della console.
• Le estensioni non devono modificare il motore del debugger o l'interfaccia utente del debugger tramite metodi non documentati. Ciò causa problemi di compatibilità e si comporta in modo non corretto nei client del debugger con un'interfaccia utente diversa.
• Le estensioni devono accedere alle informazioni di destinazione solo tramite le API del debugger documentate. Il tentativo di accedere alle informazioni su una destinazione tramite LE API win32 avrà esito negativo per molti scenari remoti e anche per alcuni scenari di debug locali attraverso i limiti di sicurezza.

Nessun uso di funzionalità specifiche di Dbgeng

Gli script che devono essere usati come estensioni non devono basarsi su funzionalità specifiche di dbgeng quando possibile, ad esempio l'esecuzione di estensioni del debugger "classiche". Gli script devono essere utilizzabili su qualsiasi debugger che ospita il modello di dati.

Test delle estensioni del debugger

È previsto che le estensioni funzionino in un'ampia gamma di scenari. Anche se alcune estensioni possono essere specifiche di uno scenario ,ad esempio uno scenario di debug del kernel, la maggior parte delle estensioni dovrebbe funzionare in tutti gli scenari o avere metadati che indicano gli scenari supportati.

Modalità kernel

• Debug del kernel in tempo reale
• Debug del dump del kernel

Modalità utente

• Eseguire il debug in modalità utente live
• Debug del dump in modalità utente

Considerare anche questi scenari di utilizzo del debugger

• Debug multiprocesso
• Debug multisessione (ad esempio dump + utente attivo all'interno di una singola sessione)

Utilizzo del debugger remoto

Testare il funzionamento corretto con gli scenari di utilizzo del debugger remoto.

• dbgsrv remotes
• ntsd remotes
• ntsd -d remoti

Per altre informazioni, vedere Debug con CDB e NTSD e Attivazione di un server di elaborazione.

Test di regressione

Esaminare l'uso dell'automazione dei test in grado di verificare la funzionalità delle estensioni, man mano che vengono rilasciate nuove versioni del debugger.

Vedere anche

oggetti debugger nativi nelle estensioni JavaScript

Oggetti debugger nativi nelle estensioni JavaScript - Dettagli oggetto debugger.

JavaScript Debugger Scripting

Script di esempio del debugger JavaScript