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.

 

SpecFlow + Mailosaur = Łatwiejsze testowanie maili

Testowanie maili z SpecFlow i Mailosaur

Cześć, dawno mnie tu nie było. Pisałem ostatnio kilka wpisów dla testuj.pl również będą się tam pojawiać od czasu do czasu moje wpisy, więc zachęcam was do sprawdzania serii o SpecFlow (link).

Dzisiaj zajmiemy się tematem – testowaniem treści mail. Tworząc test automatyzujący akcje, które musielibyśmy zrobić.

Jak podejść do testowania automatycznego maili, które przychodzą na skrzynkę mailową?

W czystym Selenium jest to możliwe jednak nie, jest to proste jak z narzędziem, które pokażę wam dzisiaj.  Z pomocą przychodzi nam Maliosaur. Nie użyjemy dziś Selenium więc nasz test będzie testował funkcjonalne, ale poprzez dostęp do API Mailosaura, które ma napisanego klienta dla .NET-u (Stworzony został wrapper API dla .NET-u)

Testowanie automatyczne zapomnianego hasła lub innych mail z systemu? 

Naprawdę może być prostsze.

… 

 

CodeceptJS testy akceptacyjne w przyjemny frameworku js.

CodeceptJS testy akceptacyjne w przyjemny frameworku js.

Witajcie,

Dziś chcę przedstawić przykład użycia framework’a w którym zdecydowałem się tworzyć swój projekt konkursowy. Testy do aplikacji typu mikroblog. Aplikację piszę Bartek (http://feree.net/) – również biorący udział w DajSięPoznać. Przy okazji czytania wiadomości na testerskim Slacku trafiłem na ten framework i właśnie w tym projekcie chcę go przetestować (Chyba, że z jakiegoś powodu jego możliwości będą mnie ograniczać to wówczas przejdę na Protractor’a). Aplikacja korzysta na fronendzie z Angulara, więc potrzebowałem frameworka radzącego sobie z nim lepiej niż czysty Selenium WebDriver.

Korzyści

  • Framework dostosowany jest do tzw. DSP (eng. Domain Specific Language) – czyli nasz kod testu posiada warstwę abstrakcji zrozumiałą w danym języku.  Przez to skupiamy się bardziej na scenariuszu dzięki czemu łatwiej analizuje się kod.
  • Testy piszemy jako użytkownik, każdy krok zaczynamy od „I.”-  pozwala to osobom postronnym lepiej zrozumieć scenariusz, który brzmi jak akcje, których dokonywalibyśmy na stronie a „pod spodem” danego kroku  „I.sth” znajduje się zaimplementowana akcja.
  • BDD – kładziemy nacisk na to jak ma się zachowywać system.

Wady

  • Jest to dość nowy framework więc mogą pojawić się czasami sytuacje nie wspierania danej funkcji.

Jak zacząć?

CodeceptJS posiada przyjemny konfigurator, który pozwala szybko stworzyć szkielet projektu. Zaczynamy od wejścia na stronę framework http://codecept.io/ . Polecam zapoznać się z jasno przedstawioną dokumentacją.

Do instalacji codeceptJS potrzebować będziemy node.js.

Po  instalacji node.js przechodzimy do terminala.

[sudo] npm install -g codeceptjs

instaluje globalnie codeceptJS

lub lokalnie

npm install –save-dev codeceptjs

Następnie po instalacji pakietu npm przechodzimy do terminala

codecepjs init  

Ta komenda utworzy nam szkielet projektu w ścieżce w której znajdujemy się aktualnie w terminalu. Aby dowiedzieć gdzie się aktualnie znajdujemy używamy polecenia pwd (w mac’u, powershell’u).

codeceptjs pyta się o folder w którym będziemy przechowywać nasze testy.

Następnie wybieramy  to jakiego helpera będziemy używać :

Ja wybieram Protractora

Wybieramy ścieżkę gdzie będziemy przechowywać output (logi, screenshoty)

Czy chcemy by utworzył folder ze stepami

Wybieram język angielski

Po skończonej konfiguracji również z terminala możemy dodać pierwszy test.

codeceptjs gt

Po wygenerowaniu testu możemy przejść do pisania kodu.CodeceptJS testy

Do pisania kodu w CodeceptJS wykorzystywał będę webStorm’a lub Visual Studio Code.

Przechodzimy w VSC – > Open -> folder exampleCodeceptJS

CodeceptJS testy

Do konfiguracji dodajemy helper Protractora. W czasie gdy czekałem na aplikacje do testów, którą tworzył Bartek, doszedłem do wniosku, że mogę zacząć pisać testy już do przykładowej strony aby zaznajomić się z frameworkiem. Jako przykład posłużył mi todomvc example, który posiada angulara na frontendzie. Url:

http://todomvc.com/examples/angularjs/

Polecam próbę na tej stronie.

Przechodzę do first_test.js

CodeceptJS testy

Metoda amOnPage(‚/’); przenosi do wybranej strony. CodeceptJS wie gdzie ma się udać, ponieważ url docelowy wzięty jest z pliku codecept.json

Przechodzimy do próby uruchomienia testów w terminalu, w folderze gdzie tworzyliśmy codeceptjs init:

codeceptjs run 

CodeceptJS testy

Naszym oczom ukazuje się błąd. I dobrze ;- ). Nasz WebDriver nie jest jeszcze uruchomiony. Aby to zrobić (musimy mieć go zainstalowanego) wpisujemy

