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
Considerare i principi seguenti per rendere le estensioni del debugger presentino informazioni individuabili, eseguibili su query e scriptable.
- 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'elenco di controllo di accesso alla 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 di chiave del Registro di sistema vengono presentate nel modo più simile possibile alle informazioni sugli handle di file.
Evitare questi approcci che non supportano questi principi.
- Non strutturare gli elementi in un unico "sink cucina". Una gerarchia organizzata consente agli utenti di cercare le informazioni che stanno cercando senza conoscere in precedenza ciò che cercano e supportano l'individuabilità.
- Non convertire un'estensione dbgeng classica semplicemente spostandola nel modello durante l'output di schermate di testo non elaborato. Non è componibile con altre estensioni e non può essere eseguita una query con espressioni LINQ. Suddividere invece i dati in campi separati e eseguibili da query.
Linee guida per la denominazione
- La maiuscola dei campi deve essere PascalCase. Un'eccezione può essere considerata per i nomi ampiamente noti in un'altra combinazione di maiuscole e minuscole, ad esempio jQuery.
- Evitare di usare caratteri speciali che normalmente non vengono usati in un identificatore C++. Ad esempio, evitare di usare nomi come "Lunghezza totale" (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 consentono 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 necessario 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 relativi a un modulo deve estendere l'oggetto Module esistente anziché creare un nuovo elenco di moduli.
- I comandi dell'utilità mobile libera devono far parte dello spazio dei nomi Debugger.Utility . Devono anche essere sotto spazio dei nomi in modo appropriato (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 comportano in modo errato in vari scenari di debugger remoti (ad esempio dbgsrv remoti, remote ntsd e "ntsd -d remotes")
- 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 API win32 avrà esito negativo per molti scenari remoti e anche per alcuni scenari di debug locali oltre 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
- Debug in modalità utente live
- Debug del dump in modalità utente
Considerare inoltre questi scenari di utilizzo del debugger
- Debug di più processi
- Debug multisessione (ad esempio dump + utente live all'interno di una singola sessione)
Utilizzo del debugger remoto
Eseguire il test per un'operazione corretta con gli scenari di utilizzo del debugger remoto.
- dbgsrv remotes
- ntsd remotes
- ntsd -d remotes
Per altre informazioni, vedere Debug tramite CDB e NTSD e Attivazione di un server di elaborazione.
Test di regressione
Esaminare l'uso dell'automazione di test in grado di verificare la funzionalità delle estensioni, man mano che vengono rilasciate nuove versioni del debugger.
Vedi anche
Oggetti debugger nativi nelle estensioni JavaScript
Oggetti debugger nativi nelle estensioni JavaScript - Dettagli dell'oggetto debugger.