Powrót do strony głównejCypressAnywhere.ioO autorze
Powrót

Znanylekarz.pl - test umówienia wizyty

Testy automatyczne opisane w tym blogu są zorganizowane w następującej formie:

  1. Przypadków testowych wraz z krokami (w uproszczonej formie)
  2. Linku do miejsca w repozytorium kodu, w którym znajduje się implementacja testów automatycznych
Dzięki temu, lektura oraz nauka, będą przyjemniejsze. W każdym momencie możliwe będzie, ściągnięcie skonfigurowanego projektu Cypress na swój komputer oraz uruchomienie testów lokalnie. Będę również dbała o to, aby przykłady były na bieżąco aktualizowane, gdy właściciel testowanej aplikacji, dokona zmiany niekompatybilnej wstecz.

Drugi test na tym blogu...

Podobnie jak w przypadku poprzedniego posta, do testowania wybrałam aplikację, z której korzystałam w przeszłości (maksymalnie 2 razy), ale której wcześniej nie testowałam w żaden sposób. Mój wybór padł na znanylekarz.pl. Posiadam aktywne konto użytkownika i wykorzystałam je do napisania testów.

Przypadek testowy: Funkcjonalność dotycząca procesu umówienia wizyty u specjalisty

  • Krok 1: Jako istniejący użytkownik loguję się do aplikacji
  • Krok 2: Sprawdzam, czy znajduję się na panelu pacjenta
  • Krok 3: Zamykam okno panelu pacjenta
  • Krok 4: Akceptuję pliki cookies
  • Krok 5: Wyszukuję specjalistów: wskazując specjalizację oraz miasto
  • Krok 6: Akceptuję pliki cookies
  • Krok 7: Sprawdzam, czy widzę listę dostępnych specjalistów
  • Krok 8: Wybieram pierwszego specjalistę z listy
  • Krok 9: Akceptuję pliki cookies
  • Krok 10: Wybieram pierwszy, dostępny termin wizyty
  • Krok 11: Zaznaczam brak symptomów choroby
  • Krok 12: Akceptuję regulamin serwisu
  • Krok 13: Wyrażam zgodę na przetwarzanie danych
  • Krok 14: Umów wizytę - krok zakomentowany

Ponieważ pierwszy post zawierający testy, skupiony był tylko na jednej funkcjonalności (logowaniu), tutaj postanowiłam przejść pełen proces, od zalogowania użytkownika do umówienia wizyty. Kod jest dostępny poniżej, więc napiszę kilka słów o przebiegu testów oraz spostrzeżeniach. Część elementów była oznaczona atrubutami - w tym przypadku data-test-id, część tych atrybutów nie posiadała. Przy wykonywaniu testów w Cypressie, korzystałam z przeglądarki Electron oraz Chrome. Warto w tym miejscu wspomnieć, że korzystając z Cypressa, w prawym, górym rogu, mamy możliwość zmiany przeglądarki do testów. Jej zmiany możemy dokonywać dowolnie, bez konieczności ponownego uruchamiania Cypressa w terminalu. Wspominam o tym dlatego, że podczas wykonywania testów, sprawdzałam, jak Cypress zachowa się na więcej niż jednej przeglądarce i podejmowałam decyzję, w przypadku której, testy przebiegają najsprawniej. Wielokrotnie, wybór przeglądarki nie będzie miał większego znaczenia, jednak przy moich testach, zdecydowałam się na przeglądarkę, która testy wykonywała najszybciej. Gdybym miała do wykonania przypadek, który ma np. 2, proste kroki, różnica nie byłaby tak odczuwalna, jak w przypadku powyższych 13 kroków (14 krok jest zakomentowany). Testowanie każdej zmiany, uruchamianie testów wiele razy, to także upływający czas - w tym przypadku Electron wykonywał testy błyskawicznie. Krok nr 14, został zakomentowany, by finalnie nie dokonywać rezerwacji. Ponieważ nie miałam oczywiście dostępu do kodu aplikacji, ale podczas testów zauważyłam coś, co pozytywnie mnie zaskoczyło, napiszę o tym. Mianowicie nastawiona byłam na konieczność napisania kodu pętli, która w przypadku braku wolnego terminu wizyty w kalendarzu widocznym w oknie, na którym przebywam, będzie zmieniała okna (strony kalandarza), aż do momentu znalezienia pierwszego, wolnego terminu. Po testowaniu manualnym, wiedziałam, że zdarzają się specjaliści, których najbliższy, wolny termin, przypada dopiero za 3 miesiące, co w praktyce wiązałoby się z wielokrotnym przeklikiwaniem okna aż do momentu odnalezienia, tej konkretnej karty w kalendarzu. Jednak przy testach, okazało się, że napisana przeze mnie podstawowa funkcja, której zadaniem było znalezienie pierwszego, wolnego terminu, w zupełności wystarczy, gdyż w przypadku konieczności przejścia np. do kolejnego tygodnia, aplikacja przerzuca okna automatycznie do momentu wolnego terminu. Developer zatem wziął tę kwestię pod uwagę, pisząc kod, co skróciło czas pracy nad moim kodem testów.

Kod tego testu znajduje się pod tym adresem Kod testu procesu umówienia wizyty u specjalisty

Podsumowując jednocześnie pierwsze testy z poprzedniego posta, jak i powyższe, warto wspomnieć, że inaczej wyglądałaby moja praca nad testami, gdyby odbywała się w realnym teamie pracującym nad daną aplikacją/sklepem. Przy tworzeniu projektu, byłabym w stałym kontakcie z resztą zespołu, czyli także z developerami. Projektując moje testy, zależnie od tego, czy miałabym dostęp do kodu aplikacji, czy nie - mogłabym samodzielnie nadawać atrybuty elementom lub prosić o ich nadanie, developerów. W sytuacji, gdy testuję istniejące i dostępne powszechnie aplikacje, nie mam takiej możliwości, zatem opieram się na tym, co jest dla mnie dostępne. Testy w takich warunkach, choć utrudnione, na pewno uczą mnie poszukiwania, dociekania, analizowania oraz oswajają z istnieniem zarówno złych, jak i dobrych praktyk. Kiedy poznamy jedne i drugie, nie będziemy zaskoczeni trafiając do projektu, w którym w kodzie zabrakło dobrych praktyk. Co więcej, będziemy mogli zaproponować, pozytywne zmiany.