Zawsze bylem przyzwyczajony do piramidy testow, najwiecej unitowych, potem im wyzej tym mniej. Zmienilem firme. Manager wymaga, zebysmy poswiecali wiekszosc czasu na testy e2e, bo 'to najbardziej interesuje klientow'. Probowalem mu wytlumaczyc, ze glowna zaleta testow jest szybka informacja dla nas. Ale on swoje, mimo, ze testy juz trwaja 45 minut (projekt rozpoczal sie w lutym, ma trwac do grudnia wiec pewnie to dopiero poczatek), Macie jakies argumenty, ze jednak lepiej poswiecic czas na testy jednostkowe, testy API i testy z mockami, bo sa po prostu szybsze?
0
0
A co za różnica że są długie? Chyba nie odpalasz tego i tak ręcznie tylko na jakimś CI?
0
@Shalom: mimo wszystko testy jednostkowe przydają się wtedy gdy pracujesz nad fragmentem kodu i możesz odpalić tylko ten fragment wszystkich testów, który sprawdza, czy nie zepsułeś czegoś małego. Testy e2e oczywiście potem na CI, ale jednostkowe, które możesz szybko i często odpalać też się przydają.
1
Nie no jasne, ja jestem za pisaniem testów jednostkowych jak najbardziej, ale nie widzę sensu w argumentowaniu jedne albo drugie albo jakimś dowodzeniu wyzszości jednych nad drugimi. I te i te są potrzebne, bo sprawdzają inne rzeczy. A już argumentowanie że testy integracyjne czy end to end są złe bo zabierają sporo czasu to jest jakaś farsa ;)
Wiadomo ze dla klienta bardziej wartościowe są testy end to end, szczególnie automatyczne, bo one pokazują że produkt działa w danych scenariuszach
0
Shalom napisał(a):
nie widzę sensu w argumentowaniu
jedne albo drugie
Roboczogodzina to roboczogodzina, im więcej czasu będziesz poświęcał na tworzenie testów funkcjonalnych tym mniej będziesz mógł poświęcić na jednostkowe, a skoro przeciętnie testy jednostkowe tworzy się szybciej to w rezultacie będziesz miał gorzej przetestowany system. Mój menadżer miał właśnie taki genialny pomysł że każda modyfikacja powinna być pokryta testem... W Selenium. Oczywiście testów jednostkowych nie mamy wcale.
3
Nie można przesadzać w żadną stronę ;) Bo same testy jednostkowe bez integracyjnych to się kończą tak:
albo tak:
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure
0
btw zapytaj managera ile lat ma doswiadczenia w programowaniu, jak powie ze malo to zdecyduj ze w takim razie Ty chcesz rzadzic budzetem projektu bo tez sie na tym nie znasz ;)
0
45 minut to nie jest długo. Jak testy się rozrosną, to będziecie na weekend zapuszczać. Moi koledzy co pracują w dużych korpo przy hardwarze tak robią, bo testy faktycznie trwają np. 2 dni. I w poniedziałek pół biedy jak mogą przeczytać raport, najgorzej jak coś w testach się wysypie i przez weekend nie poszły :)
0
MuadibAtrides napisał(a):
45 minut to nie jest długo. Jak testy się rozrosną, to będziecie na weekend zapuszczać. Moi koledzy co pracują w dużych korpo przy hardwarze tak robią, bo testy faktycznie trwają np. 2 dni. I w poniedziałek pół biedy jak mogą przeczytać raport, najgorzej jak coś w testach się wysypie i przez weekend nie poszły :)
Czyli tak, codziennie kilkadziesiat osob doklada swoj kawalek kodu i raz w tygodniu sie dowiaduja, ze ktos cos zepsul? :-)
0
Biały Mleczarz napisał(a):
MuadibAtrides napisał(a):
45 minut to nie jest długo. Jak testy się rozrosną, to będziecie na weekend zapuszczać. Moi koledzy co pracują w dużych korpo przy hardwarze tak robią, bo testy faktycznie trwają np. 2 dni. I w poniedziałek pół biedy jak mogą przeczytać raport, najgorzej jak coś w testach się wysypie i przez weekend nie poszły :)
Czyli tak, codziennie kilkadziesiat osob doklada swoj kawalek kodu i raz w tygodniu sie dowiaduja, ze ktos cos zepsul? :-)
Ja się dowiaduję zwykle po miesiącu albo dwóch więc nie widzę problemu /s
1
Biały Mleczarz napisał(a):
MuadibAtrides napisał(a):
45 minut to nie jest długo. Jak testy się rozrosną, to będziecie na weekend zapuszczać. Moi koledzy co pracują w dużych korpo przy hardwarze tak robią, bo testy faktycznie trwają np. 2 dni. I w poniedziałek pół biedy jak mogą przeczytać raport, najgorzej jak coś w testach się wysypie i przez weekend nie poszły :)
Czyli tak, codziennie kilkadziesiat osob doklada swoj kawalek kodu i raz w tygodniu sie dowiaduja, ze ktos cos zepsul? :-)
Testujesz to lokalnie, twój tester (niezależnie) też, później CI puszcza testy jednostkowe i integracyjne (co po pozytywnym review dopuszcza merge do brancha integracyjnego), w nocy leci pełna suita funkcjonalnych i E2E. Rano w ramach domknięcia historyjki musisz pokazać że regresja jest w takim samym lub lepszym stanie niż przed twoim mergem i że wszystkie nowe testy które zostały dostarczone przechodzą. Czasami rzecz jasna zdarzy się że tak się to czasowo zgra że ktoś kijowo rozwiąże konflikt i wprowadzi błędy, ale one zwykle wychodzą dość ładnie na trendach testów. Testy performance co tydzień w weekend plus po code freeze przed releasem. Takie jest życie z dużym korporacyjnym kawałkiem kodu. Dodam że testy trwają tyle z uwagi na interaktywność (klikanie trwa) i na to że muszą się łączyć z wolnawymi (i czasami niedziałającymi) środowiskami integracyjnymi produktów z których korzysta aplikacja.
0
To, których testów używać zależy od rodzaju projektu. Inaczej testuje się okienka, inaczej obliczenia, a jeszcze inaczej integrację.
0
Istnieje popularne pojęcie piramidy testów[0].
W większości jest to pewien standard w temacie gdzie i jakie testy.
Dużo zależy od samego oprogramowania, które piszecie. Miałem nieprzyjemność testować soft, który można było sprawdzić jedynie klikając po UI - wtedy lipa z piramidą. Na szczęście takie kobyły to rzadkość.
Dziś zwykle pisze się apki webowe korzystając z warstw a często również z mikroserwisów. Wtedy już łaiwiej zaimplementować ładną piramidę testów i włączyć ją CI/CD...
Pozdro
0
Uważam rozróżnienie na testy integracyjne i jednostkowe za generalnie bzdurę/problem.
- Bo co to jest ta mityczna jednostka? Czemu nie można wyjść poziom wyżej w abstrakcji i zmienić "widzianej" jednostki ?
- A dlaczego nie możesz przetestować całego systemu z infrastrukturą e2e tak jakby to był test jednostkowy ? (tu najczęściej odpowiedź jest taka, że mamy zrypaną infrastrukturę i się nie da. W mojej firmie przez "security" niestety tak mam, ale pracujemy nad tym ).
- Najczęściej testy integracyjne/ gui / e2e jakie znam to takie co nie spełniają reguł F.I.R.S.T. ... i są do bani.
Do tej pory poznałem jedną firme która robi testy e2e dobrze. Jednym z kluczowych elementów robienia testów dobrze jest np. odpowiedni timeService.
Tu jeszcze jedna rzecz - testy mają testować przede wszystkim to co się wywala. W GUI webowym najczęściej nam się wywalają CSSy (bo kod w JS/TS jest całkiem spoko pokryty testami jednostkowymi).
A do dobrego testowania poprawności renderowania akurat niczego nie znalazłem przez X lat. Porównywanie screenshotów to bzdura niestety,
2
o_O
A dlaczego nie możesz przetestować całego systemu z infrastrukturą e2e tak jakby to był test jednostkowy
Bo poza hello worldami zwykle liczba ścieżek w aplikacji jest wykładniczo duża. Test integracyjny sprawdza jedną. Sprawdzenie wszystkich jest często po prostu niemożliwe. Poza tym test integracyjny / e2e powie ci najwyżej ze "aplikacja nie działa" czy tam "przypadek użycia X nie działa". Ale nie powie ci co dokładnie nie zadziałało, bo to co sie wywaliło zwykle jest gdzieś dużo poniżej poziomu na którym uruchamiałeś test. Izolowanie pewnych elementów jako "jednostek" pozwala na sprawdzenie większości/wszystkich ścieżek.
1
jarekr000000 napisał(a):
- A dlaczego nie możesz przetestować całego systemu z infrastrukturą e2e tak jakby to był test jednostkowy ?
Przykład testu e2e:
When send request to create user
Then in response I should get HTTP 201 Created
Jak taki test się wyłoży to nie masz zielonego pojęcia co i gdzie się wyłożyło, bo to nie jest rola testu e2e. Dodatkowo taki test jest pieruńsko wymagający, bo wymaga:
- działającej DB
- zmigrowanej DB
- często również zaseedowanej DB
- działającego serwera HTTP
Podczas gdy testy jednostkowe powinny wymagać co najwyżej pierwszych 2, a i tak gdzie się da powinno się tego unikać.
0
Ja robie testy e2e z użyciem Spring Test :)
Co do testów. problem jest taki że trudno testować niektore rzeczy jednostkowo, można sensownie tak przetestować logikę (czyli mockujesz dane z DAO i sprawdzasz czy zostały odpowiednio przetworzone)
1
Nie pisałem żeby testować e2e cały system i wszystkie jego ścieżki.
Możemy cały system przetestować "jednostkowo".
Testy możemy pisać tak samo :
Nieważne czy:
- testuję kalkulator czy 2+2 daje 4,
- czy też sprawdzam, że wywołanie serwisu po HTTP daje mi odpowiedni wynik z podstawionej bazy,
Generalnie na jednym poziomie testuję kod i logikę, na innym to czy komponenty się inizjalizują i działają razem. Na kolejnym połaczenia z bazami i systemami zewnętrznymi/ protokoły. Jak to jest dobrze zrobione - to w sumie nie widać wyraźnie gdzie unity testy się kończą a zaczynają testy integracyjne (poza nazwą pakietu).
Może przykład z mojego kodu zabawkowego:
Tu testuję założoną logikę UserRepository:
https://github.com/javaFunAgain/ratpong/blob/master/src/test/java/pl/setblack/pongi/users/repo/UsersRepositoryTest.java
Po prawdzie są dwa razy odpalane - bo te same testy są z bazą in mem robione i z pełną perzystencją).
Czyli od razu testuje sobie logikę normalną i skażoną :-). Zabawnie: bo ten sam kod wtedy raz jest częścią czegoś co prawie każdy nazwał by testem jednostkowym, a w drugim przebiegu już raczej integracyjnym. WTF :-)
A to jest niby test integracyjny (wywołanie serwera przez httpclient)
interesuje mnie tylko czy składa się wszystko do kupy (jeden test):
https://github.com/javaFunAgain/ratpong/blob/master/src/test/java/pl/setblack/pongi/users/UsersServiceTest.java
0
Izolowanie pewnych elementów jako "jednostek" pozwala na sprawdzenie większości/wszystkich ścieżek.
Ścieżek? Chodzi ci pewnie o coś takiego?
function someFunction (arg) {
if (arg) {
// pierwsza sciezka
} else {
// druga sciezka
}
}
No to myślę, że nie zawsze jest w ogóle możliwe sprawdzenie wszystkich ścieżek wykonania programu. Czy nawet myślę, że czasem nie ma sensu w myśleniu w tych kategoriach. Jeśli testujemy coś co jest mocno stanowe, to nawet jeśli zrobimy testy, które wywołają każdą linijkę aplikacji co najmniej raz, to i tak nie sprawdzimy wszystkich możliwości w jaki sposób aplikacja może się zachować, bo byśmy musieli sprawdzić wszystkie możliwe stany w jakich może znaleźć się aplikacja, a to jest często niemożliwe (czasem można pozbyć się stanowości i wydzielić dużo logiki do czystych funkcji, ale nie zawsze jest to możliwe).
Pewne rzeczy ze stanem (np. GUI) są zupełnie upierdliwe, i o tym nawet już nie mówię - ale dajmy na to, że mamy jakąś bibliotekę, która służy do konwertowania jednych danych w drugie (np. Markdown na HTML). Taka biblioteka z jednej strony może mieć pełno stanowości pod maską, ale na końcu i tak będzie chodziło o to, żeby mając dany plik Markdown wygenerować poprawny HTML.
Dlatego myślę, że często lepiej jest myśleć w kategoriach wejścia-wyjścia (jednostka ma na wejściu jakieś dane A, i powinna na wyjściu mieć dane A'), a nie wnikać w to, czy trafiła w odpowiedni if. Bo w końcu poprawność danych jest ważniejsza od 100% pokrycia dla samego pokrycia.