Dostęp do klas pakietowych podczas pisania testów

Cześć, ostatnio zacząłem naukę pisania prostych testów i chciałem przećwiczyć pisanie ich do aplikacji konsolowej, którą wcześniej napisałem. Pojawił się jednak problem, aby mieć dostęp w klasie Test do klas, które nie są publiczne. Czytałem, ze powinienem (jeśli dobrze zrozumialem) umieścić klasy UserPersonalDataTest i klasę UserPersonalData w jednym pakiecie, ale w innych fizycznych folderach. Kiedy chce tak zrobić klasa UserPersonalDataTest przenosi się do pakietu userManagement i znika z folderu test. W jaki sposób mogę to zrobić, żeby działało?

Tutaj screenshot jak to mniej więcej wyglada:

Musisz w /test mieć pakiet userManagement i w nim swój test. W tej chwili klasa testowa jest w innym pakiecie.

opiszon napisał(a):

Musisz w /test mieć pakiet userManagement i w nim swój test. W tej chwili klasa testowa jest w innym pakiecie.

Tylko właśnie nie widzę takiej opcji, żeby stworzyć folder w pakiecie userManagement. Mogę stworzyć tylko klasę do testów, ale nie folder:

Package

Niestety cały czas nie mam dostępu do klas, które nie są publiczne

A musisz testować niepubliczne klasy? Może coś nie tak z designem / designem testów?

opiszon napisał(a):

Package

Cały czas nie mam dostępu do klas, które nie są publiczne

lion137 napisał(a):

A musisz testować niepubliczne klasy? Może coś nie tak z designem / designem testów?

Tutaj link do repozytorium:
https://github.com/MaciekSm19/Bank/tree/master/src

Ogólnie tak jak pisałem dopiero uczę się pisać testy i chciałem poćwiczyć na gotowej już aplikacji. Chce napisać testy do większości metod z tej aplikacji

W repo masz coś innego niż na zrzucie, bo klasy leżą w root, nie w pakietach.

Co rozumiesz przez "klasy, które nie są publiczne"? Bo jeśli private to oczywiście, że się do nich nie dostaniesz.

opiszon napisał(a):

W repo masz coś innego niż na zrzucie, bo klasy leżą w root, nie w pakietach.

Już poprawione (tylko usunąłem folder z testem)

Kod produkcyjny w scr/main/java
Kod testowy w src/test/java
Strzelam że ide nie radzi sobie ze zmapowaniem source folderów jak nie trzymasz się konwencji ani nie masz żadnego pom.xml w którym bys zdefiniował foldery.

szatkus1 napisał(a):

Co rozumiesz przez "klasy, które nie są publiczne"? Bo jeśli private to oczywiście, że się do nich nie dostaniesz.

opiszon napisał(a):

Kod produkcyjny w scr/main/java
Kod testowy w src/test/java
Strzelam że ide nie radzi sobie ze zmapowaniem source folderów jak nie trzymasz się konwencji ani nie masz żadnego pom.xml w którym bys zdefiniował foldery.

Właśnie zawsze korzystałem z tego domyślnego builda od IntelliJ. Pom.xml to plik mavena tak? Mam jeszcze pytanie, którego buildu używać domyślny/maven/gradle

pom.xml to maven.

Maven czy Gradle - który wolisz. W rzeczywistej pracy będziesz uzywal tego który jest w projekcie ;-)

Hierarchia pakietów (folderów) w /src/main/test musi być taka sama jak w /src/main/java żeby Ci się dostępy zgadzały.

Czemu nikt nie wytknie że to jest zły pomysł?

RequiredNickname napisał(a):

Hierarchia pakietów (folderów) w /src/main/test musi być taka sama jak w /src/main/java żeby Ci się dostępy zgadzały.

Przy czym od razu należy dodać że pod względem testów to jest bardzo zły pomysł, bo dodaje tight-coupling testów do kodu.

Najlepiej w testach testować tylko to co jest public z pakietów.

@Maciek_SK8 Nie pisz testów pod rzeczy które nie są public w Twoich modułach! Rzeczy które są package-private testuj za pośrednictwem rzeczy które są public.

Nie pisałbym testu pod coś co jest package-private chyba że nie miałbym innego wyjścia, i to musiałby na prawdę być szczególny przypadek.

Pełna zgoda, testowanie blackboxowo np. tylko jakiejś wystawionej publicznje fasady nie betonuje potem kodu i pozwala dowolnie zmieniać implementację póki api i zachowanie się zgadza ;)

Riddle napisał(a):

Czemu nikt nie wytknie że to jest zły pomysł?

RequiredNickname napisał(a):

Hierarchia pakietów (folderów) w /src/main/test musi być taka sama jak w /src/main/java żeby Ci się dostępy zgadzały.

Przy czym od razu należy dodać że pod względem testów to jest bardzo zły pomysł, bo dodaje tight-coupling testów do kodu.

