Automatyczne randomowe inicjalizowanie pól objektu JAVA w junit test

Hej wszystkim,

zna może ktoś z was bibliotekę, która automatycznie zainicjalizuje randomowymi wartościami pola obiektów uwzględniajac przy tym adnotacje takie jak (notNull , size, pattern itp. itd.) . Problem polega na tym, że mamy w projekcie napisane convertery, które DTO conwertuja do DOMAIN i na odwrót. Jak sie można domyśleć jest ich sporo, a zamierzamy je przetestować testami jednostkowymi. Inicjalizacja ręczna była by czasochłonna i nie efektywna, ponieważ gdyby ktoś zmienił konwerter bądź objekt musiałby dopasować również testy. Poszukuję biblioteki która w poprawny sposób zainicjalizuje wszystkie wymagane pola mojego DTO przy uruchomieniu testu.

Ale jaki to by miało sens? Przecież potem w teście trzeba jeszcze sprawdzić asercją czy dobrze się przemapowało. Jak niby chcesz to zrobić auto-magicznie? Moja rada: zróbcie w tych DTO jakieś Buildery które ustawiają defaultowe wartości, albo zróbcie sobie odpowiednie Factory. Kombinowanie z jakimiś magicznymi toolami skończy się źle.

Nie jest to odpowiedź na twój problem. Ale jak masz takie DTO i mappery, takie że je się da z automatu (potencjalnie) testować to znaczy, że możesz te DTO wywalić. Jeszcze bardziej niż w testach to wam to przeszkadza w kodzie. I do tego macie dużo głupich błędów -> typu nie zapisują się dane w bazie.

I jest fajna biblioteka, nazywa się fabricator, ale nic nie wypełnia z automatu, zwłaszcza ma gdzieś adnotacje. Po prostu losuje dane.

Jeszcze jest jFairy, ale osobiście nie lubię testów z randomowymi wartościami. Chcesz przetestować corner case, to napisz na to jawnie test.

Pytanie czy warto to testowac jednostkowo, czy to jednak nie powinno byc pokryte integracyjnie? No i Jarek ma racje, nie ma sensu stosowac DTOsów jak się mapuja 1:1 do domenowego.
A poza tym sądze że settery powinny być zniszczone

Bardzo mało mamy converterów które mapują 1:1 może 10 %, i wszystkie dotychczas były przetestowane testami integracyjnymi. Problem polega na tym, że przy deployowaniu testy wykonywały się ponad 15 minut dlatego też zdecydowaliśmy testy integracyjne pomału zastępować junit testami. Robiąc to doszedłem do package "converter" i zastanawiam się co z tym robić :). Na dziś już wystarczy , ale w poniedziałek myślę że, część pól ustawię za pomocą któregoś z powyższych bibliotek, a resztę ustawię ręcznie.

Charles_Ray napisał(a):

Jeszcze jest jFairy, ale osobiście nie lubię testów z randomowymi wartościami. Chcesz przetestować corner case, to napisz na to jawnie test.

Testy z randomowymi wartościami to jedna z podstaw property based testing. Technika ma na celu wykrywanie przypadków, o których programista nie pomyśli nawet.
W javie używam tego głównie przy poważniejszych biznesowych ficzurach, gdzie obrabiam jakieś serie danych. Nieraz już uratowało sytuację.( Głównie przy change requestach.)

przy deployowaniu testy wykonywały się ponad 15 minut dlatego też zdecydowaliśmy testy integracyjne pomału zastępować junit testami

Brak mi słów :D Przecież od tego jest CI żeby mielić te testy. Czekam na kolejny krok testy za długo idą, więc ich nie puszczamy.

Shalom napisał(a):

przy deployowaniu testy wykonywały się ponad 15 minut dlatego też zdecydowaliśmy testy integracyjne pomału zastępować junit testami

Brak mi słów :D Przecież od tego jest CI żeby mielić te testy. Czekam na kolejny krok testy za długo idą, więc ich nie puszczamy.

