Selenium WebDriver dodawanie pluginów na przykładzie AdBlocka

Selenium WebDriver dodawanie pluginów na przykładzie AdBlocka

Czy mieliście kiedyś wyzywanie sprawdzenia jak wasza strona, zachowuje się z np. AdBlockiem? Dziś chce wam pokazać, że dodanie tej wtyczki jest bardzo proste i praktycznie od zaraz możecie uruchomić z nią wasze testy.

Zaczynamy!

Czego potrzebujemy?

  • Visual Studio 2017
  • Chrome
  • Zainstalowany AdBlock w Chrome

Zaczynamy od znalezienia na naszym dysku AdBlocka. Powinien być on w takiej ścieżce:

C:\\Users\\<NameOfUser>\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Extensions\\<StringOfExtensions>\\<version>

  • <NameOfUser> – Nazwa waszego użytkownika
  • <StringOfExtensions> – ID interesującego nas pluginu
  • <version> – wersja interesującego nas pluginu

Pamiętajcie, że wersja pluginu, jeżeli macie ustawione  aktualizowanie  może się zmieniać i trzeba pamiętać o tym przy projektowaniu testów.

Jak poznać nazwę interesującego nas pluginu do w Chrome?

Jeżeli mamy zainstalowany dany dodatek jest to prosta sprawa.

Wpisujemy w pasek adresu  – chrome://extensions/

Zaznaczamy  checkbox „Developer mode”

 DeveloperMode dla pluginów Chrome

DeveloperMode dla pluginów Chrome

Dzięki temu zacznie być widoczne ID danego dodatku. Dla AdBlocka jest to:

DeveloperMode dla pluginów Chrome

ID (string) pluginu

Przechodzimy do Visual Studio

Stworzyłem projekt typu Class Library.

Dodawanie interesującego nas pluginu na przykładzie AdBlocka

Dodawanie interesującego nas pluginu na przykładzie AdBlocka

Zaczynamy od utworzenia obiektu typu ChromeOptions. Jest to klasa, która pozwala dodawać nam ustawienia, które chcemy dla uruchamianego przez nas ChromeDrivera.

Metoda AddArguments pozwala dodać  listę argumentów, które będą wczytywane wraz z załadowaniem Chrome.exe.  Używamy flagi load-extensions, która pozwala nam załadować plugin, który nas interesuje i nasza przeglądarka zostanie uruchomiona wraz z nim.

Po stworzeniu obiektu klasy ChromeOptions() przekazujemy go do naszego obiektu ChromeDrivera().

Następnie przechodzimy do zarejestrowania naszego obiektu w prostym kontenerze DI dla SpecFlow, nie jest to niezbędne, ale wiem, że często poszukujecie bardziej realnych przykładów na Context Injection w SpecFlow więc ten przykład również może pomóc wam zrozumieć idee.

Dodałem również klasę SeleniumHelper, która zawiera przydatną metodę CloseSecondTabFromPlugin(). AdBlock po dodaniu prezentuje swoją stroną na, które możemy dokonać dotacji dla nich. Potrzebujemy zamknać tą stronę.

W linijce [18] korzystamy z klasy WaitHelper, która ma zaimplementowane dynamiczne czekanie na zadany element dlatego, że korzysta z klasy WebDriverWait.

W tym przypadku czekamy maksymalnie 15 sekund (lub mniej, jeżeli jest element możliwy do znalezienia w krótszym czasie), na wczytanie się właściwości driver.WindowsHandles, która przechowuje informacje o oknach ChromeDriver’a.

Klasa WaitHelper z metodę Wait(), która zwraca obiekt typu WebDriverWait

 

ChromeDriver wraz z AdBlockiem

ChromeDriver wraz z AdBlockiem

Przykład również dostępny jest na moim GitHubie:

https://github.com/testingplusme/AddAdblockExampleToChromeDriver

Podsumowanie