webdriver-manager update

webdriver-manager start

update – po to by nasz server WebDriver’a był aktualny.

start – uruchamia server WebDriver’a.

Wracamy do polecenia :

codeceptjs run CodeceptJS testy

Nasze test uruchamia się. ; -)

Podsumowanie

Dziś dowiedzieliśmy się jak zainstalować codeceptJS, jak rozpocząć tworzenie testów tym frameworku. W kolejnych częściach będziemy pisać kolejne testy.

 

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.

 

Klikanie w Selenium WebDriver + C# oraz inne interakcje część 3

Podczas testowania aplikacji internetowych symulujemy zachowanie użytkownika. Do podstawowych interakcji ze stroną www można zaliczyć:

  • Klikanie w elementy takie jak przyciski, linki, check-boxy;
  • Wypełnianie elementów treścią jak inputs, drop-downs;
  • Przewijanie strony

W dzisiejszym wpisie postaram się zautomatyzować niektóre z wymienionych interakcji przy pomocy Selenium.

Czego potrzebujemy? 

Po czym możemy klikać?

W Selenium każdy obiekt IWebElement  posiada metodę Click(), która symuluje kliknięcie elementu.

Zdarza się, że podstawowe metody nie wystarczają. Innym sposobem jest klikanie za pomocą akcji. W Selenium akcje pozwalają m.in.:

  • Klikać – prawy/lewy klawisz, podwójne kliknięcia;

Wpisywać tekst, w tym znaki sterujące takie jak TAB, ESCAPE, ENTER

  • Przewijać do danego elementu
  • DragAndDrop – MouseDown + MouseMove + MouseUp

Plus inne…

Może się zdarzyć, że akcje również są niewystarczające do prawidłowego zasymulowania akcji użytkowania. W ostateczności można do źródła strony wstrzyknąć kod JavaScript.

var elem = driver.FindElement(By.ClassName(„something”));

((IJavaScriptExecutor)driver).ExecuteScript(„arguments[0].scrollIntoView(true);”, elem);

Powyższa metoda wykracza jednak poza ramy niniejszego posta. Zachęcam jednak do samodzielnego zgłębienia tematu.

Czego nauczysz się z tego wpisu?

  • Jak kliknąć w tytuł pierwszego posta?
  • Jak kliknąć w przycisk?
  • Jak klikać za pomocą Actions?
  • Jak wpisać tekst w element na stronie za pomocą Selenium?
  • Jak przewijać stronę do określonego elementu?

