Jak dodajecie dane testowe w testach integracyjnych? Przez repozytoria czy przez pliki sql? Który sposób uważacie za lepszy i dlaczego?
0
0
Dodawanie danych? Słaby pomysł, wszystkie potrzebne dane powinny być w samym teście. Jeśli jest ich za dużo, to chyba robić coś źle.
Najlepiej jakbyś pokazał swój test, wtedy można coś więcej powiedzieć.
0
Riddle napisał(a):
Dodawanie danych? Słaby pomysł, wszystkie potrzebne dane powinny być w samym teście. Jeśli jest ich za dużo, to chyba robić coś źle.
Najlepiej jakbyś pokazał swój test, wtedy można coś więcej powiedzieć.
No żeby napisać np. test wyszukiwania produktów, to musisz najpierw jakieś dodać. O to mi chodzi i jak to najlepiej zrobić.
0
Najpierw to najlepiej jakbyś napisał test, że jak masz 0 produktów, i spróbujesz wyszukać to dostaniesz listy wynik.
Pokaż testy jakie już masz .
0
Riddle napisał(a):
Najpierw to najlepiej jakbyś napisał test, że jak masz 0 produktów, i spróbujesz wyszukać to dostaniesz listy wynik.
Pokaż testy jakie już masz .
Ale mi nie chodzi o żaden konkretny test, który mam, to był tylko przykład. Chodzi mi o sposób na dodawanie danych testowych potrzebnych do testów.
0
Chodzi mi o sposób na dodawanie danych testowych potrzebnych do testów
Jakie dodawanie, do czego? Tak jak ci napisał @Riddle, dane maja być w teście, ewentualnie, jak danych jest dużo i zaciemiało by to plik testowy, możesz trzymać na boku, np. w jsonie
0
lion137 napisał(a):
Chodzi mi o sposób na dodawanie danych testowych potrzebnych do testów
Jakie dodawanie, do czego? Tak jak ci napisał @Riddle, dane maja być w teście, ewentualnie, jak danych jest dużo i zaciemiało by to plik testowy, możesz trzymać na boku, np. w jsonie
No do jakiejś bazy danych, czy to nie oczywiste?
0
Nofenak napisał(a):
lion137 napisał(a):
Chodzi mi o sposób na dodawanie danych testowych potrzebnych do testów
Jakie dodawanie, do czego? Tak jak ci napisał @Riddle, dane maja być w teście, ewentualnie, jak danych jest dużo i zaciemiało by to plik testowy, możesz trzymać na boku, np. w jsonie
No do jakiejś bazy danych, czy to nie oczywiste?
Nie, test integracyjne o których wspomniałeś na samej górze to nie muszą być testy które opierają się o jakąś bazę. Przykład: praca z kolejką i testowanie logiki opartej o przesył komunikatów też może być testem integracyjnym.
0
Widzę, że masz jakieś przekonanie że do napisania testu potrzeba dużo danych.
To nie jest prawda, często są się napisać test używając niewielkiej ilości inputów.
Zamiast gdybać, po prostu napisz jeden test i zobacz jak wygada. Jeśli będzie Cię wtedy martwić jego objętość, to wklej go tutaj i coś poradzimy.
Ale ogólnie jak Twój pierwszy test już na starcie jest taki duży że wymaga tyle danych że chcesz go wydzielać, to to jest bardzo zly symptom.
0
Wszyscy się tu skupili na twoim "plik sql" myśląc że masz nie wiadomo jak ogromną ilość danych testowych, natomiast podejrzewam że nie o to ci chodziło.
Jeśli pytasz o to, czy dane testowe lepiej wsadzać do bazy używając swojej implementacji repozytorium, czy odpalając zapytania stworzone oddzielnie dla testu (co nie musi być z pliku, możesz je zrobić w kodzie) to...
Po pierwsze, powiedziałbym żeby zminimalizować ilość testów integracyjnych które wymagają faktycznej bazy danych, tam gdzie nie musisz sprawdzać że pod spodem faktycznie leci połączenie do bazy i odpalają się zapytania, to nie rób tego, zamockuj to swoje repozytorium.
Po drugie, tam gdzie już masz ten test integracyjny z bazą, to osobiście spotkałem się z obydwoma podejściami. Użycie repo do dodawania danych było wygodne i proste, ale nie dawało pewności że pod spodem wszystko wygląda jak należy, że nie pomyliłeś się gdzieś implementując to repozytorium. Więc skłaniałbym się ku drugiemu podejściu, no chyba że twoje repo jest trywialne.
0
-
To zależy.
- Można robić małe testy, gdzie programowo zasilasz bazę danymi
- Można mieć dumpy sql, które wrzuca się jako pliki (bo np. jest to odtworzony przypadek testowy) (to bywa problematyczne w utrzymaniu, chyba, że sprytnie połączysz z wersjonowaniem bazy danych (flyway, liquibase)
- Można zasilać bazę programowo, ale korzystając z generatora (instancio itp)
- Można mieć wszystkie powyższe metody w jednym projekcie, albo nawet teście (np. zaczynam wielkim SQLem, a potem dodaje kilka danych programowo)
-
Nikt nie pytał - ale JPA to g**no, które nie bardzo ma sens w Javie. Po co w języku (jako tako) typowanym używać czegoś co niszczy zalety systemu typów? W JPA/Hibernate kluczowe w działaniu jest czy encje są w stanie Managed czy Detached, a to gówniane API w ogóle nie uwzględnia. Aby się zorientować co można z danym obiektem zrobić musisz przeleźć cały kod, gdzie obiekt może być używany. Jakbym chciał przechodzić cały kod aplikacji za każdym razem jak dodaje ifa to bym pisał w Basicu, albo JS.
W javie są sensowne alternatywy - JOOQ, JDBI