W poprzednim artykule na temat testów automatycznych wspomnieliśmy, że narzędzia stosowane przez nas w projektach (Selenium + Cucumber) świetnie sprawdzają się jeśli chodzi o aplikacje stworzone na platformie Pega.
W tym artykule chcielibyśmy rozwinąć ten temat prezentując w skrócie, jak wygląda proces powstawania takiego framework-a dla Pegi.
Wymagania
Aby pracować nad testami automatycznymi, potrzebujemy maszyny, która będzie miała dostęp do internetu oraz – co oczywiste – dostęp do systemu Pega, który będziemy testować. Na maszynie tej instalujemy niezbędne narzędzia. W skład tych narzędzi wchodzą:
- Przeglądarki internetowe, na których będziemy uruchamiać naszą aplikację Pegową przy pomocy testów automatycznych.
- IntelliJ IDEA Community Edition – środowisko programistyczne (IDE). W nim będziemy tworzyć nasze testy automatyczne,
- Apache Maven – to narzędzie do zarządzania projektem oprogramowania. Jest to trzon naszego projektu. Zarządza on bibliotekami oraz wtyczkami używanymi w kodzie testów automatycznych,
- Jenkins – open source-owe oprogramowanie CI/CD, które wykorzystujemy do uruchamiania testów automatycznych. Testy te można uruchamiać ręcznie z poziomu Jenkins-a, jak również automatycznie poprzez Pega Deployment Manager – w tej sytuacji, w pipeline umieszczamy tzw. zadanie Jenkins, które odwołuje się do naszej instalacji i uruchamia dla nas testy automatyczne.
Scenariusze testowe
Proces przygotowywania testów automatycznych zaprezentujemy na przykładzie aplikacji stworzonej w Pega 8.7.0. Jest to prosta aplikacja służąca do zarządzania fikcyjnym polem golfowym. Case, jaki będziemy testować służy do zarejestrowania w systemie nowego członkostwa. Jego przebieg zaprezentowany jest poniżej.
Poszczególne kroki tego procesu, to:
- Choose member – ekran zawierający pole typu autocomplete, w którym wybieramy osobę, dla której rejestrujemy członkostwo. Na potrzeby tego scenariusza testowego wybierzemy jednego z istniejących członków klubu golfowego.
- Choose membership – w tym kroku użytkownik wybiera jeden z planów członkostwa za pomocą jednego z przycisków “Choose”.
- Ostatni krok to podsumowanie. Tutaj użytkownik klika jedynie “Submit”.
Celem naszego testu jest utworzenie nowego case-a, przejście pomyślnie przez opisane powyżej kroki tak, aby case ten ostatecznie miał status “Resolved-Completed. W tym celu, w naszym projekcie tworzymy nowy plik z rozszerzeniem *.feature, w którym piszemy scenariusz testowy w języku Gherkin. Scenariusz ten może wyglądać następująco:
Scenario: New Membership Happy path
Given User has access to "Golf Club" application
When User creates new case of type "New Membership"
Then User will be presented with "Choose member" screen
When user selects "Łukasz Sokolnicki" in Choose Member autocomplete field
And User clicks Submit button
Then User will be presented with "Choose membership" screen
When User selects "Ultimate" membership plan
And User clicks Submit button
Then User will be presented with "Summary" screen
When User clicks Submit button
Then case will be finished with "Resolved-Completed" status
Na początku, przy pomocy klauzuli “Given” sprawdzamy warunki wstępne, a więc czy użytkownik ma dostęp do systemu Pega oraz czy może się zalogować do aplikacji o nazwie “Golf Club”. Zdanie zaczynające się od “Given” jest zawsze na początku scenariusza testowego i za jego pomocą sprawdzamy, czy spełnione są wszystkie warunki wstępne dla naszego testu.
Następnie używając konstrukcji zdań wykorzystujący słowa “When … Then …” wykonujemy poszczególne kroki procesu, a przy tym testujemy poprawność ich wykonania. Zdaniem zaczynającym się od “When” opisujemy działanie, jakie zostanie podjęte, natomiast “Then”, to zdanie opisujące spodziewany rezultat tego działania, czyli tzw. asercja.
W powyższym przykładzie można zauważyć, że część jest użyta wielokrotnie, np. “Then User will be presented with “(…)” screen”. Jest to celowe i pożądane działanie ponieważ zapewnia re-używalność kodu i minimalizację nakładów pracy programisty, co postaramy się wyjaśnić poniżej.
Programowanie testów automatycznych
Mając gotowy przynajmniej jeden scenariusz testowy, do pracy może przystąpić programista, który z pomocą Selenium oprogramuje testy automatyczne zgodnie ze scenariuszami testowymi. Selenium to “framework”, który dostępny jest w wielu językach programowania. My w Clocklike Minds używamy wersji dla języka Java.
W dużym skrócie praca programisty polega na tym, aby z jednej strony “przetłumaczyć” scenariusze testowe napisane w języku Gherkin, który jest mocno “biznesowy” na język programistyczny, który da się skompilować do kodu wykonalnego. Z drugiej strony ten kod musi wykonywać za nas działania w naszej aplikacji webowej przy pomocy przeglądarki internetowej (tak aby w jak najlepszym stopniu odwzorowywać rzeczywistego użytkownika).
Powiązanie języka Gherkin z Java
Na podstawie scenariusza testowego programista tworzy kod testów automatycznych. W naszym przykładzie (tak jak to robimy w rzeczywistych projektach) wykorzystamy język Java. Generalnie kod wykonywany podczas testów “opakowany” jest w metody, które nie zwracają żadnych danych, a metody te powiązane są ze scenariuszem testowym za pomocą odpowiedniej adnotacji. Każda linijka scenariusza testowego, która rozpoczyna się od słowa kluczowego Given, When, And lub Then ma odpowiadającą jej metodę w kodzie Java. Dla przykładu mamy w naszym scenariuszu krok, którym musimy wybrać członka klubu golfowego z listy rozwijanej typu “Autocomplete”:
When user selects "Łukasz Sokolnicki" in Choose Member autocomplete field
Odpowiadająca jej metoda w kodzie Java będzie wyglądała następująco:
@When("user selects \"Łukasz Sokolnicki\" in Choose Member autocomplete field")
public void user_selectes_member_in_choose_member_autocomplete_field() {
// body of the method goes here.
}
Adnotacja rozpoczyna się od symbolu “@” oraz słowa kluczowego odpowiadającego pierwszemu słowu ze scenariusza testowego. Potem – w nawiasie – umieszczany jest fragment tekstu scenariusza. Dzięki temu identyfikowana jest metoda, która ma być uruchomiona dla tej konkretnej frazy scenariusza testowego podczas jego uruchamiania. Innymi słowy za każdym razem, gdy w scenariuszu testowym pojawi się zdanie “When user selects “Łukasz Sokolnicki” in Choose Member autocomplete field”, wtedy uruchomiona zostanie metoda user_selectes_member_in_choose_member_autocomplete_field().
Dlatego warto budować kolejne scenariusze testowe z wykorzystaniem tych samych fragmentów. W ten sposób minimalizujemy zasoby programistyczne potrzebne do stworzenia testów automatycznych i promujemy re-używalność stworzonego wcześniej kodu. Nie jest to jednak jedyna możliwość aby tego dokonać. Możemy na przykład przekazywać parametry wprost ze scenariusza testowego (Gherkin) do metody Java. Takim parametrem w powyższym przykładzie może być imię i nazwisko członka klubu golfowego:
@When("user selects {string} in Choose Member autocomplete field")
public void user_selectes_member_in_choose_member_autocomplete_field(String string) {
// body of the method goes here.
}
W ten sposób zyskujemy znacząco na re-używalności powyższej metody, ponieważ możemy tworzyć kolejne scenariusze dla różnych danych członka klubu. Parametry te mogą mieć różne typy, np.: {int}, {float}, {byte}. Możemy również tworzyć własne typy, w których programista umieszcza listę dozwolonych wartości dla parametru – to rozwiązanie ułatwia pracę analitykowi biznesowemu, który tworzy scenariusze testowe.
Dodatkowo język Gherkin umożliwia stosowanie:
- słów opcjonalnych – takie słowo brane jest w nawias. Bez względu na to czy to słowo występuje, czy nie – metoda zostanie zidentyfikowana.
- słów alternatywnych – słowa oddzielone ukośnikiem. Wystarczy, aby jedno słowo występowało w scenariuszu testowym, a metoda zostanie zidentyfikowana.
Dzięki powyższym rozwiązaniom programista może stworzyć taki kod testów automatycznych, który będzie potem szeroko re-używany w wielu scenariuszach testowych przez Analityka Biznesowego.
Działania w przeglądarce internetowej
Selenium, to framework przy pomocy którego jesteśmy w stanie programowo wykonywać operacje w naszej aplikacji internetowej. W dużym skrócie sprowadza się to do dwóch czynności:
- Zlokalizuj element (np. pole tekstowe bądź przycisk) na stronie,
- Wykonaj na tym elemencie działanie (np. kliknij lub wprowadź wartość).
Do lokalizacji elementu na stronie możemy używać zarówno atrybutów html związanych z tym elementem jak i atrybutów css. Najlepszym oczywiście atrybutem jest ID ale nie każdy element na stronie go posiada. Jeżeli takowego nie ma, to możemy posłużyć się tzw. xpath, czyli wyrażeniem zbudowanym w oparciu o więcej niż jeden atrybut. Xpath daje możliwość sprawdzania również wartości danego elementu html, a także trawersowania, czyli odnoszenia się do elementu nadrzędnego bądź podrzędnego. W kontekście Pegi xpath jest szczególnie przydatny, ale o tym za chwilę.
Poniżej przedstawiona jest metoda, której zadaniem zalogowanie się do naszej aplikacji. Na standardowej stronie logowania Pegi znajdują się 3 elementy, które nas interesują. Jest to pole tekstowe na wprowadzenie użytkownika, pole tekstowe na hasło oraz przycisk “Log in”. Na nasze szczęście wszystkie te elementy mają ID.
Kod Java tej metody wygląda następująco:
@Given("User has access to {string} application")
public void user_has_access_to_application(String appName) {
getDriver().get(getAppURL(appName));
getDriver().findElement(By.id("txtUserID")).sendKeys("user@golf");
getDriver().findElement(By.id("txtPassword")).sendKeys("rules123");
getDriver().findElement(By.id("sub")).click();
}
Klasa Driver posiada metodę findElement, która pozwala nam odszukać element w kodzie Html na podstawie wybranego kryterium. W naszym przypadku jest to ID, dlatego kod wygląda następująco:
getDriver().findElement(By.id(…)).
Ponieważ metoda findElement zwraca obiekt klasy WebElement, to możemy od razu wykonać na nim żądaną operację, np: …sendKeys(”…”), czyli wprowadź tekst, używane dla pól tekstowych użytkownika i hasła, bądź .click() dla przycisku.
Jeżeli dany element na stronie nie posiada ID, to musimy go zidentyfikować za mocą innego kryterium, najczęściej jest to xpath. Taką identyfikację znakomicie ułatwia nam Pega udostępniając pole TestID. Jest to identyfikator generowany automatycznie przez system dla każdego elementu UI. W razie potrzeby taki identyfikator można ręcznie zmodyfikować. Poniżej pokazane jest pole, o które chodzi.
Wartość tego pola jest potem widoczna w kodzie html jako atrybut o nazwie data-test-id. Należy jednak pamiętać, że domyślnie atrybut ten jest niewidoczny. Podyktowane jest to względami wydajnościowymi. Aby ten atrybut był dostępny musimy dodać rolę o nazwie PegaRULES:TestID do access groupy naszego użytkownika testowego.
Wykorzystanie TestID w kodzie testu automatycznego wygląda następująco:
@When("user selects {string} in Choose Member autocomplete field")
public void user_selectes_member_in_choose_member_autocomplete_field(String string) {
getDriver().findElement(By.xpath("//input[@data-test-id='202207190751480441637']")).sendKeys("Łukasz Sokolnicki");
}
Wykorzystanie TestID udostępnionego przez Pegę znacząco ułatwia tworzenie testów automatycznych, ponieważ pozwala w łatwy sposób zidentyfikować elementy na stronie www. Korzystamy z niego zawsze, gdy mamy ku temu okazję. Daje nam to również pewność, że raz przypisany identyfikator TestID do elementu nigdy się nie zmieni, np. w wyniku upgrade-u wersji Pegi.
Dalsze programowanie testów automatycznych przebiega analogicznie do przedstawionych powyżej kroków, a więc:
- Tworzymy metodę,
- Przypisujemy do tej metody adnotację, która połączy ją z odpowiadającym jej fragmentem scenariusza testowego,
- Tworzymy ciało metody z wykorzystaniem Selenium, który daje nam dostęp do zawartości strony www z poziomu kodu java.
Jeśli uruchomimy w stworzony w ten sposób kod, to będziemy mogli zaobserwować, jak wszystkie operacje są wykonywane przez nasz program automatycznie. Wynikiem tych operacji powinien być utworzony case, w którym wszystkie kroki zostaną przeprocesowane i ostatecznie case ten osiągnie status Resolved-Completed.
Podsumowanie
Wykorzystanie zewnętrznych narzędzi, którymi są Cucumber oraz Selenium daje nam możliwość budowy potężnego framework-a do testów automatycznych, który przetestuje dla nas każdy “skrawek” aplikacji pegowej z perspektywy użytkownika. Dzięki niemu możemy testować nie tylko case-y tworzone ręcznie, ale również takie, które inicjalizowane są z zewnątrz przy pomocy na przykład serwisu REST bądź file listenera. Możemy również w pełni sprawdzić portal użytkownika i każdą jego funkcję.
