[C.....s]

Próbuje w końcu pisać testy, może ktoś zerknąć czy te są ok?
kod
#java #junit #testyjednostkowe #naukaprogramowania

[fegwegw]

@Cheessys: Po co przed każdym testem instancjonujesz VoteService?

[krasnoludkolo]

@fegwegw nie lepiej testować na niezależnych instancjach?

[fegwegw]

@krasnoludkolo: a po co jeśli to jest bezstanowe? W produkcyjnej aplikacji też zawsze korzystasz z nowych instancji?

[krasnoludkolo]

@fegwegw faktycznie, nie czytałem kodu serwisu

[C.....s]

@fegwegw: ok, to poprawie, a tak poza tym to testy są ok?

[fegwegw]

@Cheessys: są w miarę poprawne, natomiast logika biznesowa jest pokrętna.

I aby testy były czytelniejsze, możesz użyć biblioteki Truth do asercji, są dużo lepsze niż teg junitowe.

[C.....s]

@fegwegw: Dlaczego pokrętna i w takim razie jak to można zrobić lepiej?

[fegwegw]

@Cheessys: wydaje mi się, że model jest zbyt rozbudowany jak dla tego typu funkcjonalności. Z tego co widzę, chcesz up i down voteować artykuły. Po co tworzyć osobny obiekt Vote? Myślę, że mapa user-wartość głosu w modelu Article w zupełności wystarczy.

Czym w tym serwisie jest w ogóle 'Activity'? Czemu VoteType jest enumem, a i tak do porównywania wartości używasz stringów?

[C.....s]

@fegwegw: Po Activity dziedziczą 4 inne klasy w których można glosować, każda ma tez klase dziedzicząca po Vote i zapisuje w db na co użytkownik glosował, a porównuje stringi bo w db voteType jest zapisany stringiem

[fegwegw]

a porównuje stringi bo w db voteType jest zapisany stringiem

@Cheessys: ale używasz pewnie jakiegoś ORM?

[C.....s]

@fegwegw: Uzywam Spring Data.

[fegwegw]

@Cheessys: no, i jaki jest problem, żeby w encji trzymać enuma? javax.persistence.Enumerated?

[C.....s]

@fegwegw: Nie wiedziałem o tym (✌ ﾟ ∀ ﾟ)☞, już podmieniłem.

[cypo]

@Cheessys: Trzymaj się koknwencji "given (or setup) when(or execute) then(or verify)"
Co do kodu, to po co Ci serwis mutujący obiekty, gdzie one same mogą to robić - Activity.vote(vote)

Po Activity dziedziczą 4 inne klasy w których można glosować

chciałeś napisać implementują interfejs Activity?

[C.....s]

Co do kodu, to po co Ci serwis mutujący obiekty, gdzie one same mogą to robić - Activity.vote(vote)

Zeby nie powtarzac tego w 4 klasach

chciałeś napisać implementują interfejs Activity?

nie
@cypo:

[cypo]

@Cheessys: Tylko to jest mało obiektowe. To nie serwis, tylko taki util. Nie jest dobrze nabierać złych praktyk, w produkcyjnym projekcie taki kod by nie przeszedł review.
https://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html
Z dziedziczeniem też trzeba uważać, sprawdź sobie temat "Composition over inheritance". Jeszcze więcej szczegółów znajdziesz pod hasłem DDD.

[C.....s]

@cypo: Czyli według tego artykułu powinienem zrobić dwie klasy AddVote i UpdateVote? Gdzie trzymać takie klasy?

[cypo]

Albo Vote oddzielnie (z jakąś relacją do Activity), albo interfejs Voteable do tych 4 klas z metodą vote(voteCommand) i w środku obiekt typu Vote, żeby się nie powtarzać z kodem głosującym.
Ja bym to rozdzielił - jest np (teoretycznie). Activity: artykuł, komentarz. To są oddzielne odpowiedzialności. Głosowanie może być na wybrany obiekt, więc vote = voteRepository.for(activity) a potem vote.apply(voteCommand). Wtedy głosowanie nie rusza obiektu treści, który jest już utrwalony i nie musi

[cypo]

@Cheessys: Jeśli jednak nie masz czasu ogarniać wszystkiego obiektowo, domenowo i chcesz pisać w starym warstowo-proceduralnym stylu, to niech chociaż serwis nie mutuje argumentów. Powinien ogarnąć wszystko na raz - pobranie, modyfikację i zapis. Wtedy zamiast bazy w testach - mockito na DAO (czy tam repository) i szpiegujesz obiekt Activity, czy przy zapisie do bazy ma poprawne wartości.

W sumie doczytując testy da się chyba ogarnąć use-case jaki masz. Spojrzę

[cypo]

@Cheessys:
Odnośnie tematu testów, pomijając powyższe dywagacje.
void addVoteUp() zmieniony:

@Test
 addVote_shouldVoteUp() { // co testujemy, jaki jest cel testu
 //given // podział na bloki: ustawienie stanu, uruchomienie akcji, weryfikacja wyników/stanu końcowego
 vote.setVoteType(VoteType.VOTE_UP.toString());
 //when
 Activity result = voteService.addVote(article, vote);
 //then
 Assert.assertEquals(1, result.getVotes());
 }