Najlepiej w testach testować tylko to co jest public z pakietów.

@Maciek_SK8 Nie pisz testów pod rzeczy które nie są public w Twoich modułach! Rzeczy które są package-private testuj za pośrednictwem rzeczy które są public.

Nie pisałbym testu pod coś co jest package-private chyba że nie miałbym innego wyjścia, i to musiałby na prawdę być szczególny przypadek.

Czyli w jaki sposób zrobić hierarchie folderów i pakietów, żeby moc testować tę klasę, do której napisałem testy:
https://4programmers.net/Forum/Java/373676-czy_testy_sa_dobrze_napisane?p=1971260#id1971276

Maciek_SK8 napisał(a):

Czyli w jaki sposób zrobić hierarchie folderów i pakietów, żeby moc testować tę klasę, do której napisałem testy:
https://4programmers.net/Forum/Java/373676-czy_testy_sa_dobrze_napisane?p=1971260#id1971276

Moja rada: Nie przejmuj się w ogóle strukturą folderów, po prostu pisz testy pod elementy które są public - wtedy struktura nie musi być identyczna.

Riddle napisał(a):

Maciek_SK8 napisał(a):

Czyli w jaki sposób zrobić hierarchie folderów i pakietów, żeby moc testować tę klasę, do której napisałem testy:
https://4programmers.net/Forum/Java/373676-czy_testy_sa_dobrze_napisane?p=1971260#id1971276

Moja rada: Nie przejmuj się w ogóle strukturą folderów, po prostu pisz testy pod elementy które są public - wtedy struktura nie musi być identyczna.

Ale to w jaki sposób będę miał wtedy dostęp do klas w testach, które nie są publiczne (czytałem na stacku i ludzie też właśnie pisali, żeby dać do jednego pakietu)

Nie będziesz miał.
Możesz zrefaktorować kod i testy tak żeby testować metody tylko publiczne.

Maciek_SK8 napisał(a):

Ale to w jaki sposób będę miał wtedy dostęp do klas w testach, które nie są publiczne (czytałem na stacku i ludzie też właśnie pisali, żeby dać do jednego pakietu)

Nie chcesz mieć dostępu z testów do nie-publicznych klas.

Nie-publiczne klasy mają taką zaletę, że możesz je refaktorować/zmieniać; i nic poza pakietem nie powinno się wtedy zmienić - również testy. Publiczne mają tą wadę, że inne moduły (i testy) mogą na nich polegać, więc ich zmiany są trudniejsze, dlatego warto je ograniczać do minimum.

Mi się wydaje, że @Maciek_SK8 ma problem z czym innym.

Mamy przykłądowo publiczną klasę SomeServiceFacade któa ma np. dwie pakietowe zależności ServiceA i ServiceB.
Wydaje mi się, że autorowi problem sprawia samo zsetupowanie SomeServiceFacade w testach bo przecież musi wstrzyknąć do środka ServiceA i ServiceB (zakłądam, że piszemy unit testy, nie ma żadnego springowego kontekstu i musimy te klasy zwyczajnie utworzyć za pomocą konstruktora przez new).

Umieszczając klasę SomeServiceFacadeTest gdzie popadnie faktycznie nie będzie się dało stworzyć obiektu publicznje fasady którą chcemy przetestować bo nam kompilator klas nie zobaczy.

Musisz @Maciek_SK8 tak jak pisałem zrobić identyczną strukturę folderów w src/main/test co w src/main/java (wręcz lustrzane odbicie):

I tak jak pisał @Riddle ograniczenie się do testowania tylko publicznych metod z fasady (które stanowią kontrakt Twojego modułu) przyniesie sporo korzyści.

RequiredNickname napisał(a):

Mi się wydaje, że @Maciek_SK8 ma problem z czym innym.

Mamy przykłądowo publiczną klasę SomeServiceFacade któa ma np. dwie pakietowe zależności ServiceA i ServiceB.
Wydaje mi się, że autorowi problem sprawia samo zsetupowanie SomeServiceFacade w testach bo przecież musi wstrzyknąć do środka ServiceA i ServiceB (zakłądam, że piszemy unit testy, nie ma żadnego springowego kontekstu i musimy te klasy zwyczajnie utworzyć za pomocą konstruktora przez new).

Umieszczając klasę SomeServiceFacadeTest gdzie popadnie faktycznie nie będzie się dało stworzyć obiektu publicznje fasady którą chcemy przetestować bo nam kompilator klas nie zobaczy.

Musisz @Maciek_SK8 tak jak pisałem zrobić identyczną strukturę folderów w src/main/test co w src/main/java (wręcz lustrzane odbicie):

I tak jak pisał @Riddle ograniczenie się do testowania tylko publicznych metod z fasady (które stanowią kontrakt Twojego modułu) przyniesie sporo korzyści.

Dzięki bardzo, doczytam o tym jeszcze i poprawie ten kod. Na tą chwile wyglada to tak: