Setup cypress #932
Setup cypress #932
Conversation
| @@ -88,6 +88,12 @@ | |||
| ) | |||
| # END MIDDLEWARE CONFIGURATION | |||
|
|
|||
| # SITE CONFIGURATION | |||
There was a problem hiding this comment.
Przeniesione z production.py.
W trybie development, domyślnie dopuszczone są wartości localhost i pokrewne. Test cypress wymaga dopuszczenia hosta web.
Jako, iż produkcyjna wartość jest już ustawiona na "*", najprostszym rozwiązaniem było użycie tego samego mechanizmu dla środowiska dev.
tests/README.rst
Outdated
|
|
||
| HowTo | ||
| ===== | ||
| Testy najłatwiej wywołać używając pliku docker-compose.test.yml. |
There was a problem hiding this comment.
Zastanawiam się czy dokumentacja takiego rodzaju nie powinna być widoczna (co najmniej) także przez Sphinx, który mamy.
W pełni podzielam podział tego na etapy.
W taki sposób zmierzam w projekcie do testów i jest to spójne, więc popieram.
Odnośnie bezstanowości to wykonywanie testów jest bezstanowe, z perspektywy bazy danych i systemu plików, bo wykorzystujemy testy Django, które tworzą osobną bazę danych dla testów, którą potem usuwają. |
| @@ -0,0 +1,7 @@ | |||
| // The simplest tests, validating that it's possible to render the app at all. | |||
| describe('landing page', () => { | |||
There was a problem hiding this comment.
Jak będziemy provisionować stan aplikacji (faza setup), skoro JavaScript?
There was a problem hiding this comment.
Jeśli mam być szczery, to moje doświadczenie z cypress nie jest duże, ale wiem że istnieje możliwość wywołania dowolnej komendy z użyciem cy.exec. W takiej sytuacji kod testu (najprawdopodobniej) będzie mógł komunikować się bezpośrednio z bazą poprzez dedykowane skrypty.
There was a problem hiding this comment.
Ja także nie mam dużego doświadczenia w testowaniu front-endu, a w zakresie aplikacji Python & testy Javascript nie mam doświadczenia żadnego. Jeżeli będziemy używać cy.exec to pozostanie kwestia odpowiedniego zarządzania tymi skryptami (napisanymi w Pythonie). Dołożyłeś nowy kontener bazujący na cypress, więc wywołanie z niego Pythona nie będzie trywialne.
There was a problem hiding this comment.
Raczej miałem na myśli wywołanie skryptów napisanych też w JS, gadajacych bezpośrednio z bazą danych. Testy byłyby zdefiniowane w tym samym kontenerze co testy.
Generalnie nie spodziewam się, przynajmniej póki co, wywoływania niczego bardziej skomplikowanego niż usunięcie wszystkich danych przed testem, ewentualnie stworzenie możliwości dodania paru kluczowych obiektów. Raczej parę podstawowych, łatwych w utrzymaniu skryptów JS.
There was a problem hiding this comment.
Możemy spróbować, ale rezygnowanie z fabryk, które mamy na back-endzie wywołuje moje obawy w zakresie kosztów rozwoju i utrzymania. Obecnie większość stanu jesteśmy w stanie zrobić jednym wywołaniem fabryki, ewentualnie odpowiednim wywołaniem ORM-a. Uważam to za dużą wartość i ułatwienie w pisaniu testów. Tu proponujesz zejście z tych warstw na najniższy poziom.
Co zdecydowało o wyborze Cypress do testów? Rozważałeś klasyczne Selenium, które mniej modne, ale mogłoby nam zapewnić bliższą integracje z tym co dotychczas mamy ( https://blog.mloza.pl/testy-w-django-z-uzyciem-selenium/ ), albo coś w Pythonie np. Pyppeteer / Splinter?
There was a problem hiding this comment.
Cóż, główny problem z Selenium jest taki, że to bardzo stara technologia, więc o ile byłoby to prostsze w kwestii pisania samych testów (Python), to spodziewałbym się problemów z utrzymaniem, z racji wieku biblioteki.
Wydaje mi się, że problemem tutaj nie jest kwestia użycia Cypress / Selenium, ale kwestia umieszczenia testów w oddzielnym kontenerze. Z cypress mamy dostęp do basha, więc gdyby był w tym samym kontenerze co django, mógłby po prostu wywołać dowolny skrypt py i rozwiązać problem.
Wydaje mi się jednak, że umieszczenie testów integracyjnych w oddzielnym kontenerze ma więcej zalet niż wad. Koniec końców, chcemy by testy były jak najbliższe rzeczywistości, więc komunikacja bezpośrednio z django / bazą powinna być ostatecznością.
Co do samych testów - raczej zakładam, że doprowadzenie aplikacji do konkretnego stanu powinno być częścią samego testu, a nie kodu wykonywanego przed nim, tj.:
- jeśli chcemy testować edycję spraw, w ramach testu powinniśmy wywołać
- logowanie / rejestrację użytkownika
- utworzenie kilku spraw
- aktualizację konkretnej sprawy
To oczywiście zwiększy czas trwania testu, ale wykryje więcej potencjalnych błędów. Nie mamy pewności, czy wywołując ręcznie factory django nie pomijamy czegoś co wydarza się po przeklikaniu w przeglądarce, a to właśnie chcemy przetestować.
Ręczna komunikacja z bazą danych (i ogólnie z bashem) mogłaby ograniczyć się do:
- sprzątania bazy po każdym teście
- ewentualnego ustawienia wartości, których obecnie nie można przeklikać (np. teryt)
- obsługi komunikacji, która w praktyce odbywa się poza przeglądarką (np. email - nie wiem dokładnie jak wygląda implementacja, ale zakładam, że - przynajmniej w jakimś stopniu - można zastąpić emaile bezpośrednią komunikacją z bazą).
Innymi słowy, rzeczami, które nie będą (za bardzo) wymagały znajomości modeli Django.
Ok, w takim razie po prostu dodam kolejny krok do istniejącej definicji. |
|
Dziękuje, wygląda nieźle :) W praktyce sprawdzimy UX podczas pisania testów. |
#741
Szkielet + prosty test renderujący główną stronę. Póki co nie dodawałem żadnych "ciekawych" testów - wolę poświęcić na to oddzielny PR, żeby nie komplikować.
W przeszłości używałem podejścia w którym testy integracyjne startowane są z użyciem docker-compose. Ma to tę zaletę, że jest bardzo proste w obsłudze dla użytkownika, który chce tylko sprawdzić kompatybilność wprowadzonych zmian, bez zmian konfiguracji samych testów (innymi słowy, nie trzeba znać się ani na docker-compose, ani na cypress, żeby wystartować testy).
Jeśli wygląda ok, mogę przy okazji tego PR dodać też integrację z GitHub Actions.
Pytanie czy chcemy mieć testy w ramach istniejącej akcji (web), czy oddzielnej. Prawdopodobnie na dłuższą metę dodanie ich w jeden ciąg miałoby sens, ale obecnie akcja
webzdaje się nie być bezstanowa (dbiwebsą startowane wcześniej i pozostają aktywne do końca trwania akcji, o ile rozumiem), co może odrobinę zakłócać przebieg testów - prawdopodobnie wszystko zadziała, ale możemy nie wykryć, że testy przechodzą jedynie jeślidbzostanie wystartowana parę minut wcześniej, co może być odrobinę zaskakujące.