Celem testu będzie:

  • Kliknięcie w pierwszy element.
  • Powrócenie do głównego ekranu.
  • Kliknięcie w drugi wpis
  • Scrollowanie do sekcji „Comment”
  • Wypełnienie pola tekstem (mail, name, treść posta, website).

Żeby to zrobić musimy stworzyć obiekt drivera wraz z wejściem na stronę www.
var driver=new ChromeDriver();

var pageUrl = „https://studytestingblog.wordpress.com/”;

driver.Navigate().GoToUrl(pageUrl);

driver.Manage().Window.Maximize();

Assert.AreEqual(driver.Url, pageUrl);

 

Tworzymy obiekt zawierający kolekcje wszystkich tytułów postów

var listOfTitles = driver.FindElements(By.CssSelector(„.entry-title a”));

listOfTitles[0].Click();

driver.Navigate().Back();

Gdy uruchomimy test, WebDriver kliknie w tytuł pierwszego postu.

Za pomocą driver.Navigate().Back();

Wracamy do poprzedniej strony.

Drugi tytuł klikniemy z wykorzystaniem akcji w Selenium. Akcji możemy użyć na dwa sposoby:

  1. new Actions(driver).Click(listOfTitles[1]).Perform();

testingplus.me

Tworzymy nową akcję. Jako parametr w metodzie Click() podajemy IWebElement. Istnieje szansa, iż wykonanie kodu w powyższej postaci wyrzuci StaleElementReferenceException. W dokumentacji Selenium odnośnie wyjątku stale_element_reference możemy znaleźć dwa powszechne powody jego wystąpienia:

  • Element został całkowicie usunięty (dynamiczne strony www, single page applications)
  • Element nie jest już powiązany z drzewem DOM

W naszym przypadku ma miejsca druga sytuacja. Wyjątek ten spowodowany jest przeładowaniem strony (kliknięcie pierwszego posta i powrót). Selenium straciło referencję do obiektu.

Rozwiązaniem problemu może być ponowne wyszukanie elementu:

new Actions(driver).Click(driver.FindElementsByCssSelector(„.entry-title a”)[1]).Perform();

Gdy używamy Actions, to musimy pamiętać, aby na końcu każdej komendy dopisać Perform(). Jest to metoda, która odpowiada za wykonanie „akcji” i jest niejako wyzwalaczem. Actions zgodnie z nazwą, może posiadać kilka różnych, powiązanych ze sobą operacji. Wykonanie powyższego kodu powoduje klikniecie w „Drugi post”.

Kolejnym krokiem jest przewijanie strony do zadanego elementu. W poniższym przykładzie będziemy scrollować do sekcji „Comment”. Stworzymy do tego celu obiekt typu Actions.

 

Actions actions = new Actions(driver);

// Tworzę zmienną, która będzie odzwierciedleniem elementu „comment” na stronie

var comment = driver.FindElementById(„comment”);

// Przewinięcie strony do zadanego elementu

actions.MoveToElement(comment).Perform();

// Przypisanie wartości atrybutu elementu do zmiennej

var text = comment.GetAttribute(„placeholder”);

// Weryfikacja poprawności

Assert.AreEqual(text, „Enter your comment here…”);

Poniższy kod dodaje wpis na stronie i zamyka przeglądarkę.

comment.SendKeys(„ciekawy wpis”);

var mail = driver.FindElementById(„email”);

mail.SendKeys(„example@example.com”);

var author = driver.FindElementById(„author”);

author.SendKeys(„Michal”);

var websiteUrl = driver.FindElementById(„url”);

websiteUrl.SendKeys(„www.testingplus.me”);

var submitComment = driver.FindElementById(„comment-submit”);

submitComment.Click();

driver.Close();

Podsumowanie

Dziś nauczyliśmy się m.in. jak scrollować, wpisywać tekst do elementu oraz jak klikać. Pozwala to nam na pisanie coraz bardziej zaawansowanych testów. W następnej części chcę pokazać Wam podstawowe sposoby czekania w Selenium WebDriver.

