[Gryllen]

Proszę o radę w kontekście pisania testów jednostkowych i integracyjnych. Pracuje przy rozwijaniu bardzo dużego produktu napisanego w Javie. Dodaję nowe funkcjonalności albo zmieniam te ootb na potrzeby danego klienta. Prawie każda metoda którą piszę pobiera coś z bazy prze home made framework. Wywołuje odpowiednie metody pobierające z bazy co potrzebuję albo składam zapytanie z opowiednich już dostępnych klocków.
Pytanie jest takie jak to testować? Jednostkowe odpadają do takich metod bo pobieram z bazy w nich. Więć co integracyjne z mockiem danych z bazy? Czy rozdzielać metody tak aby logika w Javie była osobna i wtedy unit testy a pobieranie i obróbka danych z bazy w metodach i dla nich integracyjne?
Do tego wyobrażam sobie Selenium na user interfejs w przeglądarkach bo mamy taką możliwość.
Jakieś przemyślenia z większych projektów/produktów?
#java #programowanie

[Myzreal]

@Gryllen: Dlaczego jednostkowe odpadają? Mockujesz bazę, zwracasz sam sobie to co chcesz by baza w danym przypadku zwróciła i jedzesz na tym, testując daną metodę i serwis obserwując czy robi z tymi danymi to co ma zrobić - a że sam je sobie wymyślasz a nie sa zwracane z bazy to nie szkodzi - twój kod o tym nie wie. Więc dopóki dane są spójne z tym co realnie baza by

[K.....r]

@Gryllen ale w logice walisz tymi metodami do bazy i składasz zapytania? Wydziel to do osobnej warstwy, bo się #!$%@? z mockowaniem. Jakieś dao, czy repository z tego porób. I potek cyk, encje z mocka.

[Gryllen]

@KrwawyKefir: No właśnie mnie to dopadło z tym mockowaniem. Przez to połączenia logiki i metod pytających jest to ciężko mockować. Dzięki potwierdziły się moje przypuszczenia, że to jednak trzeba inaczej robić niż jest teraz.

@Myzreal Mam właśnie wątpliwości względem spójności danych. Niektóre typy i konstruckcje z bazy są nieźle skomplikowane. A ja szczerze przyznam, że nie mam w pracy tyle czasu żeby to na 100% poznać. Klient oczekuje rozwiązań i do

[Myzreal]

@Gryllen: No jak masz dane testowe to możesz ich użyć i próbować na tym robić jakieś testy integracyjne - ale jednostkowymi ich nie nazywaj :P

[zajety_login]

@Gryllen: Dla przeciwwagi wobec tego co napisał @Myzreal : absolutnie nie szedłbym w mocki w testach jednostkowych i bazę pamięciową w testach integracyjnych. Mamy rok 2018, więc da się lepiej. Mocki sprawiają że Twoje testy sprawdzają szczegóły implementacyjne, czyli coś co nie powinno ich interesować. Powodzenia w refaktoryzacji kodu, który jest otestowany armią mocków. Jeżeli chodzi o bazę pamięciową, odpowiedz sobie na jedno zajebiście, ale to zajebiście ważne pytanie: chcesz testować

[Myzreal]

@zajety_login: Masz rację, niestety Twoje rady są dla "idealnego" projektu - nad którym masz kontrolę, który nie ma zbyt dużego długu technicznego, i w którym nikt nie #!$%@?ł architektury :P A OP mówi o projekcie, w którym masz dostępy do bazy zmieszane z serwisami a klient "oczekuje rozwiązań", czyl pewnie: "jak to cały dzień testy pisałeś, a co ja biznesowo z tych testów bede mioł?". Powodzenia w wydzielaniu I/O za pomocą

[Gryllen]

@zajety_login: @Myzreal: Dziękuję Panowie za konstruktywne rady. Przynajmniej teraz mniej więcej wiem jak to powinno wyglądać w idealnym środowisku. KOncepcja na dziś jest taka aby małymi kroczkami dążyć do ideały. Cokolwiek bym nie zrobił to i tak będzie lepiej niż jest teraz gdzie pokrycie testami oscyluje wokół zera. Pomimo zrąbanego produktu a bardzo duzym długiem technicznym chciałbym jednak sobie wyrobić dobre wzorce zachowania.

[zajety_login]

@Myzreal: Masz rację, być może powinienem doprecyzować że to co napisałem może być trudne do wprowadzenia w systemach legacy.

@Gryllen: Podoba mi się Twoje podejście. Niestety spotkałem zbyt wielu programistów, którzy kompletnie nie przejmują się kwestiami takimi jak testowalność, łatwość utrzymania, łatwość wprowadzania zmian, łatwość zrozumienia kodu. Przejmowanie systemów po takich osobach to katorga. Brak testów, brak dokumentacji, brak modularyzacji projektu, masa zależności pomiędzy komponentami/modułami. Na szczęście małymi krokami da