Po krótkiej rozmowie z @kuba-orlik doszliśmy do wniosku, że chcemy zacząć pisać testy frontendu.
Jeśli macie jakieś doświadczenia/dobre praktyki/przemyślenia/techniki/narzędzia to zapraszam do podzielenia się w tym wątku 
- scenariusze w Gerkinie
- Selenium
- testy w Mocca / i coś jeszcze czego nie pamiętam
- wszystko spięte np. na Jenkinsie
Ciekawe jest też narzędzie o nazwie TestCafe
Mocno rekomenduję SonarQube! Zrzuty z mojego obecnego projektu, można to nawet w kliku krokach uruchomić lokalnie.
Jakiej metody to używa do testowania frontu?
Nie wiem ale mierzy dług technologiczny, code smelle etc.
Jeszcze używam Rollbara do zbierania błędów z produkcji.
1 Like
Ostatnio w kontekście przygotowań do awansu sprawdziłem co z tymi testami i w firmie używamy dwóch głównych stacków:
- Karma + Jasmine
- Mocha + Chai
1 Like
Ja z kolei wczoraj otestowałem prosty komponent przy użyciu jest + react-testing-library. Pobawię się tym stackiem w wolnym czasie przez weekend i opiszę to. Zapowiada się ciekawie
1 Like
A do coverage to instabul który dobrze integruje się z mochą.
1 Like
@adrszl Witamy na forum 
Widząc, że masz doświadczenie w temacie testów automatycznych, zapytam prosto z mostu - co polecasz? Z czym się wygodnie pracuje?
Dziękuję i witam również!
Doświadczenie jakieś tam mam, ale niestety nie różnorodne 
miałem raczej narzucone z góry technologie, tak więc jeżeli chodzi o aplikacje desktopowe to pracowałem w Selenium (najpierw wraz z C#, później tylko w Javie), do tego również korzystałem w .Net ze Specflow jeżeli dobrze pamiętam nazwę. Specflow pozwala na pisanie testów w języku naturalnym, a następnie zamienia to na skrypty testowe, co jest fajne, gdy przekazujemy robienie testów kilku innym osobom, które też niekoniecznie znają się na rzeczy. Czy polecam? Pracowało mi się dobrze, więc tak no ale jak wspomniałem nie mam porównania innych technologii “w akcji”, więc mogę nie być wiarygodny. Do tego fajnie mi się pracowało z JUnit.
A jeżeli chodzi o mobilki to używałem Selenium + Appium. Tutaj akurat mogę Appium polecać z ręką na sercu, bo zanim się tym zająłem to robiłem głęboki research, a z samym Appium dobrze mi się pracowało. To tyle ode mnie
1 Like
Tbh te wszystkie narzędzia JSowe (TestCafe, Cypress, Puppeteer, Protractor, Nightmare.js) są do siebie na tyle podobne, że wybór któregokolwiek to jest tak naprawdę kwestia bardziej rzutu kośćmi…
Bardziej mi chodziło o to że TestCafe z tego co rozumiem nie używa WebDrivera.
Żadne z tych narzędzi JSowych nie używa WebDrivera (ani Selenium, ani WebDriverIO)
A Protractor?
1 Like
Sorry, my bad, Protractor ma Selenium pod spodem 
Protractor jest też zresztą dość przywiązany do Angulara, tzn. można z niego korzystać nie mając frontu w Angularze, ale jak dla mnie nie warto
1 Like
Przejrzałem cały wątek 
i moje przemyślenia są takie:
Najpierw trzebaby raczej ustalić co mamy na myśli poprzez ‘Testy frontendu’. 
Moim skromnym zdaniem jest duża różnica między pisaniem testów jednostkowych
w:
- Jest
- Karma + Jasmine
- Mocha + Chai + Sinon
a pisaniem testów E2E w:
- Cypress
- TestCafe
- Protractorze
- Selenium - a tym bardziej dorzucaniu do tego stacku jeszcze Gherkina,
który w przypadku Sealcode wydaje się być mocnym overkillem, niepotrzebną warstwą abstrakcji.
Osobiście nie jestem przekonany czy pchanie się “na początek” w rozwiązania E2E to dobry pomysł.
Testy jednostkowe:
- Łatwiej sie pisze - testujemy jedną rzecz w separacji, dodatkowo do UI można wykorzystać snapshoty*
- Szybciej się pisze - testujemy mały skrawek całości
- Szybciej się odpala - Jest nie odpala przeglądarki (nawet Headless), domyślnie wszystko testowane jest na jsdom.
'* Wiem, że wielu ludzi uważa, że snapshoty to nawet nie są testy, ale ich koszt jest zerowy a kilka razy mi dup**ko uratowały.
Podejście Unity → integracyjne → E2E byłoby też zgodne z piramidą testów (i po prostu xD zdrowym rozsądkiem).
Wspomniano też SonarQube - korzystałem w jednej z firm, spoko, ale to nie ma wiele wspólnego z testami (nic poza coverage?), to jest analiza statyczna kodu.
Wracając jeszcze do TestCafe i Cypress’a to nie tak dawno porównywałem oba narzędzia i największym plusem TestCafe względem Cypressa było wsparcie wielu przeglądarek*.
Z tym, że od lutego tego roku Cypress dostał support Firefox’a i Edge’a:
'* Drugim dużym plusem TestCafe jest możliwość odpalania testów na urządzeniu, na którym nie ma oprogramowania do testów - e.g. odpalasz TestCafe remote na kompie:
testcafe remote tests/test.js --qr-code
W terminalu pokazuje się QR code. Skanujesz telefonem i apka odpala się na telefonie a output z testu masz w konsoli na kompie.
Tutaj więcej szczegółów: Redirecting…
P.S. Pisałem to z perspektywy DEVa, który miałby pisać ww testy.
Jeśli byłby projekt w którym QA miałbym czas na automatyzację to zakładam, że sam wybierałby sobie tool i na pewno nie byłby to Jest
2 Likes