{"id":31228,"date":"2023-05-02T06:52:36","date_gmt":"2023-05-02T04:52:36","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/narzedzia-automatyzacji-testow\/"},"modified":"2024-11-07T13:02:13","modified_gmt":"2024-11-07T12:02:13","slug":"narzedzia-automatyzacji-testow","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/narzedzia-automatyzacji-testow\/","title":{"rendered":"Narz\u0119dzia automatyzacji test\u00f3w czy dobre praktyki? Jak przyspieszy\u0107 testowanie?"},"content":{"rendered":"\n<div class=\"table-of-contents\">\n    <p class=\"title\">PRZEJD\u0179 DO: <\/p>\n    <ol>\n                    <li><a href=\"#Czy-mo\u017cna-testowa\u0107-aplikacje-szybciej?\">1.  Czy mo\u017cna testowa\u0107 aplikacje szybciej?<\/a><\/li>\n                    <li><a href=\"#test\u00f3w\">2.  R\u00f3wnoleg\u0142e uruchamianie test\u00f3w<\/a><\/li>\n                    <li><a href=\"#Tworzenie-warunk\u00f3w-wst\u0119pnych,-wykorzystuj\u0105c-interfejsy-API-lub-dzia\u0142anie-bezpo\u015brednio-w-bazie-danych\">3.  Tworzenie warunk\u00f3w wst\u0119pnych<\/a><\/li>\n                    <li><a href=\"#poziom\u00f3w\">4.  Konwersja test\u00f3w na testy ni\u017cszych poziom\u00f3w<\/a><\/li>\n                    <li><a href=\"#niejsze-pakiety-oraz-grupowanie\">5.  Rozbicie test\u00f3w<\/a><\/li>\n                    <li><a href=\"#Redukcja-liczby-podobnych-test\u00f3w\">6.  Redukcja liczby podobnych test\u00f3w<\/a><\/li>\n                    <li><a href=\"#Zmiana-struktury-test\u00f3w-\u2013-dopasowanie-testu-do-testowanej-funkcjonalno\u015bci\">7.  Zmiana struktury test\u00f3w<\/a><\/li>\n                    <li><a href=\"#wait\u00f3w\">8.  Odpowiednie wykorzystanie wait\u00f3w<\/a><\/li>\n                    <li><a href=\"#danych-do-test\u00f3w\">9.  Dedykowana baza danych do test\u00f3w<\/a><\/li>\n                    <li><a href=\"#headless\">10.  Wykorzystanie trybu headless<\/a><\/li>\n                    <li><a href=\"#wykonywania-test\u00f3w\">11.  Odpowiedni sprz\u0119t do test\u00f3w<\/a><\/li>\n                    <li><a href=\"#Podsumowanie\">12.  Podsumowanie<\/a><\/li>\n            <\/ol>\n<\/div>\n\n\n<h2 class=\"wp-block-heading\" id=\"Czy-mo\u017cna-testowa\u0107-aplikacje-szybciej?\">Czy mo\u017cna testowa\u0107 aplikacje szybciej?<\/h2>\n\n\n\n<p>Dynamicznie rozwijaj\u0105ca si\u0119 technologia i rosn\u0105ce wymagania u\u017cytkownik\u00f3w sprawiaj\u0105, \u017ce projektowanie wydajnych i niezawodnych aplikacji internetowych staje si\u0119 coraz bardziej z\u0142o\u017cone, a zapewnienie prawid\u0142owego dzia\u0142ania systemu wymaga du\u017cego wysi\u0142ku nie tylko od zespo\u0142u developerskiego, ale i testowego. Dobry zestaw test\u00f3w pomaga sprosta\u0107 tym wyzwaniom. Niestety, dba\u0142o\u015b\u0107 o jako\u015b\u0107 nie zawsze idzie w parze z szybko\u015bci\u0105.<\/p>\n\n\n\n<p>Nie tylko test managerowie i project managerowie nie lubi\u0105 d\u0142ugo czeka\u0107 na wyniki test\u00f3w. <strong>To k\u0142opotliwe tak\u017ce dla developer\u00f3w<\/strong> \u2013 przeci\u0105gaj\u0105ce si\u0119 testy aplikacji mog\u0105 by\u0107 jednym z powod\u00f3w op\u00f3\u017anienia rozwoju oprogramowania. Dla dobra projektu testy powinny by\u0107 wykonywane tak szybko, jak to mo\u017cliwe (zachowuj\u0105c rozs\u0105dek \u2013 maj\u0105 one by\u0107 r\u00f3wnie\u017c niezawodne i dawa\u0107 realne informacje na temat testowanej aplikacji). Poni\u017cej kilka sposob\u00f3w na to, jak przyspieszy\u0107 wykonywanie test\u00f3w bez tracenia na jako\u015bci.<\/p>\n\n\n\n<div style=\"height:30px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n<div class=\"wp-block-image size-full\">\n<figure class=\"aligncenter\"><img decoding=\"async\" src=\"https:\/\/nearshore-it.eu\/wp-content\/uploads\/2024\/09\/blog_2023.04.26_graphic_1.png\" alt=\" class=\" class=\"wp-image-7664\" title=\"\"><\/figure>\n<\/div>\n\n\n<div style=\"height:30px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"test\u00f3w\">R\u00f3wnoleg\u0142e uruchamianie test\u00f3w<\/h3>\n\n\n\n<p>Uruchamianie test\u00f3w w spos\u00f3b r\u00f3wnoleg\u0142y jest najlepszym i najbardziej efektywnym sposobem na znaczn\u0105 redukcj\u0119 czasu przeprowadzania test\u00f3w. Domy\u015blnie w wielu narz\u0119dziach testy odbywaj\u0105 si\u0119 w spos\u00f3b sekwencyjny (a wi\u0119c w danej chwili wykonywany jest tylko jeden test, a po jego zako\u0144czeniu uruchomiony zostaje kolejny). W g\u0142\u00f3wnej mierze mo\u017cliwo\u015b\u0107 ta zale\u017cy od wykorzystywanego test runnera i opcji, kt\u00f3re do tego celu udost\u0119pnia.<\/p>\n\n\n\n<p>Przyk\u0142adowo, <a href=\"https:\/\/xunit.net\/docs\/running-tests-in-parallel\" data-type=\"URL\" data-id=\"https:\/\/xunit.net\/docs\/running-tests-in-parallel\" target=\"_blank\" rel=\"noreferrer noopener\">w narz\u0119dziu XUnit<\/a> zastosowana zosta\u0142a <strong>koncepcja zwana test collections,<\/strong> kt\u00f3ra okre\u015bla spos\u00f3b, w jaki testy mog\u0105 by\u0107 wykonane r\u00f3wnolegle. Domy\u015blnie ka\u017cda klasa test\u00f3w stanowi ich unikatow\u0105 kolekcj\u0119, a testy znajduj\u0105ce si\u0119 w tej samej klasie nie b\u0119d\u0105 wykonywa\u0142y si\u0119 r\u00f3wnolegle \u2013 aby by\u0142o to mo\u017cliwe, nale\u017cy je rozdzieli\u0107 na 2 lub wi\u0119cej klas. Dodatkowo narz\u0119dzie to umo\u017cliwia tworzenie niestandardowych kolekcji, gdzie u\u017cytkownik mo\u017ce u\u017cywa\u0107 specjalnych atrybut\u00f3w do ich tworzenia, co u\u0142atwia zarz\u0105dzanie i grupowanie test\u00f3w oraz ich odpowiednie uruchamianie, w zale\u017cno\u015bci od kontekstu. Inne test runnery mog\u0105 posiada\u0107 podobne funkcjonalno\u015bci. Przyk\u0142adowo w narz\u0119dziu <a href=\"https:\/\/playwright.dev\/docs\/test-parallel\" data-type=\"URL\" data-id=\"https:\/\/playwright.dev\/docs\/test-parallel\" target=\"_blank\" rel=\"noreferrer noopener\">Playwright <\/a>mo\u017cna uruchamia\u0107 testy r\u00f3wnolegle zar\u00f3wno w obr\u0119bie jednej klasy testowej, jak i w ca\u0142ym projekcie za pomoc\u0105 parametr\u00f3w konfiguracyjnych. Warto doda\u0107, \u017ce opcja ta jest domy\u015blnie w\u0142\u0105czona.<\/p>\n\n\n\n<p>Jak du\u017co czasu mo\u017cna zaoszcz\u0119dzi\u0107, wykorzystuj\u0105c to podej\u015bcie? Za\u0142\u00f3\u017cmy (bez uwzgl\u0119dniania wydajno\u015bci maszyny, op\u00f3\u017anie\u0144 serwera, przepustowo\u015bci sieci i innych czynnik\u00f3w maj\u0105cych wp\u0142yw na wykonanie test\u00f3w), \u017ce posiadamy kolekcj\u0119 100 test\u00f3w, a ka\u017cdy z nich wykonuje si\u0119 \u015brednio przez minut\u0119. Uruchomienie ich sekwencyjnie zajmie <strong>1 godzin\u0119 i 40 minut<\/strong>. Przy uruchomieniu ich w dw\u00f3ch w\u0105tkach (2 testy wykonywane jednocze\u015bnie) czas potrzebny do ich wykonania skr\u00f3ci si\u0119 o po\u0142ow\u0119 \u2013 <strong>do 50 minut<\/strong>. Do\u0142\u0105czenie kolejnych w\u0105tk\u00f3w pozwoli na jeszcze wi\u0119ksz\u0105 redukcj\u0119 czasu potrzebnego na ich wykonanie.<\/p>\n\n\n\n<p><strong>Potencjalne problemy<\/strong><\/p>\n\n\n\n<p>Niestety, samo uruchamianie test\u00f3w w ten spos\u00f3b nie stanowi z\u0142otego \u015brodka, gdzie wystarczy po prostu zmieni\u0107 konfiguracj\u0119 i zwi\u0119kszy\u0107 liczb\u0119 w\u0105tk\u00f3w. Nale\u017cy pami\u0119ta\u0107 o potencjalnych problemach zwi\u0105zanych z r\u00f3wnoleg\u0142ym uruchamianiem test\u00f3w, na przyk\u0142ad:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>wyniki dzia\u0142ania jednych test\u00f3w mog\u0105 <\/strong>(np. poprzez zmiany w bazie danych czy zu\u017cywanie \/ obci\u0105\u017canie zasob\u00f3w) <strong>wp\u0142ywa\u0107 na wyniki innych test\u00f3w<\/strong>. Tego typu testy nale\u017cy zidentyfikowa\u0107 i uruchamia\u0107 sekwencyjnie (przed lub po kolekcji test\u00f3w wykonywanych r\u00f3wnolegle). Dzi\u0119ki temu zapewnimy pewn\u0105 izolacj\u0119 wszystkim testom i w trakcie wykonywania nie b\u0119d\u0105 mia\u0142y na siebie wp\u0142ywu,<\/li>\n\n\n\n<li><strong>wydajno\u015b\u0107 komputera \/ serwera<\/strong> \u2013 nale\u017cy odpowiednio dobra\u0107 maksymaln\u0105 liczb\u0119 test\u00f3w wykonywanych r\u00f3wnolegle, aby unikn\u0105\u0107 problem\u00f3w z wydajno\u015bci\u0105.<\/li>\n<\/ul>\n\n\n\n<p>Odpowiednie podej\u015bcie do analizy test\u00f3w i podzia\u0142 ich na dwie grupy (te, kt\u00f3re mog\u0105 by\u0107 uruchamiane r\u00f3wnolegle, i te, kt\u00f3re powinny zosta\u0107 uruchamiane sekwencyjnie) oraz dob\u00f3r odpowiednich parametr\u00f3w pozwalaj\u0105cych na okre\u015blenie maksymalnej liczby uruchamianych test\u00f3w mo\u017ce stanowi\u0107 wyzwanie, lecz korzy\u015bci p\u0142yn\u0105ce ze zmiany sposobu uruchamiania test\u00f3w pozwol\u0105 na znaczn\u0105 redukcj\u0119 czasu ich wykonywania, a co za tym idzie \u2013 nie tylko na mo\u017cliwo\u015b\u0107 wykorzystania dodatkowego czasu na inne aktywno\u015bci, ale przede wszystkim otrzymanie szybszego feedbacku z test\u00f3w i mo\u017cliwo\u015b\u0107 szybszej reakcji na potencjalne b\u0142\u0119dy i awarie.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Tworzenie-warunk\u00f3w-wst\u0119pnych,-wykorzystuj\u0105c-interfejsy-API-lub-dzia\u0142anie-bezpo\u015brednio-w-bazie-danych\">Tworzenie warunk\u00f3w wst\u0119pnych, wykorzystuj\u0105c interfejsy API lub dzia\u0142anie bezpo\u015brednio w bazie danych<\/h3>\n\n\n\n<p>W przypadku testowania interfejsu u\u017cytkownika cz\u0119sto niezb\u0119dne jest odpowiednie przygotowanie konfiguracji testowanej aplikacji lub wykorzystanie pewnych danych niezb\u0119dnych do przeprowadzenia testu (najcz\u0119\u015bciej s\u0105 opisane jako warunki wst\u0119pne \u2013<strong> ang. preconditions<\/strong>). Tego typu akcje powinny by\u0107 wykonywane z wykorzystaniem API. Je\u015bli to mo\u017cliwe, dane mo\u017cna przygotowywa\u0107 bezpo\u015brednio w bazie danych. Zwi\u0119ksza to szybko\u015b\u0107 wykonywania test\u00f3w (bezpo\u015brednie \u017c\u0105dania HTTP lub modyfikacja danych w bazie s\u0105 szybsze ni\u017c \u201ewyklikiwanie\u201d poszczeg\u00f3lnych opcji w interfejsie) oraz ich stabilno\u015b\u0107.<\/p>\n\n\n\n<p><strong>Potencjalne problemy<\/strong><\/p>\n\n\n\n<p>Tak\u017ce tu musimy si\u0119 liczy\u0107 z potencjalnymi problemami, takimi jak konieczno\u015b\u0107 utrzymania zgodno\u015bci z API czy baz\u0105 danych. O ile API jest proste w utrzymaniu (w wi\u0119kszo\u015bci przypadk\u00f3w to kwestia dodania\/odj\u0119cia p\u00f3l w \u017c\u0105daniach), o tyle w przypadku bazy danych trzeba zna\u0107 jej struktur\u0119 oraz zale\u017cno\u015bci mi\u0119dzy tabelami.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"poziom\u00f3w\">Konwersja test\u00f3w na testy ni\u017cszych poziom\u00f3w<\/h3>\n\n\n\n<p>Wykonywanie test\u00f3w za po\u015brednictwem interfejsu u\u017cytkownika jest z regu\u0142y wolniejsze i bardziej zawodne ni\u017c testy ni\u017cszego poziomu, takich jak testy API lub jednostkowe. Zgodnie z piramid\u0105 test\u00f3w liczba test\u00f3w UI\/E2E powinna stanowi\u0107 mniejsz\u0105 cz\u0119\u015b\u0107 ni\u017c liczba test\u00f3w z ni\u017cszych poziom\u00f3w.<\/p>\n\n\n\n<div style=\"height:30px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<figure class=\"wp-block-image size-full\"><img decoding=\"async\" src=\"https:\/\/nearshore-it.eu\/wp-content\/uploads\/2024\/09\/2021.07.06_jpro_graphic_piramida_testow.png\" alt=\" class=\" class=\"wp-image-3519\" title=\"\"><\/figure>\n\n\n\n<div style=\"height:30px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p>Testy UI wymagaj\u0105 uruchomienia przegl\u0105darki i interakcji z ni\u0105, co stanowi dodatkowy koszt czasowy i wykorzystuje wi\u0119cej zasob\u00f3w. Renderowanie interfejsu r\u00f3wnie\u017c zabiera czas; zdarza si\u0119, \u017ce czas oczekiwania na poprawne za\u0142adowanie si\u0119 strony trwa d\u0142u\u017cej z r\u00f3\u017cnych powod\u00f3w (np. obci\u0105\u017cony serwer aplikacji lub baza danych). Czasem strona mo\u017ce zachowywa\u0107 si\u0119 nieprzewidywalnie (komponent nie zostanie za\u0142adowany poprawnie, element dynamiczny nie pojawi si\u0119 itp). Mo\u017ce to spowodowa\u0107 nie tylko wyd\u0142u\u017cenie czasu trwania test\u00f3w, ale te\u017c by\u0107 powodem ich niestabilno\u015bci.<\/p>\n\n\n\n<p>Je\u015bli posiadamy wiele test\u00f3w UI, nale\u017cy rozwa\u017cy\u0107 ich konwersj\u0119 na testy ni\u017cszych warstw, je\u017celi jest to mo\u017cliwe. Przyk\u0142adowo, test dost\u0119pu do strony, kt\u00f3ra mo\u017ce by\u0107 przegl\u0105dana jedynie przez zalogowanego u\u017cytkownika (niech b\u0119dzie to panel konta u\u017cytkownika), mo\u017ce zosta\u0107 ca\u0142o\u015bciowo przeprowadzony na warstwie UI \u2013 w\u0142\u0105czaj\u0105c logowanie. Mo\u017cna jednak odpowiednio go zmodyfikowa\u0107 i zaimplementowa\u0107 logowanie do aplikacji poprzez API, dzi\u0119ki czemu warstwa UI zostanie wykorzystana jedynie w celu weryfikacji konkretnej strony. Przeniesienie logowania \u201eni\u017cej&#8221; przyspieszy wykonywanie testu, poniewa\u017c jego w\u0142a\u015bciwe wykonanie po stronie UI b\u0119dzie mo\u017cna rozpocz\u0105\u0107 z ju\u017c zalogowanym u\u017cytkownikiem i wej\u015bciem bezpo\u015brednio na \u017c\u0105dan\u0105 stron\u0119.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"niejsze-pakiety-oraz-grupowanie\">Rozbicie test\u00f3w na mniejsze pakiety oraz grupowanie<\/h3>\n\n\n\n<p>Grupowanie test\u00f3w samo w sobie nie wp\u0142ywa na wykonywanie ju\u017c stworzonych test\u00f3w. Jego zadaniem jest umo\u017cliwienie selekcji konkretnych test\u00f3w lub zestaw\u00f3w test\u00f3w ze wzgl\u0119du na ich w\u0142a\u015bciwo\u015bci (testowany obszar, funkcjonalno\u015b\u0107, typ, priorytet itd.) Dzi\u0119ki odpowiedniemu oznaczeniu przypadk\u00f3w testowych otrzymujemy mo\u017cliwo\u015b\u0107 uruchamiania tylko tych test\u00f3w, kt\u00f3re s\u0105 w danej chwili potrzebne. G\u0142\u00f3wny podzia\u0142 mo\u017ce zosta\u0107 dokonany przez wyodr\u0119bnienie test\u00f3w stabilno\u015bci, dymnych i regresji, a opatrzenie test\u00f3w dodatkowymi atrybutami pozwoli na praktycznie dowoln\u0105 konfiguracj\u0119 ich uruchamiania (np. ze wzgl\u0119du na wspomniany ju\u017c obszar i typ test\u00f3w).<\/p>\n\n\n\n<p>Nie zawsze istnieje konieczno\u015b\u0107 uruchamiania ca\u0142ego zbioru test\u00f3w. Cz\u0119sto chcemy przetestowa\u0107 jedynie wybrany fragment systemu lub konkretn\u0105 funkcjonalno\u015b\u0107. R\u0119czne ich poszukiwanie i uruchamianie by\u0142oby czynno\u015bci\u0105 bardzo czasoch\u0142onn\u0105, a gdy posiadamy du\u017cy zestaw test\u00f3w, istnieje prawdopodobie\u0144stwo, \u017ce niekt\u00f3re mog\u0105 zosta\u0107 pomini\u0119te. Wykorzystanie atrybut\u00f3w w celu filtracji pozwala na konkretn\u0105 selekcj\u0119 wszystkich test\u00f3w, kt\u00f3re s\u0105 potrzebne w danej sytuacji. Dla przyk\u0142adu \u2013 posiadaj\u0105c sklep internetowy i pracuj\u0105c nad nowym typem produktu, mo\u017cna uruchomi\u0107 tylko testy zwi\u0105zane z dodawaniem produktu do koszyka lub listy \u017cycze\u0144, zanim zdecydujemy si\u0119 na pe\u0142n\u0105 regresj\u0119.<\/p>\n\n\n\n<p>Pos\u0142u\u017c\u0119 si\u0119 przyk\u0142adem wzi\u0119tym z \u017cycia. Pracuj\u0105c dla klienta z bran\u017cy bukmacherskiej, w trakcie trwania ka\u017cdego release\u2019u, uruchamiali\u015bmy mi\u0119dzy innymi testy regresji.<\/p>\n\n\n<div class=\"special-content-box style-1\">\r\n    <div class=\"box\">\r\n                <div class=\"content\">\r\n                                <\/div>\r\n    <\/div>\r\n<\/div>\r\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Redukcja-liczby-podobnych-test\u00f3w\">Redukcja liczby podobnych test\u00f3w<\/h3>\n\n\n\n<p id=\".\">Zdarza si\u0119, \u017ce zbi\u00f3r przypadk\u00f3w testowych sk\u0142ada si\u0119 <strong>z test\u00f3w sprawdzaj\u0105cych praktycznie identyczn\u0105 funkcjonalno\u015b\u0107<\/strong>, lecz wykorzystuj\u0105cych<strong> r\u00f3\u017cne dane<\/strong> (np. dodanie 1 produktu do koszyka, dodanie 5 produkt\u00f3w do koszyka, dodanie produktu z kategorii \u201eAGD\u201d do koszyka, dodanie produktu z kategorii \u201eKonsole\u201d do koszyka). Je\u017celi drugi przypadek testowy nie weryfikuje dodatkowych kryteri\u00f3w (np. dodaj 5% zni\u017cki, gdy klient posiada co najmniej 5 produkt\u00f3w w koszyku), nale\u017cy rozwa\u017cy\u0107, czy dany przypadek testowy powinien by\u0107 nadal wykorzystywany. Zdarza si\u0119 to szczeg\u00f3lnie przy du\u017cej liczbie przypadk\u00f3w testowych tworzonych dla du\u017cych system\u00f3w, gdzie w miar\u0119 rozbudowy mo\u017cna straci\u0107 rachub\u0119 i stworzy\u0107 przypadek testowy, kt\u00f3ry na dobr\u0105 spraw\u0119 ju\u017c istnieje.. Okresowa analiza przypadk\u00f3w testowych i ich aktualizacja oraz weryfikacja pomo\u017ce zidentyfikowa\u0107 tego typu przypadki testowe, a dalsze ich badanie pozwoli odpowiedzie\u0107 na pytanie, czy analizowany przypadek testowy zostawi\u0107, zmodyfikowa\u0107 lub ca\u0142kowicie usun\u0105\u0107.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Zmiana-struktury-test\u00f3w-\u2013-dopasowanie-testu-do-testowanej-funkcjonalno\u015bci\">Zmiana struktury test\u00f3w \u2013 dopasowanie testu do testowanej funkcjonalno\u015bci<\/h3>\n\n\n\n<p>Testy powinny by\u0107 nie tylko stabilne i szybkie, ale te\u017c <strong>odpowiednio napisane<\/strong> \u2013 tak, aby testowa\u0142y konkretny obszar aplikacji lub funkcjonalno\u015b\u0107. W odpowiednio zaprojektowanym te\u015bcie liczba krok\u00f3w potrzebnych do pe\u0142nego sprawdzenia funkcjonalno\u015bci powinna by\u0107 jak najmniejsza \u2013 aby nie weryfikowa\u0107 czego\u015b, co nie powinno znajdowa\u0107 si\u0119 w obszarze testu. Przyk\u0142ad \u2013 testuj\u0105c dodawanie produktu do koszyka (zak\u0142adaj\u0105c, \u017ce u\u017cytkownik musi by\u0107 zalogowany), nie powinni\u015bmy skupia\u0107 si\u0119 na asercji, czy u\u017cytkownik faktycznie zosta\u0142 zalogowany \u2013 to powinno zosta\u0107 sprawdzone w te\u015bcie dotycz\u0105cym obszaru logowania klienta do sklepu. W tak\u0105 pu\u0142apk\u0119 mo\u017cna wpa\u015b\u0107 w szczeg\u00f3lno\u015bci, tworz\u0105c testy w procesie <a href=\"https:\/\/nearshore-it.eu\/pl\/artykuly\/testy-bdd-czy-naprawde-sa-potrzebne\" target=\"_blank\" data-type=\"URL\" data-id=\"https:\/\/nearshore-it.eu\/pl\/artykuly\/testy-bdd-czy-naprawde-sa-potrzebne\" rel=\"noreferrer noopener\">BDD <\/a>(przyk\u0142ad: specflow), gdzie cz\u0119sto kroki testu s\u0105 po prostu kopiowane z ju\u017c istniej\u0105cego i umieszczane w nowym, bez odpowiedniej ich edycji w celu jak najlepszego dopasowania ich do kontekstu.<\/p>\n\n\n\n<p class=\"has-text-align-left\">Rozwa\u017cmy test logowania u\u017cytkownika do aplikacji:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">Scenario: Log in to application \nGiven I navigate to the homepage \nAnd I click Login button \nWhen I log in as \u2018testUser\u2019 with password \u2018testPassword\u2019 \nThen I assert that My Account button is displayed \nAnd \u2018testUser\u2019 name is displayed <\/pre>\n\n\n\n<p>Mo\u017cna wykorzysta\u0107 jego kroki i doda\u0107 je na pocz\u0105tku testu dodawania produktu do koszyka:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">Scenario: Add product to basket \nGiven I navigate to the homepage \nAnd I click Login button \nWhen I log in as \u2018testUser\u2019 with password \u2018testPassword\u2019 \nThen I assert that My Account button is displayed \nAnd \u2018testUser\u2019 name is displayed \nWhen I navigate to a test product page \nAnd I add product to basket \nThen Basket should contain test product <\/pre>\n\n\n\n<p>Kroki dotycz\u0105ce poprawno\u015bci zalogowania u\u017cytkownika nie s\u0105 istotne w kontek\u015bcie dodawania produktu do koszyka \u2013 co wi\u0119cej, test logowania jest zduplikowany. Jego sens stoi pod znakiem zapytania, poniewa\u017c logowanie b\u0119dzie sprawdzane w ka\u017cdym te\u015bcie, kt\u00f3ry zostanie napisany na jego podstawie.<\/p>\n\n\n\n<p>Zamiast tego powinien zosta\u0107 on odpowiednio zmodyfikowany, aby uwzgl\u0119dnia\u0107 tylko funkcj\u0119 dodawania do koszyka:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">Scenario: Add product to basket \nGiven I navigate to a test product page \nWhen I log in as \u2018testUser\u2019 with password \u2018testPassword\u2019 \nAnd I add product to basket \nThen Basket should contain test product <\/pre>\n\n\n\n<p>Dzi\u0119ki temu test zosta\u0142 zoptymalizowany pod k\u0105tem szybko\u015bci i testowanej funkcjonalno\u015bci.<\/p>\n\n\n\n<p>Nawi\u0105zuj\u0105c do aspekt\u00f3w zwi\u0105zanych z tworzeniem warunk\u00f3w wst\u0119pnych, logowanie mo\u017cna przenie\u015b\u0107 do tej sekcji i dokona\u0107 go po stronie API, dzi\u0119ki czemu test m\u00f3g\u0142by rozpocz\u0105\u0107 si\u0119 bezpo\u015brednio od nawigacji na stron\u0119 produktu, gdzie u\u017cytkownik by\u0142by ju\u017c zalogowany:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">Background: User is Logged In \nGiven I login as test user through API \nScenario: Add product to basket \nGiven I navigate to a test product page  \nWhen I add product to basket  \nThen Basket should contain test product <\/pre>\n\n\n\n<p>Id\u0105c o krok dalej \u2013 nawi\u0105zuj\u0105c do konwersji test\u00f3w, je\u015bli nie jest konieczne sprawdzenie czego\u015b po stronie UI, mo\u017cna pokusi\u0107 si\u0119 o konwersj\u0119 testu do poziomu API i jeszcze bardziej przyspieszy\u0107 jego wykonywanie.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wait\u00f3w\">Odpowiednie wykorzystanie wait\u00f3w<\/h3>\n\n\n\n<p>Zawarto\u015b\u0107 aplikacji mo\u017ce by\u0107 wy\u015bwietlana statycznie lub dynamicznie. Do dynamicznego wy\u015bwietlania tre\u015bci wykorzystywana jest <strong>technologia AJAX<\/strong>, w kt\u00f3rej komunikacja z serwerem odbywa si\u0119 w spos\u00f3b asynchroniczny, bez konieczno\u015bci prze\u0142adowania ca\u0142ego dokumentu. Dzi\u0119ki temu elementy s\u0105 \u0142adowane na stronie w r\u00f3\u017cnych odst\u0119pach czasu.<\/p>\n\n\n\n<p>Niestety, zachowanie to wymusza stosowanie odpowiedniego podej\u015bcia do interakcji z dynamicznie \u0142adowanymi elementami. Nie zaleca si\u0119 stosowania statycznej metody <strong>Thread.Sleep()<\/strong>, kt\u00f3ra wstrzymuje wykonywanie kodu na okre\u015blony czas. Powoduje to niepotrzebne wyd\u0142u\u017cenie czasu trwania testu, a w przypadku gdy \u017c\u0105dany element zostanie za\u0142adowany szybciej ni\u017c zadeklarowana pauza \u2013 program b\u0119dzie czeka\u0142 bezczynnie, a\u017c up\u0142ynie okre\u015blona jednostka czasu przekazana do metody. W przypadku gdy element nie zostanie za\u0142adowany przed okre\u015blonym czasem \u2013 test zako\u0144czy si\u0119 niepowodzeniem (istnieje wiele czynnik\u00f3w maj\u0105cych wp\u0142yw na za\u0142adowanie si\u0119 elementu (obci\u0105\u017cenie serwera, przepustowo\u015b\u0107 sieci itd.), czasem mo\u017ce zaj\u0105\u0107 kilka, czasem kilkana\u015bcie sekund). Zbyt d\u0142ugi czas oczekiwania mo\u017ce wp\u0142ywa\u0107 te\u017c na stabilno\u015b\u0107 test\u00f3w, kt\u00f3re sporadycznie mog\u0105 ko\u0144czy\u0107 si\u0119 niepowodzeniem.<\/p>\n\n\n\n<p>Wiele framework\u00f3w do automatyzacji (np. <strong>Selenium, Cypress, Playwright czy Spock<\/strong>) zawieraj\u0105 zbudowane rozwi\u0105zania\u2026 Warto te\u017c w tym miejscu wspomnie\u0107 o <strong>zewn\u0119trznych bibliotekach jak np. Awaitility<\/strong>, kt\u00f3re mog\u0105 rozszerza\u0107 funkcjonalno\u015bci innych narz\u0119dzi. Do tego celu mo\u017cna zaimplementowa\u0107 metody, kt\u00f3re b\u0119d\u0105 czeka\u0142y na dalsze wykonanie kodu, dop\u00f3ki okre\u015blony warunek nie zostanie spe\u0142niony (<strong>conditional waits<\/strong>). Dodatkow\u0105 zalet\u0105 tego podej\u015bcia jest mo\u017cliwo\u015b\u0107 zdefiniowania tych metod w spos\u00f3b globalny i u\u017cywania ich bez duplikowania kodu w testach, co u\u0142atwia r\u00f3wnie\u017c utrzymanie repozytorium.<\/p>\n\n\n\n\n\n<h3 class=\"wp-block-heading\" id=\"danych-do-test\u00f3w\">Dedykowana baza danych do test\u00f3w<\/h3>\n\n\n\n<p>Niew\u0105tpliw\u0105 zalet\u0105 jest odseparowanie danych od reszty \u015brodowisk wykorzystywanych w projekcie, dzi\u0119ki czemu procesy nie s\u0105 wzajemnie zaburzane \u2013 nag\u0142e wdro\u017cenie w danym \u015brodowisku wsp\u00f3lnie wykorzystywanym przez ca\u0142y zesp\u00f3\u0142 lub zmiany wprowadzane manualnie nie b\u0119d\u0105 mia\u0142y wp\u0142ywu na wykonywanie test\u00f3w. Do stworzenia takiej bazy mo\u017cna wykorzysta\u0107 baz\u0119 produkcyjn\u0105, dzi\u0119ki czemu otrzymamy \u015brodowisko testowe bardzo zbli\u017cone do tego, z kt\u00f3rego korzystaj\u0105 ko\u0144cowi u\u017cytkownicy aplikacji.<\/p>\n\n\n\n<p>Wykorzystuj\u0105c osobn\u0105 baz\u0119 danych, nale\u017cy pami\u0119ta\u0107 o odpowiednim zarz\u0105dzaniu ni\u0105 \u2013 np. resetowaniu danych, gdy testy zostan\u0105 zako\u0144czone.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"headless\">Wykorzystanie trybu headless<\/h3>\n\n\n\n<p>Tryb headless oznacza, \u017ce przegl\u0105darka zostaje uruchomiona bez graficznego interfejsu. Jej dzia\u0142anie oraz funkcje pozostaj\u0105 niezmienne w stosunku do klasycznie uruchomionej przegl\u0105darki, lecz zasoby nie s\u0105 dodatkowo obci\u0105\u017cone renderowaniem aplikacji internetowej oraz samym uruchomieniem interfejsu przegl\u0105darki. Uruchamianie test\u00f3w z wykorzystaniem tego trybu pozwoli na redukcj\u0119 czasu wykonywania test\u00f3w wzgl\u0119dem test\u00f3w uruchamianych przy u\u017cyciu normalnej przegl\u0105darki. Jest to przydatne w szczeg\u00f3lno\u015bci gdy uruchamiamy wiele test\u00f3w jednocze\u015bnie \u2013 przegl\u0105darki z aktywnym GUI wykorzystuj\u0105 o wiele wi\u0119cej zasob\u00f3w ni\u017c te uruchamiane w trybie headless. Dodatkowym atutem jest mo\u017cliwo\u015b\u0107 u\u017cycia ich do przeprowadzenia test\u00f3w po stronie serwera lub kontener\u00f3w, a st\u0105d prosta droga do w\u0142\u0105czenia ich w proces CI\/CD.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wykonywania-test\u00f3w\">Odpowiedni sprz\u0119t do wykonywania test\u00f3w<\/h3>\n\n\n\n<p>Wykonywanie test\u00f3w, w szczeg\u00f3lno\u015bci E2E, w przegl\u0105darkach wymaga dosy\u0107 du\u017cej mocy obliczeniowej. Testy wykonuj\u0105 wiele operacji (uruchomienie instancji przegl\u0105darki, renderowanie aplikacji, wykonanie kodu test\u00f3w itd.). Przeprowadzanie ich na s\u0142abym wydajno\u015bciowo sprz\u0119cie, zw\u0142aszcza je\u015bli odbywa si\u0119 to r\u00f3wnolegle, mo\u017ce nie tylko negatywnie wp\u0142ywa\u0107 na czas ich wykonania, ale te\u017c prowadzi\u0107 do niestabilno\u015bci. Najprostszym rozwi\u0105zaniem jest aktualizacja komputera \/ serwera, na kt\u00f3rym wykonujemy testy. Pozwoli to zwi\u0119kszy\u0107 szybko\u015b\u0107 wykonywanych test\u00f3w (oraz liczb\u0119 test\u00f3w mog\u0105cych by\u0107 uruchamianych r\u00f3wnolegle).<\/p>\n\n\n\n<p>Gdy istniej\u0105 powody, dla kt\u00f3rych aktualizacja obecnego sprz\u0119tu nie jest mo\u017cliwa, dobrym rozwi\u0105zaniem mo\u017ce okaza\u0107 si\u0119 skorzystanie z us\u0142ug chmurowych.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Podsumowanie\">Podsumowanie<\/h2>\n\n\n\n<p>Odpowiednie narz\u0119dzie do automatyzacji test\u00f3w na pewno pomo\u017ce usprawni\u0107 ca\u0142y proces, ale to tester automatyzuj\u0105cy, jako osoba odpowiedzialna za testy, powinien przestrzega\u0107 dobrych praktyk i promowa\u0107 ich u\u017cycie w projekcie.<strong> Wykorzystuj\u0105c powy\u017csze wskaz\u00f3wki, mo\u017cna przyspieszy\u0107 wykonywanie test\u00f3w automatycznych<\/strong>, dzi\u0119ki czemu informacje na temat niezawodno\u015bci testowanej aplikacji b\u0119d\u0105 dost\u0119pne szybciej. Jest to istotne z punktu widzenia biznesowego \u2013 konkurencja nie \u015bpi, klienci i u\u017cytkownicy ko\u0144cowi oczekuj\u0105, \u017ce wydawana przez nas aplikacja b\u0119dzie dzia\u0142a\u0142a p\u0142ynnie i niezawodnie, a wszelkie poprawki zostan\u0105 wprowadzone najszybciej, jak to mo\u017cliwe. Dzi\u0119ki szybkiemu procesowi testowemu b\u0119dziemy w stanie sprosta\u0107 tym oczekiwaniom.<\/p>\n\n\n\n<p>Stosowanie wymienionych przeze mnie metod jednocze\u015bnie nie jest obligatoryjne, ale wykorzystywanie ka\u017cdej z nich <strong>pozwoli skr\u00f3ci\u0107 czas wykonywania test\u00f3w o kilkadziesi\u0105t minut lub nawet kilka\/kilkana\u015bcie godzin<\/strong>, gdy test\u00f3w jest uruchamianych naprawd\u0119 sporo.<\/p>\n\n\n\n<p>Istotne jest okresowe sprawdzanie zestawu test\u00f3w i dyskusje na temat mo\u017cliwo\u015bci optymalizacji pod ka\u017cdym wzgl\u0119dem \u2013 ka\u017cdy cz\u0142onek zespo\u0142u odpowiedzialnego za wytwarzanie oprogramowania powinien sugerowa\u0107 poprawki, dzi\u0119ki czemu otrzymamy zdywersyfikowany feedback (z punktu widzenia technicznego i biznesowego), na podstawie kt\u00f3rego mo\u017cna prowadzi\u0107 pog\u0142\u0119bione dyskusje i wyci\u0105ga\u0107 odpowiednie wnioski, wykorzystuj\u0105c je do optymalizacji posiadanych test\u00f3w.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>W miar\u0119 post\u0119pu budowania aplikacji liczba test\u00f3w automatycznych odpowiednio ro\u015bnie, a ich wykonywanie zajmuje coraz wi\u0119cej czasu. Na samym pocz\u0105tku czas ich wykonywania mo\u017ce by\u0107 liczony w minutach, a po kilku miesi\u0105cach pracy w godzinach lub nawet dniach. W tym artykule zdradzam kilka sprawdzonych metod i dobrych praktyk testerskich, kt\u00f3re pomog\u0105 ci zredukowa\u0107 czas potrzebny na wykonywanie test\u00f3w.<\/p>\n","protected":false},"author":143,"featured_media":31233,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"iawp_total_views":42,"footnotes":""},"categories":[1,582],"tags":[],"offering":[513],"class_list":["post-31228","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artykuly","category-technologie","offering-application-development"],"acf":[],"_links":{"self":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/31228","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/users\/143"}],"replies":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/comments?post=31228"}],"version-history":[{"count":7,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/31228\/revisions"}],"predecessor-version":[{"id":33818,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/31228\/revisions\/33818"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media\/31233"}],"wp:attachment":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media?parent=31228"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/categories?post=31228"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/tags?post=31228"},{"taxonomy":"offering","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/offering?post=31228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}