W ka\u017cdym j\u0119zyku mo\u017cna znale\u017a\u0107 kilka popularnych framework\u00f3w testowych. Dla C# b\u0119dzie to Bumblebee, dla Python\u2019a \u2013 Behave, a dla Javy \u2013 Serenity. Jednak w przypadku JavaScript i Typescript sytuacja wygl\u0105da zdecydowanie inaczej. W spo\u0142eczno\u015bci os\u00f3b u\u017cywaj\u0105cych tych j\u0119zyk\u00f3w mo\u017cna spotka\u0107 si\u0119 z powiedzeniem, \u017ce co pi\u0119\u0107 minut powstaje nowy artyku\u0142 o jakim\u015b frameworku, zach\u0119caj\u0105cy, aby korzysta\u0107 wy\u0142\u0105cznie z niego. Wymieniaj\u0105c tylko najpopularniejsze frameworki JS\u2019owe, mo\u017cemy wskaza\u0107 kilka rzadziej ju\u017c u\u017cywanych narz\u0119dzi, tj. NightwatchJS czy Protractor, kt\u00f3re stosowane by\u0142y odpowiednio w aplikacjach opartych o React i Angular. Obecnie du\u017co cz\u0119\u015bciej stosuje si\u0119 frameworki takie jak: Cypress, Puppeteer, Playwright czy WebdriverIO. Ka\u017cdy z nich ma swoje plusy i minusy.<\/p>\n\n\n\n
Frameworki mo\u017cemy podzieli\u0107 nie tylko ze wzgl\u0119du na ich mo\u017cliwo\u015bci, ale te\u017c ze wzgl\u0119du na spos\u00f3b komunikacji z przegl\u0105dark\u0105 \u2013 poprzez Chrome Devtools Protocol (CDP) albo Selenium Webdriver. Cypress, Puppeteer oraz Playwright mog\u0105 kontrolowa\u0107 stan samej przegl\u0105darki dzi\u0119ki CDP, ale aby w pe\u0142ni wykorzysta\u0107 mo\u017cliwo\u015bci tego protoko\u0142u, nale\u017ca\u0142oby podej\u015b\u0107 do test\u00f3w w spos\u00f3b bardziej integracyjny. Podej\u015bcie integracyjne sprawdza, jak poszczeg\u00f3lne komponenty naszej aplikacji dzia\u0142aj\u0105 pojedynczo, idealnie na spreparowanych danych (mocks). Oczywi\u015bcie mo\u017cna ich u\u017cy\u0107, by stworzy\u0107 testy funkcjonalne na\u015bladuj\u0105ce u\u017cytkownika, jednak nie jest to optymalny spos\u00f3b. Natomiast WebDriverIO umo\u017cliwia korzystanie z obu sposob\u00f3w w komunikacji, zale\u017cnie od przekazanej konfiguracji, dzi\u0119ki czemu mo\u017cna wykorzysta\u0107 odpowiednie narz\u0119dzie do zrealizowania danych potrzeb.<\/p>\n\n\n\n
Za\u0142o\u017cenia dotycz\u0105ce architektury frameworku<\/h2>\n\n\n\n
Jednym z kluczowych czynnik\u00f3w stanowi\u0105cych o pomy\u015blnym zrealizowaniu oczekiwa\u0144 klienta, czyli zbudowaniu nowego frameworku do test\u00f3w automatycznych, by\u0142o zdefiniowanie jego odpowiedniej architektury. Kluczowym za\u0142o\u017ceniem frameworku by\u0142o zapewnienie optymalizacji test\u00f3w automatycznych pod k\u0105tem likwidacji zduplikowanych scenariuszy testowych. Warto nadmieni\u0107, \u017ce powy\u017csza problematyka stanowi\u0142a jedn\u0105 z g\u0142\u00f3wnych bol\u0105czek poprzedniego frameworku testowego wykorzystywanego przez klienta. Jako rozwi\u0105zanie przyj\u0119to tworzenie scenariuszy testowych, kt\u00f3re umo\u017cliwiaj\u0105 testowanie r\u00f3\u017cnych wersji j\u0119zykowych i rynkowych z poziomu jednego testu<\/strong>. Przyj\u0119te za\u0142o\u017cenie, opr\u00f3cz redukcji potencjalnie wysokiej liczby test\u00f3w, zapewnia\u0142o tak\u017ce mniejszy nak\u0142ad pracy potrzebnej do utrzymywania nowo wytworzonych test\u00f3w automatycznych.<\/p>\n\n\n\n Ze wzgl\u0119du na dodatkowe wymagania klienta dotycz\u0105ce implementacji BDD<\/strong> oraz pisania test\u00f3w automatycznych przy pomocy JavaScript, wyb\u00f3r technologii i narz\u0119dzi w projekcie ograniczy\u0142 si\u0119 do dw\u00f3ch decyzji: JavaScript vs TypeScipt oraz wyboru samego frameworku, na kt\u00f3rym framework projektowy ma bazowa\u0107.<\/p>\n\n\n\n W pierwszej kwestii, wyb\u00f3r pad\u0142 na TypeScript<\/strong>. Przy wi\u0119kszych projektach u klient\u00f3w, kt\u00f3rzy outsourcinguj\u0105 ca\u0142e zespo\u0142y, TypeScript b\u0119dzie cechowa\u0142 si\u0119 ni\u017cszym progiem wej\u015bcia, szczeg\u00f3lnie dla os\u00f3b, kt\u00f3re wcze\u015bniej pisa\u0142y kod w Javie. Przek\u0142ada si\u0119 to na kr\u00f3tszy czas onboardingu, przez co \u0142atwiej osi\u0105gn\u0105\u0107 skalowalno\u015b\u0107 zespo\u0142u oraz szybciej pokry\u0107 testami funkcjonalno\u015bci aplikacji.<\/p>\n\n\n\n W przypadku frameworku i konieczno\u015bci u\u017cycia BDD, wyb\u00f3r pad\u0142 na WebDriverIO z Selenium Webdriver<\/strong> wraz z CucumberJS<\/strong>. Pozwoli\u0142o to na bezproblemowe po\u0142\u0105czenie wszystkich wymaga\u0144 oraz zapewnienie wystarczaj\u0105cego wsparcia technologicznego od spo\u0142eczno\u015bci. U\u017cycie Selenium Webdriver, a nie Chrome Devtools Protocol, jest kolejn\u0105 cech\u0105 pozwalaj\u0105c\u0105 obni\u017cy\u0107 pr\u00f3g wej\u015bcia. Nie zmusza dewelopera test\u00f3w do u\u017cycia asynchroniczno\u015bci na ka\u017cdym kroku, co mo\u017ce by\u0107 atrakcyjne dla os\u00f3b dopiero ucz\u0105cych si\u0119 JavaScriptu lub przechodz\u0105cych z innego j\u0119zyka. Do tego dodanie takich wzorc\u00f3w projektowych jak Dependency Injection, Page Factory oraz Page Object Pattern daje stabilno\u015b\u0107 samych test\u00f3w oraz zmniejsza nak\u0142ad pracy potrzebny do ich p\u00f3\u017aniejszego utrzymania.<\/p>\n\n\n\n Maj\u0105c za sob\u0105 wyb\u00f3r j\u0119zyka, technologii i narz\u0119dzi, w nast\u0119pnym kroku nale\u017ca\u0142o zaprojektowa\u0107 integracj\u0119 frameworku z systemami klienta, a tak\u017ce jego zada\u0144, tj. egzekucji, raportowania, integracji z innymi narz\u0119dziami w procesie testowania aplikacji.<\/p>\n\n\n\n Egzekucja wielu scenariuszy testowych z pojedynczym wynikiem oraz ocenienie, czy wszystkie testy zako\u0144czy\u0142y si\u0119 sukcesem (passed) czy nie (failed), daje zbyt ma\u0142o informacji, \u017ceby mo\u017cna by\u0142o uzna\u0107 raport z egzekucji za warto\u015bciowy. Dlatego r\u00f3wnie du\u017c\u0105 wag\u0119 powinno si\u0119 przy\u0142o\u017cy\u0107 do utworzenia raportu z egzekucji test\u00f3w<\/strong> oraz sposobu jego integracji z narz\u0119dziami do zarz\u0105dzania testami<\/strong>.<\/p>\n\n\n\n Gotowych bibliotek do utworzenia raportu w postaci zestawu stron HTML, jak i narz\u0119dzi do zarz\u0105dzania testami, jest mn\u00f3stwo, co czyni niemal\u017ce niemo\u017cliwym wyb\u00f3r idealnego narz\u0119dzia, kt\u00f3re spe\u0142ni oczekiwania dowolnego projektu. Wybieraj\u0105c bibliotek\u0119 tworz\u0105c\u0105 raport, musimy wzi\u0105\u0107 pod uwag\u0119 \u0142atwo\u015b\u0107 integracji i uruchomienia przy u\u017cyciu wybranych wcze\u015bniej technologii i narz\u0119dzi.<\/p>\n\n\n\n Tutaj wyb\u00f3r jest zazwyczaj przes\u0105dzony na rzecz narz\u0119dzia ju\u017c obecnego w \u015brodowisku klienta. Oczywi\u015bcie w cz\u0119\u015bci projekt\u00f3w, czyli w nowych projektach lub z niedojrza\u0142ym procesem testowym, b\u0119dziemy mie\u0107 wp\u0142yw lub b\u0119dziemy odpowiada\u0107 za wyb\u00f3r takiego narz\u0119dzia. Jak w powy\u017cszym przypadku, wyb\u00f3r powinien by\u0107 podyktowany \u0142atwo\u015bci\u0105 integracji z wcze\u015bniej wybranymi narz\u0119dziami. Istnieje wiele gotowych rozwi\u0105za\u0144, kt\u00f3re s\u0105 w stanie przetworzy\u0107 wynik biblioteki do raportowania bezpo\u015brednio na elementy sk\u0142adowe Jira, Rally, qTest czy innego narz\u0119dzia do zarz\u0105dzania.<\/p>\n\n\n\n Kolejnym aspektem, kt\u00f3ry warto mie\u0107 na uwadze, jest spos\u00f3b komunikacji pomi\u0119dzy frameworkiem a narz\u0119dziem do zarz\u0105dzania testami. D\u0105\u017c\u0105c do pe\u0142nej automatyzacji chcemy, \u017ceby integracja wynik\u00f3w zosta\u0142a przeprowadzona automatycznie po ka\u017cdej pe\u0142nej egzekucji regresji lub w wybranym przez klienta momencie. Dlatego powinni\u015bmy zrezygnowa\u0107 z narz\u0119dzi, kt\u00f3re pozwalaj\u0105 jedynie zrobi\u0107 import z raportu poprzez UI i postawi\u0107 na komunikacj\u0119 przez API.<\/p>\n\n\n\n Nast\u0119pnym elementem przy projektowaniu ca\u0142o\u015bci architektury b\u0119dzie odpowiedni spos\u00f3b notyfikacji o egzekucji. Powiadomienia po sko\u0144czonej egzekucji test\u00f3w automatycznych, opr\u00f3cz raport\u00f3w lub link\u00f3w, powinny zawiera\u0107 tylko niezb\u0119dne informacje, np. status czy odno\u015bnik do szczeg\u00f3\u0142\u00f3w. Dodatkowo podobn\u0105 notyfikacj\u0119 mo\u017cna zastosowa\u0107 w momencie uruchomienia egzekucji, w kt\u00f3rej kluczowymi informacjami b\u0119dzie rodzaj test\u00f3w, \u015brodowisko czy testowany system. Kana\u0142y u\u017cyte do powiadomie\u0144 powinny by\u0107 to\u017csame z kana\u0142ami u\u017cywanymi przez klienta do codziennej komunikacji. Obecne rozwi\u0105zania na rynku umo\u017cliwiaj\u0105 bezproblemowe przesy\u0142anie informacji na kana\u0142ach czy w pokojach, tak jak w aplikacjach typu Teams lub Slack.<\/p>\n\n\n\n Istotnym elementem maj\u0105cym wp\u0142yw na ostateczny kszta\u0142t narz\u0119dzia do testowania, jest \u0142atwo\u015b\u0107 uruchomienia go w \u015brodowisku CI\/CD. Wsp\u00f3\u0142czesne narz\u0119dzia do test\u00f3w automatycznych posiadaj\u0105 domy\u015blnie tak\u0105 mo\u017cliwo\u015b\u0107. Tym, o czym trzeba pami\u0119ta\u0107, jest odpowiednie ustawienie i przygotowanie narz\u0119dzia i agent\u00f3w do pracy z frameworkiem. Mo\u017cna to zrobi\u0107 zar\u00f3wno poprzez stworzenie odpowiedniego obrazu dockerowego z zainstalowanymi potrzebnymi modu\u0142ami, jak r\u00f3wnie\u017c instalowanie ich dynamicznie w zale\u017cno\u015bci od potrzeb.<\/p>\n\n\n\nDecyzje specjalist\u00f3w z Sii<\/h2>\n\n\n\n
Integracja frameworku z systemami klienta<\/h2>\n\n\n\n
a) Egzekucja i raportowanie<\/h3>\n\n\n\n
b) Wyb\u00f3r narz\u0119dzia do zarz\u0105dzania testami i komunikacja z frameworkiem<\/h3>\n\n\n\n
c) Wyb\u00f3r sposobu powiadomie\u0144 po zako\u0144czonych testach<\/h3>\n\n\n\n
d) CI\/CD<\/h3>\n\n\n\n
Podsumowanie wyzwania na konkretnym przyk\u0142adzie<\/h2>\n\n\n\n
![\"Architektura](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/09\/grafika_blogersii-final.jpg\")
<\/a>