Zaczynając od góry:
Statyczne importy = ban,
Klasa JsonTool
:
- Ta nazwa nic nie mówi, co to jest tool? Tool może być do miliona rzeczy.
-
public static String parseJson(Object obj)
nazwa metody sugeruje, że będziesz w niej parsował JSONa, a na wejściu przyjmujesz obiekt. Źle.
} catch (Exception e) {
throw new RuntimeException(e);
}
Co to jest za obsługa wyjątków? Rzucenie innego wyjątku i elo?
public static Object parseObject(String json, Class clazz) {
try {
return mapper.readValue(json, clazz);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
skoro przekazujesz już typ klasy w parametrze to zmień ta metodę tak aby automatycznie miała ten sam zwracany typ, skorzystaj z generyków. Bez sensu to jest to rzutowanie później przy każdym użyciu, jest to niestety źle. Ta trzecia metoda to samo.
Klasa Tool
:
-
public static String randomString()
nazwy metod powinna być odczasownikowe getRandomString()
. Reszta to samo.
- Nazwa klasy
Tool
nic nie mówi.
Klasa UriTool
- Nazwa klasy
- Nazwy metod jw.
Klasa UserTool
- Nazwa klasy i nazwy metod.
- Nie podoba mi się, że metoda
registerRandomUser
przyjmuje MockMvc, według mnie powinna mieć swój obiekt.
Klasa WalletTool
jw.
Klasa UserResourceTest
- Potrafisz uzasadnić użycie
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
?
- Podwójnie zła nazwa
should_register_user
. Po pierwsze camelCase, po drugie przyjmij lepszą konwencje nazewnictwa testów tak żeby każdy po rzuceniu okiem od razu wiedział co on sprawa. Testy to wymagania dlatego muszą mieć dobre nazewnictwo. Sugeruję konwencje (są to przykłady): assertThatUserCanBeRegistered
albo givenRegistrationRequestThenUserIsSuccesfullyRegisreted
- Brakuje komentarzy given when then. Zle się to czyta.
- Ten JSON w postaci Stringa w metodzie
should_return_principal()
to zły pomysł. Powinieneś czytać go z osobnego pliku.
- Tutaj jakaś dziwna konwersja DTO na DTO:
UserDto expectedResponse = UserDto.builder()
.email(userDto.getEmail())
.build();
Nie kumam tego.
-
.items(new HashMap<>())
korzystaj z Collections.emptyMap()
Klasa WalletResourceTest
-
import java.awt.*;
wtf ?
- To samo co wyżej plus nie pushuj zakomentowanego kodu.
Na razie sporo tego tego, więc oprócz testów do reszty kodu nie zaglądałem.
Czy ten projekt nadaje się do CV czy to jednak nie ten poziom
Jak parę osób zrobi jeszcze porządne CR i poprawisz uwagi to możesz wrzucić, ale bądźmy szczerzy - nie będą to fajerwerki.
Jeżeli nie ten poziom to co powinienem poprawić I co zrobić żeby jakoś zawojować, pokazać na rynku pracy, robić więcej projektów, jakaś biblioteka
Ja bym poszedł w technologie, których nie ma każdy bootcampoicz czy wannabe developer w CV. Będzie cię to kosztowało trochę wysiłku, ale postawienie czegoś w WebFluxie albo czegoś prostego na kilku mikroserwisach dałoby ci przewagę nad resztą. I obowiązkowe dobre README.md podejdź do tego pliku na poważnie, to jest pierwszy plik po wejściu w repo, powinien być ładny, estetyczny i mówić wszystko o projekcie. Do tego jakiś prosty ale ładny front w Vue.js i wrzucenie całości na Heroku/AWS. Nie oszukujmy się - ludzie wolą testować taki projekt tzw live, a nie przekopywać się przez kod w repo.