Natywne obiekty debugera w rozszerzeniach języka JavaScript — zagadnienia dotyczące projektowania i testowania

W tym temacie opisano zagadnienia dotyczące projektowania i testowania dotyczące używania natywnych obiektów debugera w rozszerzeniach języka JavaScript.

Natywne obiekty debugera reprezentują różne konstrukcje i zachowania środowiska debugera. Obiekty można przekazać do rozszerzeń języka JavaScript (lub uzyskanych w nich), aby zarządzać stanem debugera.

Aby uzyskać informacje o rozszerzeniach JavaScript obiektu debugera, zobacz Native Debugger Objects in JavaScript Extensions (Natywne obiekty debugera w rozszerzeniach języka JavaScript).

Aby uzyskać ogólne informacje na temat pracy z językiem JavaScript, zobacz JavaScript Debugger Scripting (Skrypty debugera języka JavaScript).

Zagadnienia dotyczące projektowania modelu danych debugera

Zasady projektowania

Weź pod uwagę następujące zasady, aby rozszerzenia debugera przedstawiały informacje, które można odnajdywać, wykonywać zapytania i tworzyć skrypty.

• Informacje znajdują się w odpowiednim miejscu tam, gdzie są potrzebne. Na przykład informacje o kluczu rejestru powinny być wyświetlane jako część zmiennej lokalnej zawierającej uchwyt klucza rejestru.
• Informacje są ustrukturyzowane. Na przykład informacje o kluczu rejestru są prezentowane w oddzielnych polach, takich jak typ klucza, lista ACL kluczy, nazwa klucza i wartość. Oznacza to, że dostęp do poszczególnych pól można uzyskać bez analizowania tekstu.
• Informacje są spójne. Informacje o dojściach klucza rejestru są prezentowane w sposób jak najbardziej podobny do informacji o dojściach do plików.

Unikaj tych podejść, które nie obsługują tych zasad.

• Nie należy układać swoich przedmiotów w jeden płaski "zlew kuchenny". Zorganizowana hierarchia umożliwia użytkownikom przeglądanie szukanych informacji bez wcześniejszej wiedzy na temat tego, czego szukają i obsługuje odnajdywanie.
• Nie konwertuj klasycznego rozszerzenia dbgeng, po prostu przenosząc go do modelu, jednocześnie wyświetlając ekrany nieprzetworzonego tekstu. Nie można tego komponować z innymi rozszerzeniami i nie można wykonywać zapytań dotyczących wyrażeń LINQ. Zamiast tego należy podzielić dane na oddzielne pola z możliwością wykonywania zapytań.

Wytyczne dotyczące nazewnictwa

• Wielkość liter w nazwach pól powinna być zgodna z formatem PascalCase. Dla nazw, które są powszechnie znane w innej formie zapisu literowego, na przykład jQuery, można rozważyć wyjątek.
• Unikaj używania znaków specjalnych, które normalnie nie będą używane w identyfikatorze języka C++. Na przykład unikaj używania nazw, takich jak "Łączna długość" (zawierająca spację) lub "[size]" (zawierające nawiasy kwadratowe). Ta konwencja umożliwia łatwiejsze użycie z języków skryptowych, w których te znaki nie są dozwolone w ramach identyfikatorów, a także umożliwia łatwiejsze użycie w oknie poleceń.

Wytyczne dotyczące organizacji i hierarchii

• Nie rozszerzaj najwyższego poziomu przestrzeni nazw debugera. Zamiast tego należy rozszerzyć istniejący węzeł w debugerze, tak aby informacje są wyświetlane tam, gdzie są najbardziej istotne.
• Nie duplikuj pojęć. Jeśli tworzysz rozszerzenie modelu danych zawierające listę dodatkowych informacji o koncepcji, która już istnieje w debugerze, rozszerz istniejące informacje, zamiast próbować zastąpić je nowymi informacjami. Innymi słowy, rozszerzenie, które wyświetla szczegółowe informacje o module, powinno rozszerzyć istniejący obiekt modułu zamiast tworzyć nową listę modułów.
• Bezpłatne przestawne polecenia narzędzi muszą być częścią przestrzeni nazw Debugger.Utility . Powinny być również odpowiednio umieszczone w podrzędnych przestrzeniach nazw (np. Debugger.Utility.Collections.FromListEntry)

