Debugowanie — podstawy

W programowaniu (również scenariuszy testów automatycznych) niezbędną umiejętnością jest debugowanie. Pozwala nam wykrywać miejsce, gdzie popełniliśmy błąd, czego nie przewidzieliśmy. Jest również nieodzowne w pisaniu testów automatycznych. Dzięki pomocy Visual Studio możemy to zrobić.

Czego potrzebujemy?

• Kod z poprzednich części wraz z pakietami NuGet
• Visual Studio
• ChromeDriver (przykładów nie testuje na innych driverach, więc może się zdarzyć, że kod ze wpisów może inaczej się zachowywać na innych driverach).
• R#

Czym jest debugowanie?

Debugowanie jest procesem systematycznego redukowanie liczby błędów w oprogramowaniu polegającym na kontrolowanym wykonaniu programu pod nadzorem debuggera [1]. W uproszczeniu debugger pozwala na wykonywanie kodu programu linia po linii, podglądanie wartości zmiennych i wiele innych. W efekcie możemy w dość łatwy sposób wykryć defekty oprogramowania, w tym również testów automatycznych.

Dla platformy .NET najbardziej rozpowszechnionym debuggerem jest narzędzie dostarczone wraz z platformą Visual Studio i z niego będziemy korzystali na potrzeby dzisiejszego wpisu.

Debugger

Podsumowując, debugger umożliwia:

• Wykonywanie programu w trybie pracy krokowej lub z zastawianiem tzw. pułapek (ang. breakpoints)
• podglądanie i ewentualną zmianę zawartości rejestrów, pamięci

Proces debugowania może wyglądać tak:

1. Uruchomienie krokowe oprogramowania.
2. Znalezienie źródła błędu.
3. Poprawienie błędu.
4. Weryfikacja czy poprawka pomogła.

Dla osób, które nie miały do czynienia z debuggerem może wydawać się to trudne, ale na przykładzie Selenium WebDriver w połączeniu z  C# pokażę, że jest to dość proste.

Przechodzimy do naszego ostatniego przykładu z kodem (drugi wpis). Zmieńmy wartość zmiennej amountOfPosts na 1 (Na blogu mamy 2 posty, więc zmiana na jeden będzie powodować błąd w teście).

Breakpoint (czerwona kropka widoczna na grafice poniżej) dodajemy poprzez kliknięcie na szarym obszarze obok kodu. Po uruchomieniu programu jego wykonanie zostanie wstrzymane w tym właśnie miejscu.

Żeby uruchomić debugowanie, klikamy PPM na kulkę – > Debug

Gdy uruchomimy nasz test w trybie „Debug”, program zatrzymuje się przy  wspomnianej kropce.

Zatrzymaliśmy się i co dalej?

• F10 – step over – przenosi do następnego kroku bieżącego pliku
• F11 – step into – pozwala wejść w metodę, przenosi do źródła wywoływanej metody
  Dla prostych operacji działanie step over i step into jest identyczne.

Gdy najedziemy na zmienną pageUrl to Visual Studio, pokaże nam, jaką ma wartość. Możemy również najechać na zmienną  driver. W podglądzie otrzymamy informację o wszystkich własnościach instancji WebDrivera.

W zakładce „Watch” możemy dodawać i obserwować zmienne. Ich wartości są odświeżane w czasie rzeczywistym.

Teraz gdy klikniemy F10 driver.Url zmieni się z ”data;” na http://testowaniebloga.ghost.io/ 

Visual Studio wyróżnia tę zmianę kolorem czerwonym.

Jak widzimy, jest to bardzo przydatne i gdy tylko pojawi się błąd w naszych testach z wartością lub przypisaniem, to szybko zlokalizujemy problem. Zależnie od ustawień VS może się zatrzymać lub nie przy danym błędzie.

Kolejnym krokiem będzie dodanie zmiennej „pageDescription” do „Watch”, która zawiera tekstowy opis strony.

Dodatkowo dodałem do watch zmienną postDates, która zawiera elementy z datą w postaci kolekcji elementów.

Dzięki debugowaniu widzimy wszystko, co każdy element zawiera.

F10 przechodzimy kolejno po krokach, aż do listOfPosts.

Uruchomienie testów w trybie debug bez zaznaczonych breakpointów spowoduje wstrzymanie wykonanie dopiero w momencie wystąpienia błędu.

Visual Studio w trybie Debug pokazuje dokładnie, która linijka spowodowała wstrzymanie.

Podsumowanie

Dzisiaj poznaliśmy jedną z najważniejszy metod znajdowania błędów w kodzie. Jest to podstawowa technika, która jest częścią codziennej pracy programisty / programisty testów.

P.S

Podziękowania dla Przemka Secha za pomoc przy edycji.

Bibliografia

MS.