Serdeczne podziękowania dla Przemka Secha, który pomaga mi merytorycznie korygować wpisy.  Jeszcze raz dzięki !

 

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.

 

Testowanie automatyczne. Znajdowanie elementów na stronie – Selenium WebDriver + C# część 2

Znajdowanie elementów na stronie – Testowanie automatyczne w  Selenium webDriver część 2

W dzisiejszym wpisie chcę Wam pokazać, w jaki sposób możemy znajdować elementy umieszczone na stronie, którą testujemy  w Selenium WebDriver. W tym celu utworzyłem testowego stronę na platformie blogowej na ghost.org. Polecam również stworzyć sobie stronę z ghostem do nauki Selenium.

Czym jest element?

Elementami jest wszystko to, co widzimy na stronie. Wszystko, co ma swoje odzwierciedlenie w html’u.

Dzięki znajdowaniu elementów możemy wykonywać określone akcje z nimi związane np.:

  • odczytywać tekst, jeżeli go posiadają
  • sprawdzić, czy są na stronie
  • sprawdzić, jaką mamy ilość danego elementu
  • stworzyć obiekt IWebElement, który będzie odzwierciedleniem w kodzie elementu, który znaleźliśmy na stronie (dzięki lokatorowi)
  • klikać w nie, w różny sposób
  • wpisywać wartość tekstową w znalezionym element
  • czekać aż element się pojawi

Jakie są możliwości znajdowania elementów na stronie poprzez Selenium?

W standardowym Selenium WebDriver mamy możliwość odwoływania się po tzw. lokatorach.

Lokatorem mogą być:

  • XPath
  • CssSelector
  • ClassName
  • Name
  • Id
  • LinkText
  • PartialLinkText
  • TagName

 

Polecam, jeżeli jest to możliwe odwoływać się na stronie po Id lub Name. Są one najszybciej znajdowane na stronie, jeżeli występują.

W innych przypadkach możemy użyć:

  • ClassName,
  • XPatha,
  • CssSelectora,
  • Nadać elementowi id’ka lub name,
  • LinkText
  • PartialLinkText
  • TagName

Jeżeli, jest to możliwe polecam w tym przypadku nadać id bądź name. Jednak, jeśli z jakichś powodów jest to niemożliwe, rekomenduje odwoływać się po  CssSelectorze. Jest bardziej podatny na zmianę niż id czy name. Jednak używając wzorca projektowego Page Object Model taka zmiana, zajmuję chwilę (W przyszłości napiszę post o nim).

Polecam wypowiedzi:

