Jak ogolnie wiadomo, zalezne od siebie testy to generalnie zla praktyka, szczegolnie przy testach jednostkowych.
Czy jest to jednak dopuszczalne przy testach integracyjnych?
Np:
@Test
uzytkownikTworzyObiekt()
@Test
uzytkownikAktualizujeObiektZTestu1()
@Test
uzytkownikUsuwaobiektZTestu1()
Czy absolutnie, bez zadnych dyskusji testy 2 i 3 musza byc napisane tak, aby byly niezalezne od 1?
Myślę, że można znaleźć racjonalne uzasadnienie, żeby tak zrobić, np. gdy mamy taki scenariusz:
Przeprowadzenie tych testów w sposób niepowiązany ze sobą zajmie 2 razy więcej czasu.
Może lepiej całość umieścić w 1 metodzie testowej?
shagrin napisał(a):
Jak ogolnie wiadomo, zalezne od siebie testy to generalnie zla praktyka, szczegolnie przy testach jednostkowych.
Czy jest to jednak dopuszczalne przy testach integracyjnych?
preferuje podejscie ze testy powinny byc pisane po to zeby ratowac d... skore, a nie spelniac jakies sztywne definicje, dlatego imo wszystko dozwolone, wazne zeby spelnialo swoja funkcje, bylo mozliwie proste i czytelne i nie zostawialo sladow na zewnatrz (w bazie, sieci, systemie plikow etc)
Czy absolutnie, bez zadnych dyskusji testy 2 i 3 musza byc napisane tak, aby byly niezalezne od 1?
mysle ze test 1 jest zbedny, zamiast tego zrobilabym z niego np. metode wywolywana (przez ciebie lub twoja test libke) przed testami 2 i 3 ktora tworzy usera na potrzeby reszty testow. oczywiscie nie znam w 100% twojego scenariusza, niemniej wydaje mi sie zbednym explicite testowac tworzenie usera skoro i tak jest to wymagane przy kazdym innym tescie.
Pytanie w czym problem:
Nie robiłbym tragedii z tej zależności testów jeśli jest to na jakąś małą skalę i mamy framework, który określa jednoznaczne wymusza kolejność.
Inna sprawa, że testy jakie podałaś jeśli odbywają się na mojej bazie danych (jeśli pechowo taką mam) - to nawet nie nazywam integracyjnymi i testuje jak unitowe. Uważam, że ten podział na testy integracyjne, komponentowe, unitowe jest ogólnie dość sztuczny. To są po prostu testy na różnych poziomach / warstwach abstrakcji, ale zasadzniczo niczym się nie różnią.
O ile kojarzę frameworki testowe z których korzystam, to one raczej nie przejmują się kolejnością testów (o ile kojarzę, to wręcz tę kolejność losują). Druga sprawa - jeżeli testy są od siebie zależne, to analizując faila musisz być świadoma co jest problemem pierwotnym a co wtórnym.
Ja napisałbym taki scenariusz insert, update, delete w jednej metodzie testowej. Jeżeli scenariuszy wykorzystujących takie fragmenty ma być więcej, to można sobie to wyciągnąć do 3 metod nie będących testami.
Ja się spotkałem z podejściem - na niskim poziomie dużo testów, które szybko przechodzą, a z e2e zamknąć to w jednym teście i po każdej akcji wstawiać asercje. Tutaj też takie podejście przejdzie i będzie to jeden test, tylko bardziej złożony. Z rozbijaniem tego na kilka testów bym uważał - a co jak niedługo CI będzie puszczało testy równolegle na kilku maszynach?
Też jestem za zebraniem tego w jeden test, a nie próbom wpływania na kolejność wykonywania testów. Nie ma co na siłę trzymać się podziału jeden test == jeden request.
Kiedyś popełniłem ten błąd, że testy były zależne od danych zmienionych przez poprzedni test :-) Nie wziąłem pod uwagę, że Google Test dla C++ w Jenkinsie jest skonfigurowany z losowym, wielokrotnym uruchamianiem testów...
Rozwiązaniem był zestaw narzędziowy wspomagający tworzenie danych wejściowych do testów. Nie zawsze musi to być jakiś odrębny moduł, czasem wystarczy metoda czy dwie.
+1 do tego co pisał @katelx i @Shalom w komentarzach.
Jak większość tutaj staram się separować testy od siebie i robić setup(reset) stanu aplikacji przed każdym testem. Może i jest więcej pisania, ale warto.
Nigdy nie powinnaś zmieniać stanu testu innym testem. Powinnaś mieć oddzielne testy dla mechaniki projekcji, transformacji, przy tworzeniu i aktualizacji obiektu i traktować te zachowania jako uint. Taki test będzie się również inaczej nazywał. Jeśli używasz portów zewnętrznych powinnaś przetestować zachowanie aplikacji takie jak create, update w SUT.
