Testy komponent\u00f3w \u2013 czym s\u0105?<\/strong><\/h2>\n\n\n\nTesty komponent\u00f3w w obszarze testowania front-end odnosz\u0105 si\u0119 do praktyki sprawdzania pojedynczych komponent\u00f3w lub jednostek aplikacji internetowej w izolacji. G\u0142\u00f3wnym celem jest zapewnienie, \u017ce ka\u017cdy komponent zadzia\u0142a zgodnie z oczekiwaniami, ju\u017c we wczesnej fazie rozwoju.<\/p>\n\n\n\n
Komponenty w tym kontek\u015bcie to zazwyczaj mniejsze, niezale\u017cne fragmenty interfejsu u\u017cytkownika, takie jak:<\/p>\n\n\n\n
\n- przyciski,<\/li>\n\n\n\n
- formularze,<\/li>\n\n\n\n
- niestandardowe elementy interfejsu.<\/li>\n<\/ul>\n\n\n\n
Przyk\u0142adowo \u2013 popularny \u201edate-picker\u201d idealnie wpisuje si\u0119 w t\u0119 definicj\u0119 i stanowi doskona\u0142y przedmiot sprawdzenia test\u00f3w na \u201ew\u0142asnej klawiaturze\u201d.<\/p>\n\n\n\n
Korzy\u015bci wynikaj\u0105ce z test\u00f3w<\/strong><\/h2>\n\n\n\nTesty te przynosz\u0105 szereg korzy\u015bci, a ich kr\u00f3tka charakterystyka jest nast\u0119puj\u0105ca:<\/p>\n\n\n\n
\n- Testy w izolacji<\/strong> \u2013 oznacza to, \u017ce nie potrzebujemy rzeczywistego dzia\u0142aj\u0105cego oprogramowania, serwisu, strony internetowej ani serwera, aby przeprowadzi\u0107 test. Dzi\u0119ki temu zyskujemy zar\u00f3wno na czasie, jak i na stabilno\u015bci tych test\u00f3w.<\/li>\n\n\n\n
- Ma\u0142e i szybkie testy<\/strong> \u2013 przeprowadzamy testy komponent\u00f3w prawie tak samo, jak testy jednostkowe. To pozwala nam w szybki spos\u00f3b wykry\u0107 ewentualne nieprawid\u0142owo\u015bci, co skutkuje wczesn\u0105 i stosunkowo niedrog\u0105 napraw\u0105.<\/li>\n\n\n\n
- \u0141atwy i czytelny kod<\/strong> \u2013 przy u\u017cyciu tej praktyki wprowadzamy \u0142atwo\u015b\u0107 utrzymania kodu i zwi\u0119kszamy jego przejrzysto\u015b\u0107. Aplikacja jest podzielona na mniejsze cz\u0119\u015bci, kt\u00f3re s\u0105 nast\u0119pnie testowane przez te w\u0142a\u015bnie komponentowe testy.<\/li>\n\n\n\n
- Automatyzacja i integracja<\/strong> \u2013 testy te mo\u017cna z \u0142atwo\u015bci\u0105 zautomatyzowa\u0107 i w\u0142\u0105czy\u0107 w narz\u0119dzia do ci\u0105g\u0142ej integracji. Mamy mo\u017cliwo\u015b\u0107 uruchamia\u0107 je lokalnie na kontenerze Docker, co jest szczeg\u00f3lnie przydatne, gdy dopiero rozpoczynamy swoj\u0105 przygod\u0119 z testami automatycznymi.<\/li>\n<\/ul>\n\n\n\n
Ale po co nam w\u0142a\u015bciwie testy komponent\u00f3w?<\/strong><\/h2>\n\n\n\nAby odpowiedzie\u0107 na to pytanie, zapoznamy si\u0119 z potrzeb\u0105 oraz istot\u0105 test\u00f3w automatycznych<\/strong>.<\/p>\n\n\n\nTest automatyczny to cz\u0119\u015b\u0107 procesu, w kt\u00f3rym sprawdzamy scenariusze testowe za pomoc\u0105 narz\u0119dzi do automatyzacji lub skrypt\u00f3w. Wa\u017cne jest jednak pami\u0119tanie o podstawach testowania, poniewa\u017c s\u0105 one kluczowe przy tworzeniu przypadk\u00f3w testowych.<\/p>\n\n\n\n
W moim przekonaniu, dobry test automatyczny powinien sk\u0142ada\u0107 si\u0119 z trzech element\u00f3w:<\/p>\n\n\n\n
\n- danych testowych,<\/li>\n\n\n\n
- krok\u00f3w,<\/li>\n\n\n\n
- jednej asercji.<\/li>\n<\/ol>\n\n\n\n
Stawiaj\u0105c to ostatnie jako istotne kryterium, poruszam do\u015b\u0107 kontrowersyjny temat<\/strong>. Test, kt\u00f3ry sprawdza wiele rzeczy \u2013 moim zdaniem \u2013 jest niezbyt wiarygodny, trudny w utrzymaniu i weryfikacji.<\/p>\n\n\n\nPrzyjrzyjmy si\u0119 sytuacji<\/strong>, gdzie chcemy napisa\u0107 test, kt\u00f3ry wysy\u0142a formularz rejestracji u\u017cytkownika. Wype\u0142niamy wszystkie pola i klikamy przycisk \u201ewy\u015blij\u201d za pomoc\u0105 cy.contains(„wy\u015blij”). Pojawia si\u0119 jednak pytanie \u2013 co si\u0119 stanie, je\u015bli nasz przycisk ma inny tekst, na przyk\u0142ad z powodu problem\u00f3w z wy\u015bwietlaniem polskich znak\u00f3w? Otrzymujemy wynik negatywny w te\u015bcie, kt\u00f3ry tworzy u\u017cytkownika, pomimo \u017ce ci\u0105g znak\u00f3w (popularnie nazywany stringiem), po kt\u00f3rym szukamy przycisku, jest inny.<\/p>\n\n\n\nCo mo\u017cemy zrobi\u0107 w tej sytuacji?<\/strong> Napisa\u0107 lepszy test! Mo\u017cemy u\u017cy\u0107 metody cy.get() i poda\u0107 tutaj nasz unikalny identyfikator (cy-data lokator). Ten spos\u00f3b eliminuje konieczno\u015b\u0107 wyszukiwania element\u00f3w po konkretnym ci\u0105gu znak\u00f3w i odnosi si\u0119 do lokatora. Jednak\u017ce, zdarza si\u0119, \u017ce korzystamy z metody cy.contains(), poniewa\u017c jest to bardziej wygodne i efektywne, ni\u017c w przypadku u\u017cycia metody cy.get().<\/p>\n\n\n\nCo jednak, je\u015bli mieliby\u015bmy test komponentu<\/strong>, kt\u00f3ry generuje ten element z oczekiwanym ci\u0105giem znak\u00f3w, sprawdzaj\u0105c jednocze\u015bnie jego tekst, zachowanie i style CSS?<\/p>\n\n\n\nNasze narz\u0119dzie do ci\u0105g\u0142ej integracji nie pozwoli\u0142oby na uruchomienie kolejnych test\u00f3w bez naprawy tego, co daje wynik negatywny. Dzi\u0119ki wczesnemu wykryciu b\u0142\u0119du, mo\u017cemy szybko i tanio go naprawi\u0107. Dodatkowo, dzi\u0119ki temu unikniemy fa\u0142szywie negatywnych wynik\u00f3w<\/strong> w pozosta\u0142ych testach, gdzie to w\u0142a\u015bnie komponent jest winny, a nie logika samego kodu.<\/p>\n\n\n\nTesty komponent\u00f3w a piramida test\u00f3w<\/strong><\/h2>\n\n\n\nPiramida test\u00f3w jest to \u201ewzorzec projektowy\u201d, kt\u00f3ry przedstawia nam kolejno\u015b\u0107 test\u00f3w oraz ich ilo\u015bci. Zgodnie z og\u00f3lnie przyj\u0119t\u0105 norm\u0105, dzieli si\u0119 ona na trzy poziomy. S\u0105 one u\u0142o\u017cone jeden na drugim, w kolejno\u015bci wzgl\u0119dem kosztu stworzenia\/utrzymania, czy te\u017c samego czasu wykonania.<\/p>\n\n\n\n![\"Piramida](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image1-3.png\")
<\/a>Ryc. 1 Piramida test\u00f3w przedstawiaj\u0105ca 3 g\u0142\u00f3wne poziomy test\u00f3w<\/figcaption><\/figure>\n\n\n\nUnit testy<\/strong><\/h3>\n\n\n\nUnit testy czyli testy jednostkowe \u2013 w wi\u0119kszo\u015bci przypadk\u00f3w pisane przez developer\u00f3w. Maj\u0105 one za zadanie sprawdzi\u0107 metod\u0119\/funkcj\u0119\/modu\u0142 na poziomie jednostkowym. Powinny mie\u0107 jak najwi\u0119ksze, realne pokrycie kodu.<\/p>\n\n\n\n
Przedstawia si\u0119 je jako podstaw\u0119\/fundament piramidy test\u00f3w, poniewa\u017c s\u0105:<\/p>\n\n\n\n
\n- niezale\u017cne od zewn\u0119trznych serwis\u00f3w,<\/li>\n\n\n\n
- niezwykle szybkie do napisania i wykonania,<\/li>\n\n\n\n
- tanie w utrzymaniu i tworzeniu,<\/li>\n<\/ul>\n\n\n\n
Ponadto, mog\u0105 te\u017c by\u0107 traktowane jako swojego rodzaju dokumentacja projektowa.<\/p>\n\n\n\n
Testy integracyjne<\/strong><\/h3>\n\n\n\nNa kolejnym poziomie znajduj\u0105 si\u0119 testy integracyjne, w kt\u00f3rych sk\u0142ad wchodz\u0105 testy:<\/p>\n\n\n\n
\n- systemowe,<\/li>\n\n\n\n
- integracyjne.<\/li>\n<\/ul>\n\n\n\n
Sprawdzaj\u0105 one, czy poszczeg\u00f3lne modu\u0142y ze sob\u0105 rozmawiaj\u0105 \u2013 zar\u00f3wno z danymi testowymi, jak i realnymi. Pisane i wykonywane s\u0105 g\u0142\u00f3wnie przez tester\u00f3w, ale to te\u017c zale\u017cy od ustale\u0144 w danym zespole oraz od podej\u015bcia projektowego. Mog\u0105 by\u0107 uzale\u017cnione od zewn\u0119trznych serwis\u00f3w, w zale\u017cno\u015bci od skomplikowania, jednak s\u0105 zdecydowanie ta\u0144sze oraz szybsze od test\u00f3w E2E.<\/p>\n\n\n\n
Testy End-to-End<\/strong><\/h3>\n\n\n\nTesty E2E sprawdzaj\u0105 \u015bcie\u017cki biznesowe, zaczynaj\u0105c od stworzenia u\u017cytkownika, poprzez zakup przedmiotu w sklepie internetowym. Jednak posiadaj\u0105 nast\u0119puj\u0105ce wady:<\/p>\n\n\n\n
\n- s\u0105 niestabilne,<\/li>\n\n\n\n
- s\u0105 bardzo drogie w tworzeniu i utrzymaniu,<\/li>\n\n\n\n
- pokrywaj\u0105 znikom\u0105 cz\u0119\u015b\u0107 kodu,<\/li>\n\n\n\n
- czas wykonania tych test\u00f3w jest du\u017co d\u0142u\u017cszy ni\u017c test\u00f3w jednostkowych, czy te\u017c integracyjnych.<\/li>\n<\/ul>\n\n\n\n
A gdzie s\u0105 testy komponent\u00f3w w piramidzie test\u00f3w?<\/strong><\/h3>\n\n\n\nPo tym, co przeczytali\u015bcie o samych testach komponent\u00f3w, jak i piramidzie test\u00f3w, mo\u017cecie wydedukowa\u0107, \u017ce testy komponent\u00f3w znajduj\u0105 si\u0119 pomi\u0119dzy warstw\u0105 jednostkow\u0105 a integracyjn\u0105. I dok\u0142adnie w tym miejscu ja je umieszczam.<\/p>\n\n\n\n![\"Piramida](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image2-1.png\")
<\/a>Ryc. 2 Piramida test\u00f3w z umiejscowieniem test\u00f3w komponent\u00f3w<\/figcaption><\/figure>\n\n\n\nKto powinien pisa\u0107\/tworzy\u0107 testy komponent\u00f3w?<\/strong><\/h2>\n\n\n\nPowstaje pytanie o to, kto powinien tworzy\u0107 testy komponent\u00f3w. Sytuacja jest podobna, jak w przypadku test\u00f3w jednostkowych. \u0179r\u00f3d\u0142a internetowe twierdz\u0105, \u017ce za testy komponent\u00f3w odpowiedzialni si\u0105 deweloperzy, jednak z do\u015bwiadczenia wiem, \u017ce wi\u0119kszo\u015b\u0107 z nich skupia si\u0119 bardziej na implementacji kodu, ni\u017c pisaniu test\u00f3w. Jest to r\u00f3wnie\u017c dyskusyjny temat<\/strong> zwi\u0105zany z definicj\u0105 uko\u0144czenia, z podej\u015bciem projektowym oraz zespo\u0142owym.<\/p>\n\n\n\nMoim zdaniem pisanie test\u00f3w komponent\u00f3w to idealne zadanie dla testera, kt\u00f3ry chce rozpocz\u0105\u0107 swoj\u0105 przygod\u0119 z testami automatycznymi, poniewa\u017c s\u0105 one \u0142atwe w przygotowaniu i utrzymaniu, a ich wyniki s\u0105 bardzo czytelne, rzetelne i transparentne<\/strong>.<\/p>\n\n\n\nTesty komponent\u00f3w w praktyce<\/strong><\/h2>\n\n\n\nPrzedstawi\u0119 i om\u00f3wi\u0119 dwa podej\u015bcia \u2013 stary i nowy spos\u00f3b tworzenia test\u00f3w komponent\u00f3w wraz z ich implementacj\u0105 w j\u0119zyku JavaScript z wykorzystaniem Cypressa.<\/p>\n\n\n\n
Old-fashion way<\/strong><\/h3>\n\n\n\nStare podej\u015bcie \u2013 spotykane nie tylko w Cypressie, ale r\u00f3wnie\u017c w innych frameworkach testowych, gdzie nie mamy obecnie mo\u017cliwo\u015bci wy\u015bwietlania komponent\u00f3w. Znaj\u0105c ograniczenia, postarajmy si\u0119 to zaimplementowa\u0107.<\/p>\n\n\n\n
Chcemy, aby test sprawdzi\u0142, czy przycisk \u201eClick me\u201d na stronie spe\u0142nia oczekiwania. Weryfikujemy to na naszej uruchomionej lokalnej wersji tworzonego oprogramowania pod adresem http:\/\/localhost:4200\/<\/a>:<\/p>\n\n\n\n![\"Weryfikacja](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image3-2.png\")
<\/a>Ryc. 3 Weryfikacja dzia\u0142ania przycisku \u201eClick me\u201d<\/figcaption><\/figure>\n\n\n\nTworzymy przypadki testowe i sprawdzamy, czy to dzia\u0142a:<\/p>\n\n\n\n
\n- Sprawd\u017a, czy przycisk ma napis \u201eClick me\u201d.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk ma czerwony kolor t\u0142a.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk wy\u015bwietla poprawnie text 1!2#45.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk wy\u015bwietla poprawnie zmieniony kolor na niebieski.<\/li>\n<\/ol>\n\n\n\n
![\"kod\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image4-1.png\")
<\/a><\/figure>\n\n\n\nPrzedstawiony kod wygl\u0105da schludnie i czytelnie. Przy zastosowaniu wzorca projektowego Page-Object i wyciagni\u0119ciu do zmiennych powtarzaj\u0105cych si\u0119 element\u00f3w, mo\u017cemy uzyska\u0107 jeszcze bardziej przejrzysty kod. Jego wad\u0105 niew\u0105tpliwie jest czas wykonywania, kt\u00f3ry przy czterech testach wynosi tylko, albo a\u017c, 809ms.<\/p>\n\n\n\n
Musimy zwr\u00f3ci\u0107 uwag\u0119 na to, \u017ce do przycisku dostajemy si\u0119 natychmiast po za\u0142adowaniu \u201elocalhosta\u201d. Nie wymaga on \u017cadnej dodatkowe interakcji, co przy czterech przypadkach testowych pozwala nam osi\u0105gn\u0105\u0107 akceptowalny czas. Jednak\u017ce bardziej skomplikowane jest wyodr\u0119bnienie poszczeg\u00f3lnych element\u00f3w. Przyk\u0142adowo \u2013 edycji u\u017cytkownika z trzeciej strony formularza, aby dotrze\u0107 do przycisku reset, kt\u00f3ry jednak pojawia si\u0119 dopiero po dokonaniu edycji dowolnego pola.<\/p>\n\n\n\n
I nagle test wygl\u0105da tak:<\/p>\n\n\n\n![\"kod\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image5-3.png\")
<\/a><\/figure>\n\n\n\nW takim przypadku istnieje zagro\u017cenie, \u017ce stracimy sporo czasu na pozyskanie tego elementu, co mo\u017ce prowadzi\u0107 do znacznego wzrostu kodu oraz uzale\u017cnienia od innych serwis\u00f3w.<\/p>\n\n\n\n
Co by si\u0119 sta\u0142o, gdyby\u015bmy sprawdzili przycisk na \u201eprodukcyjnym\u201d serwerze? Wykonanie tych czterech test\u00f3w zaj\u0119\u0142o mi 12 sekund.<\/p>\n\n\n\n
Co mo\u017cemy zrobi\u0107, aby nasz test by\u0142 lepszy i szybszy?<\/strong><\/h2>\n\n\n\nCo warto uwzgl\u0119dni\u0107, by testy by\u0142y bardziej efektywne:<\/p>\n\n\n\n
\n- Je\u017celi mamy StoryBooka lub inne podobne narz\u0119dzie, napiszmy testy w tym narz\u0119dziu. Mo\u017cemy napotka\u0107 nieprzyjemno\u015bci z Iframe, jednak ich skala jest drastycznie mniejsza do czasu uruchomienia tych test\u00f3w. Ponadto s\u0105 one bardzo zbli\u017cone do samych test\u00f3w komponent\u00f3w.<\/li>\n\n\n\n
- Po\u0142\u0105czmy wszystkie asercje w jednym te\u015bcie, korzystaj\u0105c z tzw. Soft asercji (asercja, kt\u00f3ra w monecie wyst\u0105pienia nie przerywa testu), aby zaoszcz\u0119dzi\u0107 czas podczas odwiedzania strony lub elementu. Pomys\u0142 ten mo\u017ce by\u0107 korzystny, zw\u0142aszcza z odpowiednim reporterem, co mo\u017ce naprawd\u0119 zaowocowa\u0107. (Jest to potencjalny antywzorzec, poniewa\u017c test powinien sk\u0142ada\u0107 si\u0119 z jednej asercji, ale… to temat na osobny wpis). Uda\u0142o mi si\u0119 uzyska\u0107 czas 358 ms.<\/li>\n\n\n\n
- Nie od\u015bwie\u017cajmy strony i wykonajmy asercje w osobnych testach (antywzorzec, poniewa\u017c testy s\u0105 zale\u017cne od siebie). Czas: 278 ms.<\/li>\n\n\n\n
- Wykorzystajmy testy komponent\u00f3w dostarczone od Cypressa z wykorzystaniem metody cy.mount()!<\/li>\n<\/ol>\n\n\n\n
![\"kod\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image6-2.png\")
<\/a><\/figure>\n\n\n\nDzi\u0119ki tej metodzie mamy mo\u017cliwo\u015b\u0107 wygenerowania komponentu pojedynczo poprzez jego import i przekazanie go do metody mount(). Oszcz\u0119dzamy czas na pisanie i egzekucj\u0119, nasz kod jest przejrzysty, a testy wiarygodne. Czas, jaki otrzyma\u0142em, to 162 ms! Czyli najlepszy jak do tej pory.<\/p>\n\n\n\n![\"Testy](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image7-3-1024x244.png\")
<\/a>Ryc. 4 Testy komponent\u00f3w<\/figcaption><\/figure>\n\n\n\nJe\u015bli nie Cypress, to co?<\/strong><\/h2>\n\n\n\nTestowanie komponent\u00f3w nie ogranicza si\u0119 jedynie do narz\u0119dzia Cypress. Istnieje szereg alternatywnych narz\u0119dzi, takich jak:<\/p>\n\n\n\n
\n- Jest,<\/li>\n\n\n\n
- Enzyme,<\/li>\n\n\n\n
- Vue Test Utils,<\/li>\n<\/ul>\n\n\n\n
kt\u00f3re r\u00f3wnie\u017c mog\u0105 by\u0107 skutecznie u\u017cywane do tej praktyki.<\/p>\n\n\n\n
Te r\u00f3\u017cnorodne opcje pozwalaj\u0105 deweloperom na dostosowywanie narz\u0119dzi do konkretnych potrzeb projektu, co staje si\u0119 szczeg\u00f3lnie istotne w sytuacjach, gdy Cypress, z r\u00f3\u017cnych powod\u00f3w, nie spe\u0142nia oczekiwa\u0144.<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Wi\u0119cej o Cypress dowiesz si\u0119 z innych artyku\u0142\u00f3w naszych ekspert\u00f3w<\/a>. <\/p>\n\n\n
Przyk\u0142adowo \u2013 popularny \u201edate-picker\u201d idealnie wpisuje si\u0119 w t\u0119 definicj\u0119 i stanowi doskona\u0142y przedmiot sprawdzenia test\u00f3w na \u201ew\u0142asnej klawiaturze\u201d.<\/p>\n\n\n\n
Korzy\u015bci wynikaj\u0105ce z test\u00f3w<\/strong><\/h2>\n\n\n\nTesty te przynosz\u0105 szereg korzy\u015bci, a ich kr\u00f3tka charakterystyka jest nast\u0119puj\u0105ca:<\/p>\n\n\n\n
\n- Testy w izolacji<\/strong> \u2013 oznacza to, \u017ce nie potrzebujemy rzeczywistego dzia\u0142aj\u0105cego oprogramowania, serwisu, strony internetowej ani serwera, aby przeprowadzi\u0107 test. Dzi\u0119ki temu zyskujemy zar\u00f3wno na czasie, jak i na stabilno\u015bci tych test\u00f3w.<\/li>\n\n\n\n
- Ma\u0142e i szybkie testy<\/strong> \u2013 przeprowadzamy testy komponent\u00f3w prawie tak samo, jak testy jednostkowe. To pozwala nam w szybki spos\u00f3b wykry\u0107 ewentualne nieprawid\u0142owo\u015bci, co skutkuje wczesn\u0105 i stosunkowo niedrog\u0105 napraw\u0105.<\/li>\n\n\n\n
- \u0141atwy i czytelny kod<\/strong> \u2013 przy u\u017cyciu tej praktyki wprowadzamy \u0142atwo\u015b\u0107 utrzymania kodu i zwi\u0119kszamy jego przejrzysto\u015b\u0107. Aplikacja jest podzielona na mniejsze cz\u0119\u015bci, kt\u00f3re s\u0105 nast\u0119pnie testowane przez te w\u0142a\u015bnie komponentowe testy.<\/li>\n\n\n\n
- Automatyzacja i integracja<\/strong> \u2013 testy te mo\u017cna z \u0142atwo\u015bci\u0105 zautomatyzowa\u0107 i w\u0142\u0105czy\u0107 w narz\u0119dzia do ci\u0105g\u0142ej integracji. Mamy mo\u017cliwo\u015b\u0107 uruchamia\u0107 je lokalnie na kontenerze Docker, co jest szczeg\u00f3lnie przydatne, gdy dopiero rozpoczynamy swoj\u0105 przygod\u0119 z testami automatycznymi.<\/li>\n<\/ul>\n\n\n\n
Ale po co nam w\u0142a\u015bciwie testy komponent\u00f3w?<\/strong><\/h2>\n\n\n\nAby odpowiedzie\u0107 na to pytanie, zapoznamy si\u0119 z potrzeb\u0105 oraz istot\u0105 test\u00f3w automatycznych<\/strong>.<\/p>\n\n\n\nTest automatyczny to cz\u0119\u015b\u0107 procesu, w kt\u00f3rym sprawdzamy scenariusze testowe za pomoc\u0105 narz\u0119dzi do automatyzacji lub skrypt\u00f3w. Wa\u017cne jest jednak pami\u0119tanie o podstawach testowania, poniewa\u017c s\u0105 one kluczowe przy tworzeniu przypadk\u00f3w testowych.<\/p>\n\n\n\n
W moim przekonaniu, dobry test automatyczny powinien sk\u0142ada\u0107 si\u0119 z trzech element\u00f3w:<\/p>\n\n\n\n
\n- danych testowych,<\/li>\n\n\n\n
- krok\u00f3w,<\/li>\n\n\n\n
- jednej asercji.<\/li>\n<\/ol>\n\n\n\n
Stawiaj\u0105c to ostatnie jako istotne kryterium, poruszam do\u015b\u0107 kontrowersyjny temat<\/strong>. Test, kt\u00f3ry sprawdza wiele rzeczy \u2013 moim zdaniem \u2013 jest niezbyt wiarygodny, trudny w utrzymaniu i weryfikacji.<\/p>\n\n\n\nPrzyjrzyjmy si\u0119 sytuacji<\/strong>, gdzie chcemy napisa\u0107 test, kt\u00f3ry wysy\u0142a formularz rejestracji u\u017cytkownika. Wype\u0142niamy wszystkie pola i klikamy przycisk \u201ewy\u015blij\u201d za pomoc\u0105 cy.contains(„wy\u015blij”). Pojawia si\u0119 jednak pytanie \u2013 co si\u0119 stanie, je\u015bli nasz przycisk ma inny tekst, na przyk\u0142ad z powodu problem\u00f3w z wy\u015bwietlaniem polskich znak\u00f3w? Otrzymujemy wynik negatywny w te\u015bcie, kt\u00f3ry tworzy u\u017cytkownika, pomimo \u017ce ci\u0105g znak\u00f3w (popularnie nazywany stringiem), po kt\u00f3rym szukamy przycisku, jest inny.<\/p>\n\n\n\nCo mo\u017cemy zrobi\u0107 w tej sytuacji?<\/strong> Napisa\u0107 lepszy test! Mo\u017cemy u\u017cy\u0107 metody cy.get() i poda\u0107 tutaj nasz unikalny identyfikator (cy-data lokator). Ten spos\u00f3b eliminuje konieczno\u015b\u0107 wyszukiwania element\u00f3w po konkretnym ci\u0105gu znak\u00f3w i odnosi si\u0119 do lokatora. Jednak\u017ce, zdarza si\u0119, \u017ce korzystamy z metody cy.contains(), poniewa\u017c jest to bardziej wygodne i efektywne, ni\u017c w przypadku u\u017cycia metody cy.get().<\/p>\n\n\n\nCo jednak, je\u015bli mieliby\u015bmy test komponentu<\/strong>, kt\u00f3ry generuje ten element z oczekiwanym ci\u0105giem znak\u00f3w, sprawdzaj\u0105c jednocze\u015bnie jego tekst, zachowanie i style CSS?<\/p>\n\n\n\nNasze narz\u0119dzie do ci\u0105g\u0142ej integracji nie pozwoli\u0142oby na uruchomienie kolejnych test\u00f3w bez naprawy tego, co daje wynik negatywny. Dzi\u0119ki wczesnemu wykryciu b\u0142\u0119du, mo\u017cemy szybko i tanio go naprawi\u0107. Dodatkowo, dzi\u0119ki temu unikniemy fa\u0142szywie negatywnych wynik\u00f3w<\/strong> w pozosta\u0142ych testach, gdzie to w\u0142a\u015bnie komponent jest winny, a nie logika samego kodu.<\/p>\n\n\n\nTesty komponent\u00f3w a piramida test\u00f3w<\/strong><\/h2>\n\n\n\nPiramida test\u00f3w jest to \u201ewzorzec projektowy\u201d, kt\u00f3ry przedstawia nam kolejno\u015b\u0107 test\u00f3w oraz ich ilo\u015bci. Zgodnie z og\u00f3lnie przyj\u0119t\u0105 norm\u0105, dzieli si\u0119 ona na trzy poziomy. S\u0105 one u\u0142o\u017cone jeden na drugim, w kolejno\u015bci wzgl\u0119dem kosztu stworzenia\/utrzymania, czy te\u017c samego czasu wykonania.<\/p>\n\n\n\n<\/a>Ryc. 1 Piramida test\u00f3w przedstawiaj\u0105ca 3 g\u0142\u00f3wne poziomy test\u00f3w<\/figcaption><\/figure>\n\n\n\nUnit testy<\/strong><\/h3>\n\n\n\nUnit testy czyli testy jednostkowe \u2013 w wi\u0119kszo\u015bci przypadk\u00f3w pisane przez developer\u00f3w. Maj\u0105 one za zadanie sprawdzi\u0107 metod\u0119\/funkcj\u0119\/modu\u0142 na poziomie jednostkowym. Powinny mie\u0107 jak najwi\u0119ksze, realne pokrycie kodu.<\/p>\n\n\n\n
Przedstawia si\u0119 je jako podstaw\u0119\/fundament piramidy test\u00f3w, poniewa\u017c s\u0105:<\/p>\n\n\n\n
\n- niezale\u017cne od zewn\u0119trznych serwis\u00f3w,<\/li>\n\n\n\n
- niezwykle szybkie do napisania i wykonania,<\/li>\n\n\n\n
- tanie w utrzymaniu i tworzeniu,<\/li>\n<\/ul>\n\n\n\n
Ponadto, mog\u0105 te\u017c by\u0107 traktowane jako swojego rodzaju dokumentacja projektowa.<\/p>\n\n\n\n
Testy integracyjne<\/strong><\/h3>\n\n\n\nNa kolejnym poziomie znajduj\u0105 si\u0119 testy integracyjne, w kt\u00f3rych sk\u0142ad wchodz\u0105 testy:<\/p>\n\n\n\n
\n- systemowe,<\/li>\n\n\n\n
- integracyjne.<\/li>\n<\/ul>\n\n\n\n
Sprawdzaj\u0105 one, czy poszczeg\u00f3lne modu\u0142y ze sob\u0105 rozmawiaj\u0105 \u2013 zar\u00f3wno z danymi testowymi, jak i realnymi. Pisane i wykonywane s\u0105 g\u0142\u00f3wnie przez tester\u00f3w, ale to te\u017c zale\u017cy od ustale\u0144 w danym zespole oraz od podej\u015bcia projektowego. Mog\u0105 by\u0107 uzale\u017cnione od zewn\u0119trznych serwis\u00f3w, w zale\u017cno\u015bci od skomplikowania, jednak s\u0105 zdecydowanie ta\u0144sze oraz szybsze od test\u00f3w E2E.<\/p>\n\n\n\n
Testy End-to-End<\/strong><\/h3>\n\n\n\nTesty E2E sprawdzaj\u0105 \u015bcie\u017cki biznesowe, zaczynaj\u0105c od stworzenia u\u017cytkownika, poprzez zakup przedmiotu w sklepie internetowym. Jednak posiadaj\u0105 nast\u0119puj\u0105ce wady:<\/p>\n\n\n\n
\n- s\u0105 niestabilne,<\/li>\n\n\n\n
- s\u0105 bardzo drogie w tworzeniu i utrzymaniu,<\/li>\n\n\n\n
- pokrywaj\u0105 znikom\u0105 cz\u0119\u015b\u0107 kodu,<\/li>\n\n\n\n
- czas wykonania tych test\u00f3w jest du\u017co d\u0142u\u017cszy ni\u017c test\u00f3w jednostkowych, czy te\u017c integracyjnych.<\/li>\n<\/ul>\n\n\n\n
A gdzie s\u0105 testy komponent\u00f3w w piramidzie test\u00f3w?<\/strong><\/h3>\n\n\n\nPo tym, co przeczytali\u015bcie o samych testach komponent\u00f3w, jak i piramidzie test\u00f3w, mo\u017cecie wydedukowa\u0107, \u017ce testy komponent\u00f3w znajduj\u0105 si\u0119 pomi\u0119dzy warstw\u0105 jednostkow\u0105 a integracyjn\u0105. I dok\u0142adnie w tym miejscu ja je umieszczam.<\/p>\n\n\n\n<\/a>Ryc. 2 Piramida test\u00f3w z umiejscowieniem test\u00f3w komponent\u00f3w<\/figcaption><\/figure>\n\n\n\nKto powinien pisa\u0107\/tworzy\u0107 testy komponent\u00f3w?<\/strong><\/h2>\n\n\n\nPowstaje pytanie o to, kto powinien tworzy\u0107 testy komponent\u00f3w. Sytuacja jest podobna, jak w przypadku test\u00f3w jednostkowych. \u0179r\u00f3d\u0142a internetowe twierdz\u0105, \u017ce za testy komponent\u00f3w odpowiedzialni si\u0105 deweloperzy, jednak z do\u015bwiadczenia wiem, \u017ce wi\u0119kszo\u015b\u0107 z nich skupia si\u0119 bardziej na implementacji kodu, ni\u017c pisaniu test\u00f3w. Jest to r\u00f3wnie\u017c dyskusyjny temat<\/strong> zwi\u0105zany z definicj\u0105 uko\u0144czenia, z podej\u015bciem projektowym oraz zespo\u0142owym.<\/p>\n\n\n\nMoim zdaniem pisanie test\u00f3w komponent\u00f3w to idealne zadanie dla testera, kt\u00f3ry chce rozpocz\u0105\u0107 swoj\u0105 przygod\u0119 z testami automatycznymi, poniewa\u017c s\u0105 one \u0142atwe w przygotowaniu i utrzymaniu, a ich wyniki s\u0105 bardzo czytelne, rzetelne i transparentne<\/strong>.<\/p>\n\n\n\nTesty komponent\u00f3w w praktyce<\/strong><\/h2>\n\n\n\nPrzedstawi\u0119 i om\u00f3wi\u0119 dwa podej\u015bcia \u2013 stary i nowy spos\u00f3b tworzenia test\u00f3w komponent\u00f3w wraz z ich implementacj\u0105 w j\u0119zyku JavaScript z wykorzystaniem Cypressa.<\/p>\n\n\n\n
Old-fashion way<\/strong><\/h3>\n\n\n\nStare podej\u015bcie \u2013 spotykane nie tylko w Cypressie, ale r\u00f3wnie\u017c w innych frameworkach testowych, gdzie nie mamy obecnie mo\u017cliwo\u015bci wy\u015bwietlania komponent\u00f3w. Znaj\u0105c ograniczenia, postarajmy si\u0119 to zaimplementowa\u0107.<\/p>\n\n\n\n
Chcemy, aby test sprawdzi\u0142, czy przycisk \u201eClick me\u201d na stronie spe\u0142nia oczekiwania. Weryfikujemy to na naszej uruchomionej lokalnej wersji tworzonego oprogramowania pod adresem http:\/\/localhost:4200\/<\/a>:<\/p>\n\n\n\n<\/a>Ryc. 3 Weryfikacja dzia\u0142ania przycisku \u201eClick me\u201d<\/figcaption><\/figure>\n\n\n\nTworzymy przypadki testowe i sprawdzamy, czy to dzia\u0142a:<\/p>\n\n\n\n
\n- Sprawd\u017a, czy przycisk ma napis \u201eClick me\u201d.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk ma czerwony kolor t\u0142a.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk wy\u015bwietla poprawnie text 1!2#45.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk wy\u015bwietla poprawnie zmieniony kolor na niebieski.<\/li>\n<\/ol>\n\n\n\n
<\/a><\/figure>\n\n\n\nPrzedstawiony kod wygl\u0105da schludnie i czytelnie. Przy zastosowaniu wzorca projektowego Page-Object i wyciagni\u0119ciu do zmiennych powtarzaj\u0105cych si\u0119 element\u00f3w, mo\u017cemy uzyska\u0107 jeszcze bardziej przejrzysty kod. Jego wad\u0105 niew\u0105tpliwie jest czas wykonywania, kt\u00f3ry przy czterech testach wynosi tylko, albo a\u017c, 809ms.<\/p>\n\n\n\n
Musimy zwr\u00f3ci\u0107 uwag\u0119 na to, \u017ce do przycisku dostajemy si\u0119 natychmiast po za\u0142adowaniu \u201elocalhosta\u201d. Nie wymaga on \u017cadnej dodatkowe interakcji, co przy czterech przypadkach testowych pozwala nam osi\u0105gn\u0105\u0107 akceptowalny czas. Jednak\u017ce bardziej skomplikowane jest wyodr\u0119bnienie poszczeg\u00f3lnych element\u00f3w. Przyk\u0142adowo \u2013 edycji u\u017cytkownika z trzeciej strony formularza, aby dotrze\u0107 do przycisku reset, kt\u00f3ry jednak pojawia si\u0119 dopiero po dokonaniu edycji dowolnego pola.<\/p>\n\n\n\n
I nagle test wygl\u0105da tak:<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nW takim przypadku istnieje zagro\u017cenie, \u017ce stracimy sporo czasu na pozyskanie tego elementu, co mo\u017ce prowadzi\u0107 do znacznego wzrostu kodu oraz uzale\u017cnienia od innych serwis\u00f3w.<\/p>\n\n\n\n
Co by si\u0119 sta\u0142o, gdyby\u015bmy sprawdzili przycisk na \u201eprodukcyjnym\u201d serwerze? Wykonanie tych czterech test\u00f3w zaj\u0119\u0142o mi 12 sekund.<\/p>\n\n\n\n
Co mo\u017cemy zrobi\u0107, aby nasz test by\u0142 lepszy i szybszy?<\/strong><\/h2>\n\n\n\nCo warto uwzgl\u0119dni\u0107, by testy by\u0142y bardziej efektywne:<\/p>\n\n\n\n
\n- Je\u017celi mamy StoryBooka lub inne podobne narz\u0119dzie, napiszmy testy w tym narz\u0119dziu. Mo\u017cemy napotka\u0107 nieprzyjemno\u015bci z Iframe, jednak ich skala jest drastycznie mniejsza do czasu uruchomienia tych test\u00f3w. Ponadto s\u0105 one bardzo zbli\u017cone do samych test\u00f3w komponent\u00f3w.<\/li>\n\n\n\n
- Po\u0142\u0105czmy wszystkie asercje w jednym te\u015bcie, korzystaj\u0105c z tzw. Soft asercji (asercja, kt\u00f3ra w monecie wyst\u0105pienia nie przerywa testu), aby zaoszcz\u0119dzi\u0107 czas podczas odwiedzania strony lub elementu. Pomys\u0142 ten mo\u017ce by\u0107 korzystny, zw\u0142aszcza z odpowiednim reporterem, co mo\u017ce naprawd\u0119 zaowocowa\u0107. (Jest to potencjalny antywzorzec, poniewa\u017c test powinien sk\u0142ada\u0107 si\u0119 z jednej asercji, ale… to temat na osobny wpis). Uda\u0142o mi si\u0119 uzyska\u0107 czas 358 ms.<\/li>\n\n\n\n
- Nie od\u015bwie\u017cajmy strony i wykonajmy asercje w osobnych testach (antywzorzec, poniewa\u017c testy s\u0105 zale\u017cne od siebie). Czas: 278 ms.<\/li>\n\n\n\n
- Wykorzystajmy testy komponent\u00f3w dostarczone od Cypressa z wykorzystaniem metody cy.mount()!<\/li>\n<\/ol>\n\n\n\n
<\/a><\/figure>\n\n\n\nDzi\u0119ki tej metodzie mamy mo\u017cliwo\u015b\u0107 wygenerowania komponentu pojedynczo poprzez jego import i przekazanie go do metody mount(). Oszcz\u0119dzamy czas na pisanie i egzekucj\u0119, nasz kod jest przejrzysty, a testy wiarygodne. Czas, jaki otrzyma\u0142em, to 162 ms! Czyli najlepszy jak do tej pory.<\/p>\n\n\n\n<\/a>Ryc. 4 Testy komponent\u00f3w<\/figcaption><\/figure>\n\n\n\nJe\u015bli nie Cypress, to co?<\/strong><\/h2>\n\n\n\nTestowanie komponent\u00f3w nie ogranicza si\u0119 jedynie do narz\u0119dzia Cypress. Istnieje szereg alternatywnych narz\u0119dzi, takich jak:<\/p>\n\n\n\n
\n- Jest,<\/li>\n\n\n\n
- Enzyme,<\/li>\n\n\n\n
- Vue Test Utils,<\/li>\n<\/ul>\n\n\n\n
kt\u00f3re r\u00f3wnie\u017c mog\u0105 by\u0107 skutecznie u\u017cywane do tej praktyki.<\/p>\n\n\n\n
Te r\u00f3\u017cnorodne opcje pozwalaj\u0105 deweloperom na dostosowywanie narz\u0119dzi do konkretnych potrzeb projektu, co staje si\u0119 szczeg\u00f3lnie istotne w sytuacjach, gdy Cypress, z r\u00f3\u017cnych powod\u00f3w, nie spe\u0142nia oczekiwa\u0144.<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Wi\u0119cej o Cypress dowiesz si\u0119 z innych artyku\u0142\u00f3w naszych ekspert\u00f3w<\/a>. <\/p>\n\n\n
Ale po co nam w\u0142a\u015bciwie testy komponent\u00f3w?<\/strong><\/h2>\n\n\n\nAby odpowiedzie\u0107 na to pytanie, zapoznamy si\u0119 z potrzeb\u0105 oraz istot\u0105 test\u00f3w automatycznych<\/strong>.<\/p>\n\n\n\nTest automatyczny to cz\u0119\u015b\u0107 procesu, w kt\u00f3rym sprawdzamy scenariusze testowe za pomoc\u0105 narz\u0119dzi do automatyzacji lub skrypt\u00f3w. Wa\u017cne jest jednak pami\u0119tanie o podstawach testowania, poniewa\u017c s\u0105 one kluczowe przy tworzeniu przypadk\u00f3w testowych.<\/p>\n\n\n\n
W moim przekonaniu, dobry test automatyczny powinien sk\u0142ada\u0107 si\u0119 z trzech element\u00f3w:<\/p>\n\n\n\n
\n- danych testowych,<\/li>\n\n\n\n
- krok\u00f3w,<\/li>\n\n\n\n
- jednej asercji.<\/li>\n<\/ol>\n\n\n\n
Stawiaj\u0105c to ostatnie jako istotne kryterium, poruszam do\u015b\u0107 kontrowersyjny temat<\/strong>. Test, kt\u00f3ry sprawdza wiele rzeczy \u2013 moim zdaniem \u2013 jest niezbyt wiarygodny, trudny w utrzymaniu i weryfikacji.<\/p>\n\n\n\nPrzyjrzyjmy si\u0119 sytuacji<\/strong>, gdzie chcemy napisa\u0107 test, kt\u00f3ry wysy\u0142a formularz rejestracji u\u017cytkownika. Wype\u0142niamy wszystkie pola i klikamy przycisk \u201ewy\u015blij\u201d za pomoc\u0105 cy.contains(„wy\u015blij”). Pojawia si\u0119 jednak pytanie \u2013 co si\u0119 stanie, je\u015bli nasz przycisk ma inny tekst, na przyk\u0142ad z powodu problem\u00f3w z wy\u015bwietlaniem polskich znak\u00f3w? Otrzymujemy wynik negatywny w te\u015bcie, kt\u00f3ry tworzy u\u017cytkownika, pomimo \u017ce ci\u0105g znak\u00f3w (popularnie nazywany stringiem), po kt\u00f3rym szukamy przycisku, jest inny.<\/p>\n\n\n\nCo mo\u017cemy zrobi\u0107 w tej sytuacji?<\/strong> Napisa\u0107 lepszy test! Mo\u017cemy u\u017cy\u0107 metody cy.get() i poda\u0107 tutaj nasz unikalny identyfikator (cy-data lokator). Ten spos\u00f3b eliminuje konieczno\u015b\u0107 wyszukiwania element\u00f3w po konkretnym ci\u0105gu znak\u00f3w i odnosi si\u0119 do lokatora. Jednak\u017ce, zdarza si\u0119, \u017ce korzystamy z metody cy.contains(), poniewa\u017c jest to bardziej wygodne i efektywne, ni\u017c w przypadku u\u017cycia metody cy.get().<\/p>\n\n\n\nCo jednak, je\u015bli mieliby\u015bmy test komponentu<\/strong>, kt\u00f3ry generuje ten element z oczekiwanym ci\u0105giem znak\u00f3w, sprawdzaj\u0105c jednocze\u015bnie jego tekst, zachowanie i style CSS?<\/p>\n\n\n\nNasze narz\u0119dzie do ci\u0105g\u0142ej integracji nie pozwoli\u0142oby na uruchomienie kolejnych test\u00f3w bez naprawy tego, co daje wynik negatywny. Dzi\u0119ki wczesnemu wykryciu b\u0142\u0119du, mo\u017cemy szybko i tanio go naprawi\u0107. Dodatkowo, dzi\u0119ki temu unikniemy fa\u0142szywie negatywnych wynik\u00f3w<\/strong> w pozosta\u0142ych testach, gdzie to w\u0142a\u015bnie komponent jest winny, a nie logika samego kodu.<\/p>\n\n\n\nTesty komponent\u00f3w a piramida test\u00f3w<\/strong><\/h2>\n\n\n\nPiramida test\u00f3w jest to \u201ewzorzec projektowy\u201d, kt\u00f3ry przedstawia nam kolejno\u015b\u0107 test\u00f3w oraz ich ilo\u015bci. Zgodnie z og\u00f3lnie przyj\u0119t\u0105 norm\u0105, dzieli si\u0119 ona na trzy poziomy. S\u0105 one u\u0142o\u017cone jeden na drugim, w kolejno\u015bci wzgl\u0119dem kosztu stworzenia\/utrzymania, czy te\u017c samego czasu wykonania.<\/p>\n\n\n\n<\/a>Ryc. 1 Piramida test\u00f3w przedstawiaj\u0105ca 3 g\u0142\u00f3wne poziomy test\u00f3w<\/figcaption><\/figure>\n\n\n\nUnit testy<\/strong><\/h3>\n\n\n\nUnit testy czyli testy jednostkowe \u2013 w wi\u0119kszo\u015bci przypadk\u00f3w pisane przez developer\u00f3w. Maj\u0105 one za zadanie sprawdzi\u0107 metod\u0119\/funkcj\u0119\/modu\u0142 na poziomie jednostkowym. Powinny mie\u0107 jak najwi\u0119ksze, realne pokrycie kodu.<\/p>\n\n\n\n
Przedstawia si\u0119 je jako podstaw\u0119\/fundament piramidy test\u00f3w, poniewa\u017c s\u0105:<\/p>\n\n\n\n
\n- niezale\u017cne od zewn\u0119trznych serwis\u00f3w,<\/li>\n\n\n\n
- niezwykle szybkie do napisania i wykonania,<\/li>\n\n\n\n
- tanie w utrzymaniu i tworzeniu,<\/li>\n<\/ul>\n\n\n\n
Ponadto, mog\u0105 te\u017c by\u0107 traktowane jako swojego rodzaju dokumentacja projektowa.<\/p>\n\n\n\n
Testy integracyjne<\/strong><\/h3>\n\n\n\nNa kolejnym poziomie znajduj\u0105 si\u0119 testy integracyjne, w kt\u00f3rych sk\u0142ad wchodz\u0105 testy:<\/p>\n\n\n\n
\n- systemowe,<\/li>\n\n\n\n
- integracyjne.<\/li>\n<\/ul>\n\n\n\n
Sprawdzaj\u0105 one, czy poszczeg\u00f3lne modu\u0142y ze sob\u0105 rozmawiaj\u0105 \u2013 zar\u00f3wno z danymi testowymi, jak i realnymi. Pisane i wykonywane s\u0105 g\u0142\u00f3wnie przez tester\u00f3w, ale to te\u017c zale\u017cy od ustale\u0144 w danym zespole oraz od podej\u015bcia projektowego. Mog\u0105 by\u0107 uzale\u017cnione od zewn\u0119trznych serwis\u00f3w, w zale\u017cno\u015bci od skomplikowania, jednak s\u0105 zdecydowanie ta\u0144sze oraz szybsze od test\u00f3w E2E.<\/p>\n\n\n\n
Testy End-to-End<\/strong><\/h3>\n\n\n\nTesty E2E sprawdzaj\u0105 \u015bcie\u017cki biznesowe, zaczynaj\u0105c od stworzenia u\u017cytkownika, poprzez zakup przedmiotu w sklepie internetowym. Jednak posiadaj\u0105 nast\u0119puj\u0105ce wady:<\/p>\n\n\n\n
\n- s\u0105 niestabilne,<\/li>\n\n\n\n
- s\u0105 bardzo drogie w tworzeniu i utrzymaniu,<\/li>\n\n\n\n
- pokrywaj\u0105 znikom\u0105 cz\u0119\u015b\u0107 kodu,<\/li>\n\n\n\n
- czas wykonania tych test\u00f3w jest du\u017co d\u0142u\u017cszy ni\u017c test\u00f3w jednostkowych, czy te\u017c integracyjnych.<\/li>\n<\/ul>\n\n\n\n
A gdzie s\u0105 testy komponent\u00f3w w piramidzie test\u00f3w?<\/strong><\/h3>\n\n\n\nPo tym, co przeczytali\u015bcie o samych testach komponent\u00f3w, jak i piramidzie test\u00f3w, mo\u017cecie wydedukowa\u0107, \u017ce testy komponent\u00f3w znajduj\u0105 si\u0119 pomi\u0119dzy warstw\u0105 jednostkow\u0105 a integracyjn\u0105. I dok\u0142adnie w tym miejscu ja je umieszczam.<\/p>\n\n\n\n<\/a>Ryc. 2 Piramida test\u00f3w z umiejscowieniem test\u00f3w komponent\u00f3w<\/figcaption><\/figure>\n\n\n\nKto powinien pisa\u0107\/tworzy\u0107 testy komponent\u00f3w?<\/strong><\/h2>\n\n\n\nPowstaje pytanie o to, kto powinien tworzy\u0107 testy komponent\u00f3w. Sytuacja jest podobna, jak w przypadku test\u00f3w jednostkowych. \u0179r\u00f3d\u0142a internetowe twierdz\u0105, \u017ce za testy komponent\u00f3w odpowiedzialni si\u0105 deweloperzy, jednak z do\u015bwiadczenia wiem, \u017ce wi\u0119kszo\u015b\u0107 z nich skupia si\u0119 bardziej na implementacji kodu, ni\u017c pisaniu test\u00f3w. Jest to r\u00f3wnie\u017c dyskusyjny temat<\/strong> zwi\u0105zany z definicj\u0105 uko\u0144czenia, z podej\u015bciem projektowym oraz zespo\u0142owym.<\/p>\n\n\n\nMoim zdaniem pisanie test\u00f3w komponent\u00f3w to idealne zadanie dla testera, kt\u00f3ry chce rozpocz\u0105\u0107 swoj\u0105 przygod\u0119 z testami automatycznymi, poniewa\u017c s\u0105 one \u0142atwe w przygotowaniu i utrzymaniu, a ich wyniki s\u0105 bardzo czytelne, rzetelne i transparentne<\/strong>.<\/p>\n\n\n\nTesty komponent\u00f3w w praktyce<\/strong><\/h2>\n\n\n\nPrzedstawi\u0119 i om\u00f3wi\u0119 dwa podej\u015bcia \u2013 stary i nowy spos\u00f3b tworzenia test\u00f3w komponent\u00f3w wraz z ich implementacj\u0105 w j\u0119zyku JavaScript z wykorzystaniem Cypressa.<\/p>\n\n\n\n
Old-fashion way<\/strong><\/h3>\n\n\n\nStare podej\u015bcie \u2013 spotykane nie tylko w Cypressie, ale r\u00f3wnie\u017c w innych frameworkach testowych, gdzie nie mamy obecnie mo\u017cliwo\u015bci wy\u015bwietlania komponent\u00f3w. Znaj\u0105c ograniczenia, postarajmy si\u0119 to zaimplementowa\u0107.<\/p>\n\n\n\n
Chcemy, aby test sprawdzi\u0142, czy przycisk \u201eClick me\u201d na stronie spe\u0142nia oczekiwania. Weryfikujemy to na naszej uruchomionej lokalnej wersji tworzonego oprogramowania pod adresem http:\/\/localhost:4200\/<\/a>:<\/p>\n\n\n\n<\/a>Ryc. 3 Weryfikacja dzia\u0142ania przycisku \u201eClick me\u201d<\/figcaption><\/figure>\n\n\n\nTworzymy przypadki testowe i sprawdzamy, czy to dzia\u0142a:<\/p>\n\n\n\n
\n- Sprawd\u017a, czy przycisk ma napis \u201eClick me\u201d.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk ma czerwony kolor t\u0142a.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk wy\u015bwietla poprawnie text 1!2#45.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk wy\u015bwietla poprawnie zmieniony kolor na niebieski.<\/li>\n<\/ol>\n\n\n\n
<\/a><\/figure>\n\n\n\nPrzedstawiony kod wygl\u0105da schludnie i czytelnie. Przy zastosowaniu wzorca projektowego Page-Object i wyciagni\u0119ciu do zmiennych powtarzaj\u0105cych si\u0119 element\u00f3w, mo\u017cemy uzyska\u0107 jeszcze bardziej przejrzysty kod. Jego wad\u0105 niew\u0105tpliwie jest czas wykonywania, kt\u00f3ry przy czterech testach wynosi tylko, albo a\u017c, 809ms.<\/p>\n\n\n\n
Musimy zwr\u00f3ci\u0107 uwag\u0119 na to, \u017ce do przycisku dostajemy si\u0119 natychmiast po za\u0142adowaniu \u201elocalhosta\u201d. Nie wymaga on \u017cadnej dodatkowe interakcji, co przy czterech przypadkach testowych pozwala nam osi\u0105gn\u0105\u0107 akceptowalny czas. Jednak\u017ce bardziej skomplikowane jest wyodr\u0119bnienie poszczeg\u00f3lnych element\u00f3w. Przyk\u0142adowo \u2013 edycji u\u017cytkownika z trzeciej strony formularza, aby dotrze\u0107 do przycisku reset, kt\u00f3ry jednak pojawia si\u0119 dopiero po dokonaniu edycji dowolnego pola.<\/p>\n\n\n\n
I nagle test wygl\u0105da tak:<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nW takim przypadku istnieje zagro\u017cenie, \u017ce stracimy sporo czasu na pozyskanie tego elementu, co mo\u017ce prowadzi\u0107 do znacznego wzrostu kodu oraz uzale\u017cnienia od innych serwis\u00f3w.<\/p>\n\n\n\n
Co by si\u0119 sta\u0142o, gdyby\u015bmy sprawdzili przycisk na \u201eprodukcyjnym\u201d serwerze? Wykonanie tych czterech test\u00f3w zaj\u0119\u0142o mi 12 sekund.<\/p>\n\n\n\n
Co mo\u017cemy zrobi\u0107, aby nasz test by\u0142 lepszy i szybszy?<\/strong><\/h2>\n\n\n\nCo warto uwzgl\u0119dni\u0107, by testy by\u0142y bardziej efektywne:<\/p>\n\n\n\n
\n- Je\u017celi mamy StoryBooka lub inne podobne narz\u0119dzie, napiszmy testy w tym narz\u0119dziu. Mo\u017cemy napotka\u0107 nieprzyjemno\u015bci z Iframe, jednak ich skala jest drastycznie mniejsza do czasu uruchomienia tych test\u00f3w. Ponadto s\u0105 one bardzo zbli\u017cone do samych test\u00f3w komponent\u00f3w.<\/li>\n\n\n\n
- Po\u0142\u0105czmy wszystkie asercje w jednym te\u015bcie, korzystaj\u0105c z tzw. Soft asercji (asercja, kt\u00f3ra w monecie wyst\u0105pienia nie przerywa testu), aby zaoszcz\u0119dzi\u0107 czas podczas odwiedzania strony lub elementu. Pomys\u0142 ten mo\u017ce by\u0107 korzystny, zw\u0142aszcza z odpowiednim reporterem, co mo\u017ce naprawd\u0119 zaowocowa\u0107. (Jest to potencjalny antywzorzec, poniewa\u017c test powinien sk\u0142ada\u0107 si\u0119 z jednej asercji, ale… to temat na osobny wpis). Uda\u0142o mi si\u0119 uzyska\u0107 czas 358 ms.<\/li>\n\n\n\n
- Nie od\u015bwie\u017cajmy strony i wykonajmy asercje w osobnych testach (antywzorzec, poniewa\u017c testy s\u0105 zale\u017cne od siebie). Czas: 278 ms.<\/li>\n\n\n\n
- Wykorzystajmy testy komponent\u00f3w dostarczone od Cypressa z wykorzystaniem metody cy.mount()!<\/li>\n<\/ol>\n\n\n\n
<\/a><\/figure>\n\n\n\nDzi\u0119ki tej metodzie mamy mo\u017cliwo\u015b\u0107 wygenerowania komponentu pojedynczo poprzez jego import i przekazanie go do metody mount(). Oszcz\u0119dzamy czas na pisanie i egzekucj\u0119, nasz kod jest przejrzysty, a testy wiarygodne. Czas, jaki otrzyma\u0142em, to 162 ms! Czyli najlepszy jak do tej pory.<\/p>\n\n\n\n<\/a>Ryc. 4 Testy komponent\u00f3w<\/figcaption><\/figure>\n\n\n\nJe\u015bli nie Cypress, to co?<\/strong><\/h2>\n\n\n\nTestowanie komponent\u00f3w nie ogranicza si\u0119 jedynie do narz\u0119dzia Cypress. Istnieje szereg alternatywnych narz\u0119dzi, takich jak:<\/p>\n\n\n\n
\n- Jest,<\/li>\n\n\n\n
- Enzyme,<\/li>\n\n\n\n
- Vue Test Utils,<\/li>\n<\/ul>\n\n\n\n
kt\u00f3re r\u00f3wnie\u017c mog\u0105 by\u0107 skutecznie u\u017cywane do tej praktyki.<\/p>\n\n\n\n
Te r\u00f3\u017cnorodne opcje pozwalaj\u0105 deweloperom na dostosowywanie narz\u0119dzi do konkretnych potrzeb projektu, co staje si\u0119 szczeg\u00f3lnie istotne w sytuacjach, gdy Cypress, z r\u00f3\u017cnych powod\u00f3w, nie spe\u0142nia oczekiwa\u0144.<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Wi\u0119cej o Cypress dowiesz si\u0119 z innych artyku\u0142\u00f3w naszych ekspert\u00f3w<\/a>. <\/p>\n\n\n
Test automatyczny to cz\u0119\u015b\u0107 procesu, w kt\u00f3rym sprawdzamy scenariusze testowe za pomoc\u0105 narz\u0119dzi do automatyzacji lub skrypt\u00f3w. Wa\u017cne jest jednak pami\u0119tanie o podstawach testowania, poniewa\u017c s\u0105 one kluczowe przy tworzeniu przypadk\u00f3w testowych.<\/p>\n\n\n\n
W moim przekonaniu, dobry test automatyczny powinien sk\u0142ada\u0107 si\u0119 z trzech element\u00f3w:<\/p>\n\n\n\n
- \n
- danych testowych,<\/li>\n\n\n\n
- krok\u00f3w,<\/li>\n\n\n\n
- jednej asercji.<\/li>\n<\/ol>\n\n\n\n
Stawiaj\u0105c to ostatnie jako istotne kryterium, poruszam do\u015b\u0107 kontrowersyjny temat<\/strong>. Test, kt\u00f3ry sprawdza wiele rzeczy \u2013 moim zdaniem \u2013 jest niezbyt wiarygodny, trudny w utrzymaniu i weryfikacji.<\/p>\n\n\n\n
Przyjrzyjmy si\u0119 sytuacji<\/strong>, gdzie chcemy napisa\u0107 test, kt\u00f3ry wysy\u0142a formularz rejestracji u\u017cytkownika. Wype\u0142niamy wszystkie pola i klikamy przycisk \u201ewy\u015blij\u201d za pomoc\u0105 cy.contains(„wy\u015blij”). Pojawia si\u0119 jednak pytanie \u2013 co si\u0119 stanie, je\u015bli nasz przycisk ma inny tekst, na przyk\u0142ad z powodu problem\u00f3w z wy\u015bwietlaniem polskich znak\u00f3w? Otrzymujemy wynik negatywny w te\u015bcie, kt\u00f3ry tworzy u\u017cytkownika, pomimo \u017ce ci\u0105g znak\u00f3w (popularnie nazywany stringiem), po kt\u00f3rym szukamy przycisku, jest inny.<\/p>\n\n\n\n
Co mo\u017cemy zrobi\u0107 w tej sytuacji?<\/strong> Napisa\u0107 lepszy test! Mo\u017cemy u\u017cy\u0107 metody cy.get() i poda\u0107 tutaj nasz unikalny identyfikator (cy-data lokator). Ten spos\u00f3b eliminuje konieczno\u015b\u0107 wyszukiwania element\u00f3w po konkretnym ci\u0105gu znak\u00f3w i odnosi si\u0119 do lokatora. Jednak\u017ce, zdarza si\u0119, \u017ce korzystamy z metody cy.contains(), poniewa\u017c jest to bardziej wygodne i efektywne, ni\u017c w przypadku u\u017cycia metody cy.get().<\/p>\n\n\n\n
Co jednak, je\u015bli mieliby\u015bmy test komponentu<\/strong>, kt\u00f3ry generuje ten element z oczekiwanym ci\u0105giem znak\u00f3w, sprawdzaj\u0105c jednocze\u015bnie jego tekst, zachowanie i style CSS?<\/p>\n\n\n\n
Nasze narz\u0119dzie do ci\u0105g\u0142ej integracji nie pozwoli\u0142oby na uruchomienie kolejnych test\u00f3w bez naprawy tego, co daje wynik negatywny. Dzi\u0119ki wczesnemu wykryciu b\u0142\u0119du, mo\u017cemy szybko i tanio go naprawi\u0107. Dodatkowo, dzi\u0119ki temu unikniemy fa\u0142szywie negatywnych wynik\u00f3w<\/strong> w pozosta\u0142ych testach, gdzie to w\u0142a\u015bnie komponent jest winny, a nie logika samego kodu.<\/p>\n\n\n\n
Testy komponent\u00f3w a piramida test\u00f3w<\/strong><\/h2>\n\n\n\n
Piramida test\u00f3w jest to \u201ewzorzec projektowy\u201d, kt\u00f3ry przedstawia nam kolejno\u015b\u0107 test\u00f3w oraz ich ilo\u015bci. Zgodnie z og\u00f3lnie przyj\u0119t\u0105 norm\u0105, dzieli si\u0119 ona na trzy poziomy. S\u0105 one u\u0142o\u017cone jeden na drugim, w kolejno\u015bci wzgl\u0119dem kosztu stworzenia\/utrzymania, czy te\u017c samego czasu wykonania.<\/p>\n\n\n\n
<\/a>Ryc. 1 Piramida test\u00f3w przedstawiaj\u0105ca 3 g\u0142\u00f3wne poziomy test\u00f3w<\/figcaption><\/figure>\n\n\n\n Unit testy<\/strong><\/h3>\n\n\n\n
Unit testy czyli testy jednostkowe \u2013 w wi\u0119kszo\u015bci przypadk\u00f3w pisane przez developer\u00f3w. Maj\u0105 one za zadanie sprawdzi\u0107 metod\u0119\/funkcj\u0119\/modu\u0142 na poziomie jednostkowym. Powinny mie\u0107 jak najwi\u0119ksze, realne pokrycie kodu.<\/p>\n\n\n\n
Przedstawia si\u0119 je jako podstaw\u0119\/fundament piramidy test\u00f3w, poniewa\u017c s\u0105:<\/p>\n\n\n\n
- \n
- niezale\u017cne od zewn\u0119trznych serwis\u00f3w,<\/li>\n\n\n\n
- niezwykle szybkie do napisania i wykonania,<\/li>\n\n\n\n
- tanie w utrzymaniu i tworzeniu,<\/li>\n<\/ul>\n\n\n\n
Ponadto, mog\u0105 te\u017c by\u0107 traktowane jako swojego rodzaju dokumentacja projektowa.<\/p>\n\n\n\n
Testy integracyjne<\/strong><\/h3>\n\n\n\n
Na kolejnym poziomie znajduj\u0105 si\u0119 testy integracyjne, w kt\u00f3rych sk\u0142ad wchodz\u0105 testy:<\/p>\n\n\n\n
- \n
- systemowe,<\/li>\n\n\n\n
- integracyjne.<\/li>\n<\/ul>\n\n\n\n
Sprawdzaj\u0105 one, czy poszczeg\u00f3lne modu\u0142y ze sob\u0105 rozmawiaj\u0105 \u2013 zar\u00f3wno z danymi testowymi, jak i realnymi. Pisane i wykonywane s\u0105 g\u0142\u00f3wnie przez tester\u00f3w, ale to te\u017c zale\u017cy od ustale\u0144 w danym zespole oraz od podej\u015bcia projektowego. Mog\u0105 by\u0107 uzale\u017cnione od zewn\u0119trznych serwis\u00f3w, w zale\u017cno\u015bci od skomplikowania, jednak s\u0105 zdecydowanie ta\u0144sze oraz szybsze od test\u00f3w E2E.<\/p>\n\n\n\n
Testy End-to-End<\/strong><\/h3>\n\n\n\n
Testy E2E sprawdzaj\u0105 \u015bcie\u017cki biznesowe, zaczynaj\u0105c od stworzenia u\u017cytkownika, poprzez zakup przedmiotu w sklepie internetowym. Jednak posiadaj\u0105 nast\u0119puj\u0105ce wady:<\/p>\n\n\n\n
- \n
- s\u0105 niestabilne,<\/li>\n\n\n\n
- s\u0105 bardzo drogie w tworzeniu i utrzymaniu,<\/li>\n\n\n\n
- pokrywaj\u0105 znikom\u0105 cz\u0119\u015b\u0107 kodu,<\/li>\n\n\n\n
- czas wykonania tych test\u00f3w jest du\u017co d\u0142u\u017cszy ni\u017c test\u00f3w jednostkowych, czy te\u017c integracyjnych.<\/li>\n<\/ul>\n\n\n\n
A gdzie s\u0105 testy komponent\u00f3w w piramidzie test\u00f3w?<\/strong><\/h3>\n\n\n\n
Po tym, co przeczytali\u015bcie o samych testach komponent\u00f3w, jak i piramidzie test\u00f3w, mo\u017cecie wydedukowa\u0107, \u017ce testy komponent\u00f3w znajduj\u0105 si\u0119 pomi\u0119dzy warstw\u0105 jednostkow\u0105 a integracyjn\u0105. I dok\u0142adnie w tym miejscu ja je umieszczam.<\/p>\n\n\n\n
<\/a>Ryc. 2 Piramida test\u00f3w z umiejscowieniem test\u00f3w komponent\u00f3w<\/figcaption><\/figure>\n\n\n\n Kto powinien pisa\u0107\/tworzy\u0107 testy komponent\u00f3w?<\/strong><\/h2>\n\n\n\n
Powstaje pytanie o to, kto powinien tworzy\u0107 testy komponent\u00f3w. Sytuacja jest podobna, jak w przypadku test\u00f3w jednostkowych. \u0179r\u00f3d\u0142a internetowe twierdz\u0105, \u017ce za testy komponent\u00f3w odpowiedzialni si\u0105 deweloperzy, jednak z do\u015bwiadczenia wiem, \u017ce wi\u0119kszo\u015b\u0107 z nich skupia si\u0119 bardziej na implementacji kodu, ni\u017c pisaniu test\u00f3w. Jest to r\u00f3wnie\u017c dyskusyjny temat<\/strong> zwi\u0105zany z definicj\u0105 uko\u0144czenia, z podej\u015bciem projektowym oraz zespo\u0142owym.<\/p>\n\n\n\n
Moim zdaniem pisanie test\u00f3w komponent\u00f3w to idealne zadanie dla testera, kt\u00f3ry chce rozpocz\u0105\u0107 swoj\u0105 przygod\u0119 z testami automatycznymi, poniewa\u017c s\u0105 one \u0142atwe w przygotowaniu i utrzymaniu, a ich wyniki s\u0105 bardzo czytelne, rzetelne i transparentne<\/strong>.<\/p>\n\n\n\n
Testy komponent\u00f3w w praktyce<\/strong><\/h2>\n\n\n\n
Przedstawi\u0119 i om\u00f3wi\u0119 dwa podej\u015bcia \u2013 stary i nowy spos\u00f3b tworzenia test\u00f3w komponent\u00f3w wraz z ich implementacj\u0105 w j\u0119zyku JavaScript z wykorzystaniem Cypressa.<\/p>\n\n\n\n
Old-fashion way<\/strong><\/h3>\n\n\n\n
Stare podej\u015bcie \u2013 spotykane nie tylko w Cypressie, ale r\u00f3wnie\u017c w innych frameworkach testowych, gdzie nie mamy obecnie mo\u017cliwo\u015bci wy\u015bwietlania komponent\u00f3w. Znaj\u0105c ograniczenia, postarajmy si\u0119 to zaimplementowa\u0107.<\/p>\n\n\n\n
Chcemy, aby test sprawdzi\u0142, czy przycisk \u201eClick me\u201d na stronie spe\u0142nia oczekiwania. Weryfikujemy to na naszej uruchomionej lokalnej wersji tworzonego oprogramowania pod adresem http:\/\/localhost:4200\/<\/a>:<\/p>\n\n\n\n
<\/a>Ryc. 3 Weryfikacja dzia\u0142ania przycisku \u201eClick me\u201d<\/figcaption><\/figure>\n\n\n\n Tworzymy przypadki testowe i sprawdzamy, czy to dzia\u0142a:<\/p>\n\n\n\n
- \n
- Sprawd\u017a, czy przycisk ma napis \u201eClick me\u201d.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk ma czerwony kolor t\u0142a.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk wy\u015bwietla poprawnie text 1!2#45.<\/li>\n\n\n\n
- Sprawd\u017a, czy przycisk wy\u015bwietla poprawnie zmieniony kolor na niebieski.<\/li>\n<\/ol>\n\n\n\n<\/a><\/figure>\n\n\n\n
Przedstawiony kod wygl\u0105da schludnie i czytelnie. Przy zastosowaniu wzorca projektowego Page-Object i wyciagni\u0119ciu do zmiennych powtarzaj\u0105cych si\u0119 element\u00f3w, mo\u017cemy uzyska\u0107 jeszcze bardziej przejrzysty kod. Jego wad\u0105 niew\u0105tpliwie jest czas wykonywania, kt\u00f3ry przy czterech testach wynosi tylko, albo a\u017c, 809ms.<\/p>\n\n\n\n
Musimy zwr\u00f3ci\u0107 uwag\u0119 na to, \u017ce do przycisku dostajemy si\u0119 natychmiast po za\u0142adowaniu \u201elocalhosta\u201d. Nie wymaga on \u017cadnej dodatkowe interakcji, co przy czterech przypadkach testowych pozwala nam osi\u0105gn\u0105\u0107 akceptowalny czas. Jednak\u017ce bardziej skomplikowane jest wyodr\u0119bnienie poszczeg\u00f3lnych element\u00f3w. Przyk\u0142adowo \u2013 edycji u\u017cytkownika z trzeciej strony formularza, aby dotrze\u0107 do przycisku reset, kt\u00f3ry jednak pojawia si\u0119 dopiero po dokonaniu edycji dowolnego pola.<\/p>\n\n\n\n
I nagle test wygl\u0105da tak:<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nW takim przypadku istnieje zagro\u017cenie, \u017ce stracimy sporo czasu na pozyskanie tego elementu, co mo\u017ce prowadzi\u0107 do znacznego wzrostu kodu oraz uzale\u017cnienia od innych serwis\u00f3w.<\/p>\n\n\n\n
Co by si\u0119 sta\u0142o, gdyby\u015bmy sprawdzili przycisk na \u201eprodukcyjnym\u201d serwerze? Wykonanie tych czterech test\u00f3w zaj\u0119\u0142o mi 12 sekund.<\/p>\n\n\n\n
Co mo\u017cemy zrobi\u0107, aby nasz test by\u0142 lepszy i szybszy?<\/strong><\/h2>\n\n\n\n
Co warto uwzgl\u0119dni\u0107, by testy by\u0142y bardziej efektywne:<\/p>\n\n\n\n
- \n
- Je\u017celi mamy StoryBooka lub inne podobne narz\u0119dzie, napiszmy testy w tym narz\u0119dziu. Mo\u017cemy napotka\u0107 nieprzyjemno\u015bci z Iframe, jednak ich skala jest drastycznie mniejsza do czasu uruchomienia tych test\u00f3w. Ponadto s\u0105 one bardzo zbli\u017cone do samych test\u00f3w komponent\u00f3w.<\/li>\n\n\n\n
- Po\u0142\u0105czmy wszystkie asercje w jednym te\u015bcie, korzystaj\u0105c z tzw. Soft asercji (asercja, kt\u00f3ra w monecie wyst\u0105pienia nie przerywa testu), aby zaoszcz\u0119dzi\u0107 czas podczas odwiedzania strony lub elementu. Pomys\u0142 ten mo\u017ce by\u0107 korzystny, zw\u0142aszcza z odpowiednim reporterem, co mo\u017ce naprawd\u0119 zaowocowa\u0107. (Jest to potencjalny antywzorzec, poniewa\u017c test powinien sk\u0142ada\u0107 si\u0119 z jednej asercji, ale… to temat na osobny wpis). Uda\u0142o mi si\u0119 uzyska\u0107 czas 358 ms.<\/li>\n\n\n\n
- Nie od\u015bwie\u017cajmy strony i wykonajmy asercje w osobnych testach (antywzorzec, poniewa\u017c testy s\u0105 zale\u017cne od siebie). Czas: 278 ms.<\/li>\n\n\n\n
- Wykorzystajmy testy komponent\u00f3w dostarczone od Cypressa z wykorzystaniem metody cy.mount()!<\/li>\n<\/ol>\n\n\n\n<\/a><\/figure>\n\n\n\n
Dzi\u0119ki tej metodzie mamy mo\u017cliwo\u015b\u0107 wygenerowania komponentu pojedynczo poprzez jego import i przekazanie go do metody mount(). Oszcz\u0119dzamy czas na pisanie i egzekucj\u0119, nasz kod jest przejrzysty, a testy wiarygodne. Czas, jaki otrzyma\u0142em, to 162 ms! Czyli najlepszy jak do tej pory.<\/p>\n\n\n\n
<\/a>Ryc. 4 Testy komponent\u00f3w<\/figcaption><\/figure>\n\n\n\n Je\u015bli nie Cypress, to co?<\/strong><\/h2>\n\n\n\n
Testowanie komponent\u00f3w nie ogranicza si\u0119 jedynie do narz\u0119dzia Cypress. Istnieje szereg alternatywnych narz\u0119dzi, takich jak:<\/p>\n\n\n\n
- \n
- Jest,<\/li>\n\n\n\n
- Enzyme,<\/li>\n\n\n\n
- Vue Test Utils,<\/li>\n<\/ul>\n\n\n\n
kt\u00f3re r\u00f3wnie\u017c mog\u0105 by\u0107 skutecznie u\u017cywane do tej praktyki.<\/p>\n\n\n\n
Te r\u00f3\u017cnorodne opcje pozwalaj\u0105 deweloperom na dostosowywanie narz\u0119dzi do konkretnych potrzeb projektu, co staje si\u0119 szczeg\u00f3lnie istotne w sytuacjach, gdy Cypress, z r\u00f3\u017cnych powod\u00f3w, nie spe\u0142nia oczekiwa\u0144.<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Wi\u0119cej o Cypress dowiesz si\u0119 z innych artyku\u0142\u00f3w naszych ekspert\u00f3w<\/a>. <\/p>\n\n\n