CodeceptJS – interaktywny shell – Jak może pomóc w testach?

CodeceptJS – interaktywny shell – W jaki sposób może pomóc w testach?

Witajcie.

W poprzednim poście rozpoczynającym serię wpisów na temat CodeceptJS nauczyliśmy się jak stworzyć pierwszy test oraz w jaki sposób zainicjować projekt. Dziś zajmiemy się dalszymi aspektami poznawania CodeceptJS , którego używam do projektu testów w konkursie DajSiePoznać (link). Z dzisiejszego wpisu nauczymy się jak uruchomić CodeceptJS  w trybie interaktywnym (shell), dzięki czemu nasze testy będziemy mogli tworzyć szybciej. Tryb interaktywny pozwala bowiem szybko sprawdzić, czy nasz krok (czyli zapisana metoda po „I” np. I.click(‚element’)) uruchomia się oraz równocześnie zobaczyć efekt działania kodu. Rezultat działania testu widzimy szybciej niż przez codeceptjs run. Testy możemy pisać w taki sposób:

  • Wpisujemy metodę po metodzie w shellu
  • Jeżeli dany krok po „I.”  jest dobry to kopiujemy daną linijkę do testu w naszym IDE
  • Dzięki temu gdy jest błąd od razu wiemy w której linijce / kroku

Czego potrzebujemy?

  • Przygotowanego projektu tak jak w pierwszej części serii o codeceptjs (link)
  • Strony, na której będziemy pisać testy. (Ja wykorzystam stronę aplikacji, którą wystawił mi Bartek (link))
  1. Włączamy terminal.
  2. Przechodzimy do katalogu, w którym mamy testy.

codeceptjs      3. Następnie w terminalu używamy komendy:

codeceptjs shell

      4. Dalej wpisujemy metodę I.amOnPage(‚/) specjalnie z błędem, by zobaczyć jak framework się zachowa. Jak widzimy występuję błąd.

      5. Kolejnym krokiem jest wpisanie I.amOnPage(‚/’) metody, która przeniesie nas do do strony testowanej.

      6. Następnie używamy metody I.see(”), która pozwala sprawdzić, czy dany element jest widoczny na stronie.

      7. Po innych użyciach metody I.see(”). Używam metody I.click(‚.red’) dzięki temu, zostaje kliknięty przycisk MORE. Klikamy w selector „.red”, który ma przycisk MORE.

Zrzut ekranu 2017-03-26 o 21.08.59
Zrzut ekranu 2017-03-26 o 21.01.01

 

Zrzut ekranu 2017-03-26 o 21.03.14

 

 

Podsumowanie

Zatem w tym poście dowiedzieliśmy się, w jaki sposób możemy używać powłoki shell w naszych testach. Dzięki niej możemy krok po kroku sprawdzać rezultat z uruchomienia danego testu. Jest to szybki sposób, jeżeli chcemy „na szybko” sprawdzić, czy krok, który chcemy wykonać, przejdzie. W następnych częściach dowiemy się m.in. w jaki sposób używać wzorca Page Object Pattern oraz innych przełączników podczas uruchamiania testów.

 

Debugowanie – testów automatycznych w C#

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.

debug1

debug2

Ż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.

debug3

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.

debugowanie w VS

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

 

debugowanie w VS

 

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.

debugowanie w VS

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

debugowanie w VS

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

[1] Debugowanie – https://pl.wikipedia.org/wiki/Debugowanie

 

MS.