Jak widzie w kilka minut jesteśmy w stanie uruchomić naszego ChromeDrivera z dodanym pluginem – takim jakim chcemy. Może być to dla was przydatne dla sprawdzenia, czy wszystkie elementy na stronie zachowują się prawidłowo również z dodanym AdBlockiem. Zdarza się, że AdBlock źle sklasyfikuje określony elementem. Innym scenariuszem jest sprawdzenie, jeżeli jesteście np. wydawcą treści czy skrypt, która macie do blokowania AdBlocka wyświetla się zawsze, wtedy kiedy powinien.

 

Page Object Model – Wzorzec, który ułatwi Wam implementowanie testów w Selenium WebDriver.

Page Object Model – Wzorzec, który jest nieodzowny w testowaniu automatycznym stron www.

Dzisiaj chcę przedstawić wam jeden z najbardziej podstawowych wzorców projektowych używany przy implementowaniu testów automatycznych. Pokażę jak w prosty sposób możecie go zastosować przy użyciu C# + Selenium WebDriver. Jeżeli ktoś z Was nie słyszał o tym wzorcu, dowie się jakie korzyści płyną z korzystania z niego w swoich testach. Przykład będzie prosty na tyle, na ile to jest możliwe.

Z tekstu dowiesz się m.in:

  • Jak budować testy, które będą łatwiejsze w utrzymaniu i implementowaniu ?
  • Jak zmniejszyć ilość duplikowanego kodu?

Czym jest Page Object Model?

 

 

folwer

 

Martin Folwer

źródło „ http://martinfowler.com/bliki/PageObject.html

Jest to sposób pisania testów polegający na tym, że każdą ze stron danej aplikacji webowej przedstawiamy jako tzw. Page object. Każdy z elementów na stronie, którą testujemy możemy przedstawić w naszej implementacji jako obiekt typu IWebElement (Może != Musi, jeżeli danego elementu znajdującego się na stronie, którą testujemy nie potrzebujemy w teście, to nie implementujemy go, by nie zaciemniać kodu).

Czego będziemy potrzebować do zdeklarowania naszego elementu w teście?

Do zdeklarowania elementu w teście potrzebujemy użyć tak jak przy deklaracji IWebElement – jakiegoś selectora. Do wyboru mamy:

  • XPath,
  • CssSelector,
  • Id,
  • Name,
  • Class,
  • PartialLinkText,
  • LinkText,

Pozwala to w jednym miejscu posiadać deklaracje obiektu IWebElement, który odpowiada elementowi na stronie. Jeżeli na stronie będzie dokonana jakaś zmiana np. selector Id przycisku zmieni się z „buttonId” na „buttonNewId” dzięki używaniu page object model – zmiany selectora dokonujemy w jednym miejscu.

Przykładowy obiekt:

[FindsBy(How=How.Id,Using = „user_login”)]

public IWebElement LoginField { get; set; }

Programista wprowadza zmianę  w html, od teraz element, który na stronie to selector user_login po zmianie to user_login_foo.  Gdy zamienimy user_login na user_login_foo to w testach w których wszędzie używaliśmy tego elementu zachodzą takie zmiany. Jeżeli nie używalibyśmy Page Object Model to w każdym teście gdzie używalibyśmy IWebElement z selectorem „user_login” trzeba byłoby zmienić na „user_login_cos”.

Po co stosować Page Object Model?

– Pozwala oddzielić logikę metod robiących akcje na stronie od reprezentacji elementów na stronie w postaci obiektów IWebElement

-Pozwala w łatwiejszy sposób zrozumieć abstrakcje związaną z pisaniem testów

-Pozwala łatwiej utrzymywać testy, jeżeli zmienia się selector na stronie np. poprzez zmianę układu strony to selector do elementu zmieniamy tylko w jednym miejscu. Jeżeli nie stosujemy Page Object Model to należy we wszystkich testach zmienić dany selector.

Przechodzimy do części napisania dwóch prostych testów, które będą korzystały ze wzorca page object model.

