Czy każdy test (np. loginTest, registerTest) to powinien być oddzielny plik? Czy może lepszym wyjściem jest stworzenie pliku testLandingPage w którym umieszczonych będzie kilka testów (logowania, przechodzenia do podstron itp.)?
Jeszcze dodatkowe pytanie jaką stosujecie konwencję nazewnictwa przy nadawaniu nazw plikom testowym? testDupa a może test_dupa?
@Melisandre: To zależy od przyjętych konwencji ale nie jest to jakieś mega ważne. Pierwsza opcja - cammel case popularniejsza i stosowana np. w Javie, druga za to w Pythonie (zgodna z PEP8).
@Melisandre: Konwencja nazewnictwa to kwestia umowna (chyba, że framework wymusza nazewnictwo), jak pracujesz w zespole to sobie to dogadajcie, jak sama to rób jak chcesz.
Podział najlepiej robić tak by mieć testy pogrupowane w jakiś sposób. Czy to klasy, czy klasy i pakiety/moduły to zależy od testowanej aplikacji, rozmiaru projektu, frameworka, języka itd.
Ja osobiście przy dosyć dużym projekcie (kilka tysięcy testów) w ScalaTest preferuję strukturę 3-poziomową *: 1. Pakiet zawierający
@QualityAssurance: tak, dokładnie tak mam zrobione. Mam teraz mętlik w głowie, bo mam landingPage. Testuję fakt, czy w ogóle przechodzę do landing page, kolejno chcę przetestować logowanie. I teraz nie wiem, to jest oddzielna funkcjonalność, więc powinnam utworzyć nowy plik z testem, ale przycisk logowania znajduje się na landingPage, więc też po części do niego należy. I nie wiem czy to rozdzielić czy nie, ale chyba tak.
@Melisandre: W takich przypadkach zawsze warto zrobić jakiś bardziej obszerny test niż samo załadowanie stronu. Np. wejście na landingPage i sprawdzenie czy jakieś najważniejsze elementy się wyświetlają, wtedy masz jedną akcje plus ileś tam asercji. A w teście na logowanie powtarzasz tylko samą akcję wejścia na landingPage już bez sprawdzania co się wyświetla. Dzięki temu jak coś na landingPage się wywali to dostaniesz jasny komunikat w danym konkretnym teście.
@LiczbaPi: Ok, tak zrobię. Super rozświetliło mi to dużo.
@QualityAssurance: Właśnie utworzyłam sobie plik loginLogoutProvider i mam zamiar wrzucić tam logowanie. Słyszałeś coś o handling cookies dzięki któremu nie jest potrzebne każdorazowe logowanie? (Przeczytałam o tym w książce Selenium-WebDriver Practical Guide z Pactu (jak coś to str. 73).
polecam ten framework: http://www.thucydides.info/docs/serenity/ największe zalety: - świetne raporty, które są przejrzyste również dla biznesu - page object pattern - struktura pozwalająca utrzymać porządek i reużywać stepy (unikasz duplikowania kodu)
Czy każdy test (np. loginTest, registerTest) to powinien być oddzielny plik? Czy może lepszym wyjściem jest stworzenie pliku testLandingPage w którym umieszczonych będzie kilka testów (logowania, przechodzenia do podstron itp.)?
Jeszcze dodatkowe pytanie jaką stosujecie konwencję nazewnictwa przy nadawaniu nazw plikom testowym? testDupa a może test_dupa?
@Melisandre: właśnie tak
@Melisandre: To zależy od przyjętych konwencji ale nie jest to jakieś mega ważne. Pierwsza opcja - cammel case popularniejsza i stosowana np. w Javie, druga za to w Pythonie (zgodna z PEP8).
Podział najlepiej robić tak by mieć testy pogrupowane w jakiś sposób. Czy to klasy, czy klasy i pakiety/moduły to zależy od testowanej aplikacji, rozmiaru projektu, frameworka, języka itd.
Ja osobiście przy dosyć dużym projekcie (kilka tysięcy testów) w ScalaTest preferuję strukturę 3-poziomową *:
1. Pakiet zawierający
Komentarz usunięty przez autora
Komentarz usunięty przez autora
@QualityAssurance: Właśnie utworzyłam sobie plik loginLogoutProvider i mam zamiar wrzucić tam logowanie. Słyszałeś coś o handling cookies dzięki któremu nie jest potrzebne każdorazowe logowanie? (Przeczytałam o tym w książce Selenium-WebDriver Practical Guide z Pactu (jak coś to str. 73).
Komentarz usunięty przez autora
Komentarz usunięty przez autora
największe zalety:
- świetne raporty, które są przejrzyste również dla biznesu
- page object pattern
- struktura pozwalająca utrzymać porządek i reużywać stepy (unikasz duplikowania kodu)