Automatyczne testy front-endu

[ad-m]

Mamy szereg zależności od front-endu, które nie są aktualne ( https://github.com/watchdogpolska/poradnia/pulls?q=is%3Apr+is%3Aopen+label%3Ajavascript ). Mamy także nieaktualny stan projektu w repozytorium ( #729 ).

Potrzebujemy:

• powtarzalne, wiarygodnego procesu budowania monolitycznej aplikacji django SPA, z uwzględnieniem bibliotek wymaganych przez rozszerzenia Django,
• testów front-endu, choćby w podstawowym zakresie, abyśmy mogli spokojnie włączać aktualizacje, które mogą dotknąć front-endu.

Zaznaczę także, że mamy także problemy, których nie możemy łatwo rozwiązać tj. w czasie rzeczywistym odświeżenie listów (#518), zachowanie wiadomości po jej poprawnym zapisaniu (#562). W tym zakresie konieczna jest szersza wizja jak do tego podejść.

[bukowa]

Ciekawie wygląda https://github.com/chromedp/chromedp

Np. https://github.com/bukowa/dockerizedapps/blob/master/drone.io/scripts/gitlab-browser/main.go

[ad-m]

Ale wymaga pisania testów w Go, co nie jest zbyt efektywne długoterminowo. W przypadku sterowania przeglądarek albo mamy Selenium + geckodriver itp. z dostosowanymi przeglądarkami rozwiązania lub oparte o implementacje protokołu Chrome Dev Protocol (implementuje go Chrome, częściowo Firefox i Edge). Dla Chrome Dev Protocol istnieje kilka narzędzi, które implementuje protokół, także napisanych w Python ( https://github.com/ChromeDevTools/awesome-chrome-devtools#protocol-driver-libraries ). Czy nie będzie to lepsze rozwiązanie?

[bukowa]

Moim zdaniem nie warto ograniczać się do jednego języka, a wybierać narzędzie które najlepiej robi robote, ma dobre api i jest rozwijane. Sporo oglądałem projektów do automatyzacji przeglądarki i chromedp wygląda dla mnie najlepiej, działa od strzała w Dockerze jest szybciutki i rozwijany. Projekty pythonowe wyglądają kiepsko (przynajmniej jeśli chodzi o API). Selenium też próbowałem i dla mnie odpada, nie wiem czy ma przyszłość jeśli jest Chrome Dev Protocol. Wszystko zależy od osoby która te testy będzie pisała. Jak uważasz?

[ad-m]

Jak ktoś napisze testy w Go, ładnie je zintegruje z projektem, udokumentuje jak je uruchomić to z chęcią taki PR przyjmę w dowolnym języku. Takie testy lepsze niż obecny stan nieprzewidywalnej aktualizacji front-endu.

[bukowa]

Czyli jakie testy to te właściwe?

[ad-m]

W mojej ocenie potrzebujemy mieć flow, aby weryfikować w CI, że poprawki takie jak #724 , #681, #633 zachowują działanie obecnych funkcjonalności w projekcie. Jak również, że poprawnie działają biblioteki front-endu dostarczone przez biblioteki Python np. #796 . Poprawne działanie to znaczy zachowanie walorów wizualnych i funkcjonalnych.

[westscz]

Wydaje mi się, że lepiej byłoby napisać te testy z wykorzystaniem Cypress. Czy są gdzieś spisane podstawowe przypadki użycia?

[ad-m]

Nie zostały udokumentowane, ale mamy niewielką ilość JS, a w tym zakresie szczególnie testy front-endu są wymagane, zatem:

• rejestracja
• logowanie
• zarejestrowanie nowej sprawy z załącznikiem,
• dodanie listu do sprawy,
• wyszukanie sprawy po nazwie w wyszukiwarce z opcji "Wyszukaj" z menu bocznego
• dodanie do listu sprawy z załącznikiem i pomyślne pobranie go

Jeżeli będziemy mieli te scenariusze obsłużone to będzie dobra baza i dość bezpieczny rozwój front-endu.

[AgnieszkaZdanowicz]

@ad-m nie wiem, czy to aktualne?

[rwakulszowa]

Postaram się tym zająć.
Prawdopodobnie Cypress + dedykowany plik docker-compose.test.yml będą najwygodniejszym rozwiązaniem.

@ad-m - jak wygląda sytuacja w kwestii integracji z GitHub actions? Czy jako NGO mamy dostęp do większej ilości zasobów GH? W takiej sytuacji mógłbym też dodać automatyczne wywołanie testów przy każdym PR / commicie do mastera.

[ad-m]

jak wygląda sytuacja w kwestii integracji z GitHub actions? Czy jako NGO mamy dostęp do większej ilości zasobów GH?

Jako NGO żadnych benefitów w tym zakresie, ale jako open-source nie mamy opłat za minuty, więc jak najbardziej integruj.

GitHub Actions usage is free for public repositories and self-hosted runners.
https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions

Mam wątpliwości czy dedykowany docker-compose będzie konieczny.

W zakresie zagadnienia widzę dwa elementy:

• szkielet, aby uruchamiać testy i dwa przykłady,
• pokrycie testami adekwatne do potrzeb (pewnie wymaga to podobnego podejścia jak w Definicja krytycznych funkcjonalności i metod ich weryfikacji feder#860)

[rwakulszowa]

Z punktów wymienionych wyżej, obecnie nie testujemy jeszcze:

• zarejestrowanie nowej sprawy z załącznikiem
• wyszukanie sprawy po nazwie w wyszukiwarce z opcji "Wyszukaj" z menu bocznego
• dodanie do listu sprawy z załącznikiem i pomyślne pobranie go

W kolejnym PR postaram się obsłużyć te 3 przypadki, po czym pewnie będziemy mogli zamknąć tę sprawę, a kolejne testy dodawać już na bieżąco.

Następnie będziemy mogli wdrożyć #913, zaktualizować wszystkie zależności, po czym przejść wreszcie do #889 .