Co będzie Ci potrzebne?

  • Postawiona testowa strona wordpress.com.  -Ja użyję w tym celu swojego bloga, którego stworzyłem do pisania testów.(https://studytestingblog.wordpress.com/). Możesz również lokalnie postawić sobie takiego wordpressa.
  • Visual Studio

Dodane do projektu

  • ChromeDriver (przykładów nie testuje na innych driverach, więc może się zdarzyć, że kod z wpisów może inaczej się zachowywać na innych driverach).
  • Dodane przez NuGet’a:

page object model

Do projektu z testami dodaję folder Pages – Miejsce gdzie będziemy umieszczać nasze klasy z reprezentacją danego widoku na stronie.

pom3

Tworzymy plik klasy HomePage.cs

page object model

Sama klasa, którą użyje do testu wygląda tak:

  • Zaczynamy od definicji Driver, który jest/może być potrzebny do metod w Page’ach.
  • Następnie definiuje kilka elementów, które znajdują się na stronie.

https://studytestingblog.wordpress.com/wp-login.php

page object model

Aby stworzyć properites, który będzie odzwierciedlał element na stronie używamy:

[FindsBy(How= Tutaj wpisujemy jakiego selectora używamy  np. How.Id,Using = „tutaj wartość tego selectora np. user_login”)]

 LoginField  – properties, który reprezentuje pole służące do wpisywania loginu;

Selectory „zdobywamy” tak jak pokazywałem to w jednym ze wcześniejszych wpisów (link).

PasswordField – properties, który reprezentuje pole służące do wpisywania hasła;

SubmitButton – properties, który reprezentuje przycisk do wysłania formularza;

ErrorBox – propeties, który reprezentuje div’a zawierającego komunikaty o błędach (jeżeli jest na stronie np. gdy próbujemy zalogować się złym hasłem);

Po dodaniu propertiesów tworzymy konstruktor z parametrem.

Parametr jest typu IWebDriver. Powoduje to, że możemy przekazać każdy Driver, który implementuje interfejs IWebDriver. Gdybyśmy wpisali jako parametr ChromeDriver driver, zamiast IWebDriver driver to nie moglibyśmy w teście przekazać np. FirefoxDriver’a

this.Driver=driver;

Powoduje to, że nasz properties Driver będzie miał przypisaną referencje przekazanego driver’a, gdy stworzymy nowy obiekt typu HomePage.

PageFactory.InitElements(driver, this); <- Powoduje, że w konstruktorze inicjalizowane są elementy z tego Page’a. Gdybyśmy tego nie zrobili to test w miejscu gdzie używany byłby element z klasy HomePage rzuciłby błędem NullReferenceException dlatego, że element nie miałyby referencji.

pom5

Kolejnym elementem, który zaimplementujemy jest stworzenie metody odpowiadającej za logowanie do strony. Zmniejsza to ilość kodu w teście, łatwiej się go analizuje oraz nie trzeba w każdym teście pisać mechanizmu logowania.

Raz napisana metoda jest reużywalna w innych testach.

Metoda, którą napiszemy będzie zawierać:

Dwie właściwości, które są typu IWebElement (więc posiadają „po kropce” dostęp do metody SendKeys(„”);, odpowiadającej za wpisywanie znaków).

W parametrze będziemy przekazywać login i hasło.

Następnie po wpisaniu klikniemy w przycisk „Log In”  czyli w naszym przykładzie SubmitButton.Click();

Metoda jest typu DashboardPage i zwracamy return new DashboardPage(Driver);

logujemy się i test przenosi nas do Dashboard’u (Tak działa zalogowanie się do panelu admina w wordpressie).

pom6
devenv_2017-04-02_12-59-33

Po stworzeniu metody logującej tworzymy w folderze Tests folder Login. Dobre ułożenie testów po folderach pozwala zachować porządek w solucji. W folderze Login tworzymy klasę CheckLoginFunctionality.cs.  Stworzymy dwa testy, które sprawdzą w różnej konfiguracji:

  • Czy po zalogowaniu URL jest prawidłowy.
  • Czy gdy podamy złe hasło wyświetlany jest prawidłowy komunikat walidacyjny.

page object model

Testy zaczynamy od deklaracji zmiennej driver typu IWebDriver.

W setupie definiujemy zmienną driver typu ChromeDriver. Następnie przechodzimy do stworzenia w teście obiektu typu HomePage w parametrze przekazujemy obiekt driver.

CommonHelper.cs  – to klasa, która zawiera dwa properties’y. Jeden z loginem, drugi z hasłem do panelu administracyjnego.

Na końcu pierwszego testu znajduję się asercja sprawdzająca czy adres URL Driver’a jest taki jak oczekujemy po zalogowaniu. W drugim teście dodałem więcej asercji, żeby pokazać Wam jakie inne rzeczy możemy sprawdzać.

Assert.IsTrue(home.ErrorBox.Displayed) – sprawdza czy ErrorBox wyświetlił się.

Ostatnia asercja sprawdza czy komunikat walidacyjny jest prawidłowy znak po znaku.

W [TeardDown]

znajduję się metoda Close(), która zamyka po każdym teście przeglądarkę za pomocą driver.Dispose();

Próbujemy uruchomić nasz test. Testy wyświetlają się na zielono. Jednak gdy uruchamiam je drugi raz. Pojawia się błąd przy jednym z testów. Widać, że Selenium WebDriver zbyt szybko wpisuje tekst. Dodamy klasę WaitHelper.cs, która będzie zawierał metodę, która czeka na wpisanie przez selenium tekstu w pole.

Klasa WaitHelper.cs

page object model

Następnie tworzymy metodę statyczną WaitUntilElementValueEquals, która zawiera trzy parametry:

this IWebDriver driver – każdy obiekt, który implementuje IWebDriver ma dostęp do tej metody „po kropce”,

IWebElement element – element, który będziemy przekazywać i w nim sprawdzać czy wartość zdążyła się wpisać,

valueToCheck – przekazujemy tu tekst na, który będziemy czekać, aż się pojawi jako wartości w elemencie,

W pierwszej linii metody tworzymy obiekt typu WebDriverWait, który pozwala czekać za pomocą Selenium. Jako parametr potrzebuje jakiegoś driver’a, oraz TimeSpan.

Ostatnim krokiem jest wywołanie metody Unitl, która czeka w zadanym czasie na to by wartość atrybtu naszego elementu przekazengo w metodzie była równa z valueToCheck

Po stworzeniu metody dodajemy ją do klasy HomePage i metody LoginOnPage

pom8

Dodajemy naszą metodę. Uruchamiamy testy.

pom9

Podsumowanie

Dzisiaj dowiedzieliśmy się czym jest wzorzec Page Object Model. Zachęcam do wypróbowania tego u siebie.

MS.

 

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.

 

Selenium WebDriver – Testowanie automatyczne aplikacji webowych

Post ten rozpocznie cykl wpisów na temat Selenium WebDriver. Tematykę tę chcę skierować zarówno do osób rozpoczynających przygodę z testowaniem automatycznym, jak i do osób, które szukają bardziej zaawansowanych rozwiązań.

Czym jest testowanie automatyczne?

Myślę, że każdy z nas, który testuje różnego rodzaju oprogramowania zastanawia się czy scenariusze, które są testowane manualnie w jakiś sposób da się zautomatyzować.  Czy czas, który jest wykorzystywany na testowanie manualnie, da się w jakiś sposób skrócić na wykonywaniu testów regresji naszego oprogramowania.

Przeklikiwanie aplikacji po każdej zmianie jest kosztowne w czasie.

Testy automatyczne znakomicie uzupełniają testy manualne. Większość testerów zgadza się, że niemożliwe jest, by całkowicie zastąpić testowanie manualne na rzecz automatycznego. Człowiek w niektórych kontekstach sprawuje się lepiej, a testy automatyczne są  tym co zaprogramowaliśmy. Wykonują powtarzalne kroki.

Chcę na przykładzie Selenium Web Driver z wykorzystaniem języka programowania C# przedstawić pisanie testów automatycznych od podstaw. W blogu znajdziecie m.in. odpowiedzi na pytania:

  • Jak kliknąć w dany element?
  • Jak pobrać wartość tekstową elementu?
  • W jaki sposób odwoływać się do elementów?
  • Czym jest wzorzec Page Object Model?
  • I wiele innych.

Testowanie automatyczne

Plusy:

  • możliwość po wytworzeniu scenariusza testowego, odtwarzania kroków w sposób powtarzalny
  • przy dobrze dobranych scenariuszach i np. uruchamianiu i utrzymywaniu testów automatycznych aplikacji, większa kontrola nad potencjalnym defektami w systemie

Minusy:

  •  utrzymywanie testów z każdą zmianą aplikacji kosztuje (Jednak przy użyciu wzorca projektowego Page Object Model o, którym kiedyś opowiem da się ten koszt czasowy utrzymania testów znacząco zmniejszyć)

 

Czego potrzebujemy, żeby pisać przy użyciu Selenium Webdriver?

Visual Studio

https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx

Selenium WebDriver

Selenium.WebDriver.Chrome – Jest to namespace, który reprezentuje przeglądarkę Chrome. Chrome jest najlepiej rozwiniętą przeglądarką w kontekście szybkości i rozwijalności driverów. Jest to przeglądarka dostosowana do Selenium. Potrzebujemy jakieś, aby Selenium wiedziało gdzie ma urchomić nasze testy automatyczne.

NUnit – jest to framework do pisania głównie testów jednostkowych. Jednak wiele innych testowych frameworków wykorzystuje NUnita pewnie dlatego, że jest gotowy i darmowy np. nasze Selenium WebDriver, Android UI Test, specFlow.

C# – na początku przygody z Selenium wystarczą podstawy na temat programowania.

R# – dodatek, który jest darmowy dla studentów, lub przez pierwsze 30 dni użytkowania dla każdego. Pomaga znacznie przy refraktoryzacji kodu. Dodatkowo stanowi dobre wsparcie dla NUnita i w dobry sposób prezentuje sesje testów. Podczas pisania testów będę go używał.

 

Tworzenie projektu

projekt1

W Visual Studio 2015 klikamy na „New” – > „Project”

Tworzymy aplikację typu class library – > Klikamy „OK”

Klikamy PPM na „TestyCw”.

Klikamy na „Manage NuGet Packages…”.

W Browse wpisujemy NUnit.

Dla Selenium WebDriver oraz Chrome również wykonujemy te kroki.

Wchodzimy do „Class1” Jest to miejsce gdzie będziemy pisać nasz kod testu.

Zmieniamy nazwę klasy na „EnterToPage”. Klasa powinna odzwierciedlać to, co będziemy robić w danych testach. Ponieważ klasa może posiadać wiele testów. Co moim zdaniem jest średnią praktyką. Osobiście preferuje każdy test w osobnej klasie. Jest to wtedy jasne, że dana klasa ma w sobie jeden określony scenariusz, swoją unikalną nazwą.

projekt2

[TextFixture] nadajemy w każdej klasie, która ma być klasą zawierając test. Jest to przez niektórych nazywane kontekstem testowym.

https://en.wikipedia.org/wiki/Test_fixture

[Test] Każdy test składa się z metody, która posiada atrybut [Test], pozwala to NUnitowi rozpoznać dany test. Bez tego atrybutu nie jest on widoczny.

Jest wiele innych atrybutów, które posiadają różną rolę. Sukcesywnie z kolejnymi wpisami będę przedstawiał większą ich ilość.

projekt3

Następnie przechodzimy do stworzenia Drivera. Driver jest naszą instancją, która pozwala odwoływać do danej, wybranej przeglądarki.

projekt4

Jak widać na zdjęciu mam spore możliwości. Ja na początek polecam  ChromeDrivera, bo działa on najszybciej ze wszystkich dostępnych driverów i najmniej z nim problemów. Dodatkową ciekawą opcją do rozważenia jest PhantomJS, który nie uruchamia graficznego interfejsu przeglądarki. Tylko odpala testy w konsoli. Ma on zbliżoną prędkość do ChromeDriver (jednak na korzyść chrome).

Url strony zapisałem do zmiennej. Polecam tę praktykę, żeby nie tworzyć tzw. Magicznych zmiennych. Czyli zmiennych, które są wpisane i nie wiemy czemu akurat taka wartość a nie inna. W tym przypadku akurat jest to zrozumiałe, ale gdy zaczniemy odwoływać się do elementów np. po CssSelectorze, może to już tak jasne nie być. Kolejną korzyścią z używania zmiennych jest fakt, że możemy sobie stworzyć klasę z ustawieniami i w jednym miejscu zmieniać adres url, a nie w każdym teście z osobna.

obraz55

Metodą do przejścia pod dany adres url. Jest GoToUrl („adresstrony”). Dodatkowymi ciekawymi metodami są:

Refresh – jest to odświeżenie przeglądarki

Back – pozwala wrócić do poprzedniej strony

Forward – pozwala „iść naprzód” (Czyli jeżeli cofnęliśmy się z jakiejś strony, możemy do niej wrócić)

projekt5

W kolejnym kroku używamy metody  driver.Manage().Window.Maximize(); która pozwala powiększyć okno przeglądarki do pełnej rozdzielczości.

W ostatnim kroku zajmujemy się zamknięciem drivera.

Gdy napisaliśmy test taki jak wyżej, uruchamiamy go.

projekt6

Robimy to, klikając na tę kulkę PPM -> Run.

projekt7

Gdy uruchomimy test przejdzie pozytywnie, obok kółka pojawi się zielony znaczek.

Do testów możemy i powinniśmy dodawać różnego rodzaju asercje.

Definicja:

Asercja (ang. assertion) – predykat (forma zdaniowa w danym języku, która zwraca prawdę lub fałsz), umieszczony w pewnym miejscu w kodzie. Asercja wskazuje, że programista zakłada, że predykat ów jest w danym miejscu prawdziwy.

Źródło: wikipedia

Pozwala nam np. to na:

– sprawdzenie, czy jesteśmy na pewno na tej samej stronie, czy może nie wystąpił jakiś redirect na inny adres

– czy title strony zgadza się z tym, co wiemy o tytule

– czy dany element wyświetla się na stronie

– czy dany element np. jakiś przycisk posiada określony tekst

Używanie asercji w testach jest niezbędne. Nie wyobrażam sobie bez nich testów.

selenium

selenium

Żeby użyć Asercji w testach korzystamy z klasy Assert i po kropce mamy dostęp do różnych metod. W tym przykładzie użyjemy Assert.AreEqual(obiekt1, obiekt2). Ta asercja sprawdza, czy jakieś dwa obiekty są tej samej wartości. Jeżeli tak to zwraca true, jeżeli nie to fałsz i test nie przechodzi.

77

Asercja ze screenu pozwala nam sprawdzić, czy url, który mamy wpisany w chrome driverze jest taki sam, jak podaliśmy w metodzie GoToUrl(). Uruchamiamy test, po chwili występuje błąd asercji, czyli to, co sprawdzamy okazuje się błędne. Dodatkowo kroki po asercji, która zwróciła błąd, nie są uruchamiane. W tym przypadku to driver.Close();

Dostajemy komunikat

selenium

selenium

Okazuje się, że nasz adres Url do bloga nie zawiera slasha na końcu zmiennej, a properties driver.Url zwraca ze slashem zawsze adres. Dokonujemy zmiany w naszym teście i dodajemy w zmiennej pageUrl slasha na końcu jej przed cudzysłowem kończącym zmienną.

Po zmianie slasha test zaczyna przechodzić.

projekt10

Podsumowanie

Udało nam się napisać pierwszy test w selenium.

Poznaliśmy podstawowe asercje. Następnym wpis będzie na temat szukania elementów.

Jeżeli podobał Ci się ten post.

Zachęcam do udostępniania.

MŚ.