Był pomysł żeby ustawić tak żeby, wykonywały się tylko testy jednostkowe :)

@dwroblew: brawo, czyli klasyczna mockosturbacja, zamiast testowac czy cos działa, testujesz Mockito...

Zmierzam do tego że większość można przetestować junit testami gdzie integracyjne testy nie mają sensu jak na przykład zmiana statusy albo wartości. Niestety w takich przypadkach czasami zdarzyło się że, ktoś ładuje cały kontekst Springa

I dzięki temu masz faktyczny test całej funkcji systemu i masz pewność że ona działa (przynajmniej o ile powiązane serwisy działają).
Taki unit test to co najwyżej sanity check -> jak sie wywali to znaczy ze coś jest nie tak. Ale jak działa, to w sumie nie wiadomo czy ta funkcja działa czy nie, bo sprawdziłeś tylko malutki jej kawałek.
Mógłbyś skasować endpoint który do tej funkcji kieruje, popsuć access-control/auth, wyrzucić połowę kodu a test nadal będzie zielony. Więc jaka wartość na taki test?

Zalecam zresztą zrobić takie ćwiczenie, skoro twierdzisz że możesz wymienić testy integracyjne na unity -> zobacz ile kodu dotyczącego danej funkcji systemu możesz usunąć / popsuć zanim unit test zrobi się czerwony. Obawiam sie że odpowiedź będzie brzmiała "prawie wszystko". Pytanie więc jaka jest wartość tego testu?

Ma sens to co piszecie i zgadzam się w stu procentach, ale przy teście 2+2=4 ładować kontekst springa też jest bezsensowne prawda? a takich kwiatków w kodzie trochę jest. Kolejną temat to proporcja 450 testów integracyjnych do 70 junit, według wielu źródeł powinno być na odwrót. Inna sprawą jest to że, ja jestem tylko zwykłym juniorem który wykonuje polecenia moich niemieckich "doświadczonych" kolegów :)

Kolejną temat to proporcja 450 testów integracyjnych do 70 junit, według wielu źródeł powinno być na odwrót

Te źródła to jakiś 50-letni cargo-cult ;) Unity mają sens tylko do testowania jakiejś skomplikowanej logiki domenowej, kiedy koniecznie chcesz to testować w separacji. Moim zdaniem proporcja którą macie jest bardzo dobra.

ja jestem tylko zwykłym juniorem który wykonuje polecenia moich niemieckich "doświadczonych" kolegów

W takim razie zalecam rozglądać się za nową pracą, z 2 powodów:

• uczą cię tam głupot
• niedługo trzeba będzie to utrzymywać a wtedy ten brak testów będzie mocno boleć :)

przy teście 2+2=4

A macie taką funkcje w systemie? Czy może jednak funkcja to:

• user musi być zalogowany
• user musi mieć odpowiednią rolę
• user musi wprowadzić 2 wartości które są liczbami w odpowiednim zakresie
• system musi być w stanie XYZ
• ...
• system powinien zwrócić 4

Z tych wszystkich punktów chcesz sprawdzić tylko ten ostatni. Można, fakt, tylko taki test nie wykryje kiedy coś z wcześniejszych punktów przestanie działać...

Ma sens to co piszecie i zgadzam się w stu procentach, ale przy teście 2+2=4 ładować kontekst springa też jest bezsensowne prawda

Masz częściowo rację. Częściowo, bo skoro wywołanie 2+2 jest w ramach testu integracyjnego to po co pisac osobny test?
Z drugiej strony, może być jakas bardziej złozona logika. Załóżmy że mamy kalkulator kosztów na podstawie liczby godzin plus np. typu abonamentu. Wtedy jest sens testów jednostkowych, bo można łatwo wprowadzic duzo danych testowych, a sama implementacja jest bardzo niezalezna od baz danych itp

Kolejną temat to proporcja 450 testów integracyjnych do 70 junit, według wielu źródeł powinno być na odwrót.

Kiedys powszechne były goto i pewnie wiele ksiązek je pochwalało :)