JimEvans’a (odpowiedzialnego za rozwój WebDrivera dla C#)

http://stackoverflow.com/questions/11777694/which-is-the-best-and-fastest-way-to-find-the-element-using-webdriver-by-xpath

http://stackoverflow.com/questions/13975595/why-one-should-prefer-using-css-over-xpath-in-ie

Czego potrzebujemy?

  • Visual Studio
  • R#
  • ChromeWebDriver
  • SeleniumWebDriver
  • Własna strona z zainstalowanym ghostem + post powitalny

Tworzymy w naszym projekcie nową klasę o nazwie FindElementsOnPage.cs

Dodajemy metodę testową z wejściem na stronę. Inicjalizujemy ChromeDrivera.

Dodajemy zmienną wraz z adresem url. W jaki sposób szukać elementów? Poniżej przedstawiam kilka dodatków, które pomagają nam w szukaniu.

Polecam cztery ciekawe dodatki, które pomagają nam znajdować XPatha oraz CSS Selectory elementów.

WebDriverLocator

Odkryty nie dawno przeze mnie dodatek do Firefoxa. Dodajemy poprzez wyszukanie WebDriver Element Locator w dodatkach Firefoxa.

Klikamy PPM na wybraną stronę w Firefoxie. W menu kontekstowym mamy dostęp do lokatorów Xpath dostosowanych do C#.

locator locator1

Dla szybkiego znalezienia XPath’a jest to pomocny dodatek.

FirePath + FireBug

https://addons.mozilla.org/en-US/firefox/addon/firepath/

Jeden z najbardziej popularnych dodatków służących do znajdowania XPatha oraz CSS Selectora na stronie. FirePath jest bardzo przyjemnym dodatkiem. Pozwala znajdować css selectory oraz XPathy szybko, ja osobiście go bardzo polecam.

FireFinder +FireBug

Dodatek, który widziałem na jednej prezentacji odnośnie Selenium WebDriver. Pozwala sprawnie radzić sobie z XPathem.

Kurs znajdowania CSS Selectorów

http://flukeout.github.io/ Prosty i przyjemny kurs podstaw znajdowania CSS Selectorów.

Chrome Developer Tools

Za pomocą Chrome Developer Tools (Klikamy F12 lub  PPM – >”zbadaj element”) możemy odczytać każdy lokator elementu na stronie www, jeżeli on istnieje. Polecam samemu nauczyć się podstawowego znajdowania. Wymieniony wyżej kurs pomaga w tym. Dlatego, że nasze css selectory czy xpathy mogą być, krótsze, bardziej odporne na zmianę interfejsu strony www niż zrobione przez automat np. Chrome’a.

find8

IWebElement

Jest to interfejs, który definiuje wszystkie metody oraz właściwości, które ma każdy obiekt WebElement.

https://seleniumhq.github.io/selenium/docs/api/dotnet/html/T_OpenQA_Selenium_IWebElement.htm

Polecam artykuł na temat interfejsu, jeżeli ktoś nie miał styczności.

http://4programmers.net/C_sharp/Interfejsy

Każdy obiekt typu WebElement obsługuje interfejs IWebElement.

find1

Gdy skopiujemy lokator danego elementu, tworzymy w kodzie obiekt typu WebElement z takim samym rodzajem lokatora, jakiego pobraliśmy wartość. Przy pomocy metod dostępnych w klasie By (klasa ta posiada dla każdego lokatora osobną metodę).

Dlaczego w przykładach mam var zamiast WebElement lub IWebElement?

Często stosuje „var”. Tym bardziej dla wartości, dla których bez zastanowienia znam wartość. Czym jest „var” wyjaśnione jest sensownie na stackOverflow:

http://stackoverflow.com/questions/4307467/what-does-var-mean-in-c

find2

Lub metody, które znajdują się poza „By”

driver.FindElementById(„id”);

driver.FindElementsByName(„name”);

Na stronie wyszukajmy:

  • Tytuł strony

find3

Klasa „page-title” w tym przypadku odpowiada za tytuł strony. Chrome podświetla nam w konsoli element na, którym kliknęliśmy „Zbadaj element” lub mając odpalone Chrome Developer Tools, najechaliśmy na ten element.

  • Opis strony

var pageDescription = driver.FindElement(By.ClassName(„page-description”));

  • Liczbę postów

Tutaj przedstawię dwa pomysły na pobranie wszystkich postów:

var listOfPostsValue = driver.FindElementById(„content”).FindElements(By.ClassName(„post-excerpt”));

Assert.AreEqual(listOfPostsValue.Count, amountOfPosts);

Dzięki temu, że w Selenium możemy szukać elementu w elemencie, zmienna listOfPostValue zwraca kolekcję WebElementów, które mają id=”content” oraz ClassName =”post-excerpt”.  Dzięki FindElements możemy znaleźć je wszystkie i zapisać do kolekcji. Po zapisie do zmiennej możliwe jest odwołanie się do dowolnego posta.

var textFromFirstPost = listOfPostsValue[0].Text;

Assert.AreEqual(textFromFirstPost, „You’re live! Nice. We’ve put together a little post to introduce you to the Ghost editor and get you started. You can manage your content by »”);

Asercja sprawdza, czy posty posiadają tę samą treść.

Lub

var listOfPosts = driver.FindElementByClassName(„post-excerpt”).FindElements(By.TagName(„p”));

Każdy post zawiera TagName

(paragraph), w którym jest skrócona treść posta.

  • Kolekcję wszystkich tytułów postów

var allOfPostTitles= driver.FindElements(By.ClassName(„post-title”));

Assert.AreEqual(allOfPostTitles.Count,amountOfPosts);

  • Przycisk menu

Najbardziej charakterystycznym elementem, który wyróżniania przycisk menu to klasa „word”

var menuButton = driver.FindElement(By.ClassName(„word”));

Assert.AreEqual(menuButton.Text, „MENU”);

Asercja pozwala sprawdzić, czy teksty są takie same. Na wyniki wyszukiwania ma wpływ wielkość liter, więc jeżeli byśmy napisali „Menu” to test, by nie przeszedł.

  • Link do autora

Żeby uzyskać link do autora bloga (w tym przypadku testowyblog). Możemy odwołać się do LinkTextu

var linkToGhostOwner = driver.FindElementByLinkText(„testowyblog”);

Assert.AreEqual(linkToGhostOwner.Text,”testowyblog”);

Po poznaniu podstawowych opcji wyszukiwania elementów na stronie uruchamiamy test.

find4

Teraz sprawdzimy, co się stanie z testami, jeżeli dodam drugi post na platformie blogowej Ghost.

find5

Pojawia nam się błąd związany z datą. Sprawdzamy ClassName „post-date”, Selenium wskazuje nam tego posta, który jest najnowszy. Dlatego, że Selenium bierze pierwsze wystąpienie ClassName „post-date” po dodaniu posta. Najnowszy post ma to pierwsze wystąpienie. Jeżeli chcemy w teście sprawdzić datę pierwszego posta w kontekście dodania, to możemy zrobić sobie kolekcje post-data i wziąć ostatni element (post):

Np. tak

var postDates = driver.FindElements(By.ClassName(„post-date”));

Assert.AreEqual(postDates.Last().Text, „24 JULY 2016”);

Po tej zmianie w asercji test w tym miejscu. Uruchamiamy znowu. NUnit zwraca nam błąd:

find6

Wynika to z tego, że liczymy ile mamy postów (2), a w kodzie mamy zdefiniowane, że mamy jeden post. Należy zmienną amountOfPosts zmienić na 2.

Kolejna rzecz, którą należy poprawić:

find7

Post, który dodałem do strony, jest (patrząć od góry strony wyświetlany jako pierwszy). Jego długość wyności 25 znaków, nie 142 jak wcześniejszy post czyli post drugi ( Pierwszy w kontekście daty powstania ). Jeżeli chcemy sprawdzać ostatni post, to również korzystamy z Last().

var listOfPostsValue =driver.FindElementById(„content”).FindElements(By.ClassName(„post-excerpt”));

var textFromFirstPost = listOfPostsValue.Last().Text;

Assert.AreEqual(textFromFirstPost, „You’re live! Nice. We’ve put together a little post to introduce you to the Ghost editor and get you started. You can manage your content by »”);

Jeżeli postanowilibyśmy w naszym scenariuszu, że chcemy zawsze wybierać pierwszy post (najstarszy), polecam wtedy się zastanowić:

  • Czy w jednym scenariuszu testowym dodajemy i usuwamy post?
  • Uruchamianie scenariuszy testowych jeden po drugim, w jednym scenariuszu dodajemy post, w drugim scenariuszu usuwamy wcześniej dodany post. Musimy pamiętać w tym wypadku o kolejności uruchamiania (możemy pogrupować).

Może sami macie jakiś inny ciekaw pomysł? Z chęcią go poznam. Podzielicie się koniecznie w komentarzu.

Podsumowanie

Poznaliśmy znajdowanie elementów za pomocą różnych lokatorów w Selenium WebDriver oraz C#. W kolejnym wpisie na temat selenium poruszę temat klikania w  elementy na stronie.

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