Zgodność z poprzednimi wersjami i zmiany powodujące niezgodność

Opublikowany skrypt nie powinien przerywać zgodności z innymi skryptami, które od niego zależą. Jeśli na przykład funkcja zostanie opublikowana w modelu, powinna pozostać w tej samej lokalizacji i z tymi samymi parametrami, jeśli jest to możliwe.

Brak użycia zasobów zewnętrznych

• Rozszerzenia nie mogą uruchamiać procesów zewnętrznych. Procesy zewnętrzne mogą zakłócać działanie debugera i mogą działać niepoprawnie w różnych scenariuszach zdalnego debugera (np. zdalnego dbgsrv, zdalne ntsd i zdalne "ntsd -d")
• Rozszerzenia nie mogą wyświetlać żadnego interfejsu użytkownika. Wyświetlanie elementów interfejsu użytkownika będzie działać niepoprawnie w scenariuszach zdalnego debugowania i może przerwać scenariusze debugowania konsoli.
• Rozszerzenia nie mogą manipulować aparatem debugera ani interfejsem użytkownika debugera za pomocą nieudokumentowanych metod. Powoduje to problemy ze zgodnością i będzie działać niepoprawnie na klientach debugera z innym interfejsem użytkownika.
• Rozszerzenia muszą uzyskiwać dostęp do informacji docelowych tylko za pośrednictwem udokumentowanych interfejsów API debugera. Próba uzyskania dostępu do informacji o obiekcie docelowym za pośrednictwem interfejsów API win32 zakończy się niepowodzeniem w przypadku wielu scenariuszy zdalnych, a nawet niektórych lokalnych scenariuszy debugowania w granicach zabezpieczeń.

Brak użycia funkcji specyficznych dla dbgeng

Skrypty, które mają być używane jako rozszerzenia, nie mogą polegać na funkcjach specyficznych dla dbgeng zawsze, gdy jest to możliwe (takich jak wykonywanie "klasycznych" rozszerzeń debugera). Skrypty powinny być używane na dowolnym debuggerze, który hostuje model danych.

Testowanie rozszerzeń debugera

Oczekuje się, że rozszerzenia będą działać w wielu różnych scenariuszach. Chociaż niektóre rozszerzenia mogą być specyficzne dla scenariusza (takiego jak scenariusz debugowania jądra), większość rozszerzeń powinna działać we wszystkich scenariuszach lub mieć metadane wskazujące obsługiwane scenariusze.

Tryb jądra

• Debugowanie jądra na żywo
• Debugowanie zrzutu jądra

Tryb użytkownika

• Debugowanie trybu użytkownika na żywo
• Debugowanie zrzutu trybu użytkownika

Ponadto należy wziąć pod uwagę te scenariusze użycia debugera

• Debugowanie wielu procesów
• Debugowanie wielu sesji (np. zrzut pamięci i sesja użytkownika na żywo w ramach jednej sesji)

Użycie debugera zdalnego

Przetestuj poprawną operację za pomocą scenariuszy użycia zdalnego debugera.

• dbgsrv remotes
• zdalne sesje ntsd
• ntsd -d remotes

Aby uzyskać więcej informacji, zobacz Debugowanie przy użyciu usługi CDB i NTSD oraz Aktywowanie serwera przetwarzania.

Testowanie regresji

Zbadaj użycie automatyzacji testów, która może zweryfikować funkcjonalność rozszerzeń, ponieważ są wydawane nowe wersje debugera.

Zobacz także

natywnych obiektów debugera w rozszerzeniach Języka JavaScript

Natywne obiekty debugera w rozszerzeniach Języka JavaScript — szczegóły obiektu debugera.

Skrypty debugowania JavaScript

Przykładowe skrypty debugera JavaScript