Wątek przeniesiony 2019-03-30 13:36 z przez Patryk27.

Prośba o Code Review

Odpowiedz Nowy wątek
2019-03-30 12:37
0

Cześć. Piszę do was z prośbą o ocenę kodu mojej aplikacji. Pisałem ją przez 4 wieczory i 3 dni od zera. Jest to mój pierwszy "większy" projekt w Springu i zdaję sobie sprawę, że to tylko prosty CRUD bez logiki. Pisząc go chciałem podsumować swoją wiedzę przed przejściem do nauki REST`ów i przy okazji stworzyć jakiś projekt do portfolio, które chciałbym ewentualnie kiedyś wykorzystać do znalezienia pierwszego stażu wakacyjnego. Planuję w najbliższym wolnym czasie popracować nad Security ( dodawanie użytkowników, edycja ról itp. ). Prosiłbym o skupienie się na samym backendzie, ponieważ frontend u mnie raczkuje. Z góry dziękuję za pomoc, rady, konstruktywną krytykę i poświęcony czas.

Link do repozytorium : https://github.com/DSniatecki/YourFleetManager

Pozostało 580 znaków

2019-03-30 13:40
1

Tak poza tym to na oko wygląda ok, CRUD jak CRUD, w zasadzie nie ma tam funkcjonalnego kodu, więc trudno cokolwiek więcej powiedzieć.
Mógłbyś przynajmniej dopisać tam jakieś "prawdziwe" testy, tzn takie które wystartują ci jakąś bazę in memory i postawią aplikacje na jakimś embedded jetty/tomcat i faktycznie będziesz stukać po endpointach.


Na PW przyjmuje tylko (ciekawe!) zlecenia. Masz problem? Pisz na forum, nie do mnie.
edytowany 1x, ostatnio: Shalom, 2019-03-30 13:41
@Shalom: z doświadczenia - przed skopiowaniem linku naciśnij y na klawiaturze by mieć canonical URL. - hauleth 2019-04-02 13:14
opera masterrace takich rzeczy nie wspiera chyba :P - Shalom 2019-04-02 13:36
Powinna, bo to jest skrót w GitHubie a nie w przeglądarce. - hauleth 2019-04-02 15:12
No ale jakieś brzydkie JSy odpala - Shalom 2019-04-02 15:22
Co tam chcesz, ale hardlinking do mastera to niekoniecznie dobre wyjście, bo linki szybko się zdezaktualizują. - hauleth 2019-04-02 15:35

Pozostało 580 znaków

2019-03-30 14:23
0
Shalom napisał(a):

Poprawione.

Zmienione na "entities".

Tak poza tym to na oko wygląda ok, CRUD jak CRUD, w zasadzie nie ma tam funkcjonalnego kodu, więc trudno cokolwiek więcej powiedzieć.
Mógłbyś przynajmniej dopisać tam jakieś "prawdziwe" testy, tzn takie które wystartują ci jakąś bazę in memory i postawią aplikacje na jakimś embedded jetty/tomcat i faktycznie będziesz stukać po endpointach.

Dzięki za rzucenie okiem i wszystkie rady :)

edytowany 2x, ostatnio: DamianSn, 2019-03-31 15:56

Pozostało 580 znaków

2019-04-02 12:54
1

Na twoim miejscu pozmieniałbym nazwy testów. W JUNIT 5 masz do dyspozycji adnotację @DisplayName dzięki której możesz stworzyć czytelną nazwę testu. Niektóre testy mają tytuł totalnie nie adekwatny do tego co dany test robi.

Moim zdaniem powinieneś dodać sobie jakąś baze inMemory np H2 i koniecznie stworzyć testy integracyjne dla kontrolerów, chociażby. Dobrą praktyką jest też odpowiednie nazewnictwo klas testów tzn dla testów jednostkowych dodawać suffix UnitTest lub UTest lub po prostu UT, dla integracyjnych IntegrationTest lub ITest lub IT

czyli np UserControllerITest, UserServiceUTest itd.

Pozostało 580 znaków

2019-04-02 14:28
0
witold12 napisał(a):

Na twoim miejscu pozmieniałbym nazwy testów. W JUNIT 5 masz do dyspozycji adnotację @DisplayName dzięki której możesz stworzyć czytelną nazwę testu. Niektóre testy mają tytuł totalnie nie adekwatny do tego co dany test robi.

  • Początkowo chciałem napisać testy jednostkowe właśnie w JUnit 5, ale nie mogłem znaleźć sposobu jak "zmockować" komponenty do testów by później przy nich nie był wczytywany kontekst, a w JUnit 4 wyszło mi to bez problemu.

Moim zdaniem powinieneś dodać sobie jakąś baze inMemory np H2 i koniecznie stworzyć testy integracyjne dla kontrolerów, chociażby. Dobrą praktyką jest też odpowiednie nazewnictwo klas testów tzn dla testów jednostkowych dodawać suffix UnitTest lub UTest lub po prostu UT, dla integracyjnych IntegrationTest lub ITest lub IT

czyli np UserControllerITest, UserServiceUTest itd.

  • Dzięki za rady. W wolnym czasie przerobię te testy od początku tak jak trzeba.

Mam jeszcze kilka pytań o testy. Jak to jest z tym TDD ? Dużo osób to praktykuje ? Jeśli nie praktykujecie TDD, to w którym momencie piszecie testy ? Czy takie pisanie testów do działającego już kodu ma sens ?

edytowany 1x, ostatnio: DamianSn, 2019-04-02 14:29

Pozostało 580 znaków

2019-04-02 17:44
1

Tam gdzie się da staram się pisać testy przed kodem, bo przynajmniej mam jakąś wizję jak coś ma działać i wiem czy działa (szybciej tak sprawdzać niż ręcznie). Pisanie testów do działającego kodu ma taki sens, że na własnej skórze odczujesz co to znaczy nietestowalny kod :P


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ

Pozostało 580 znaków

2019-04-02 17:57
0

A jak rygorystyczne mają być testy ? Każda metoda ma być przetestowana dla każdej sytuacji ? Czyli osobny test dla sukcesu i osobny dla każdego możliwego wyjątku przez nią rzuconego ? Jeśli np. 2 metody rzucają ten sam wyjątek w serwisie dla tej samej sytuacji to powinno się napisać 2 osobne testy dla nich, sprawdzające czy każda z nich rzuca ten wyjątek ? Sorka za zasypywanie pytaniami :D

Pozostało 580 znaków

2019-04-02 18:02
1
DamianSn napisał(a):

A jak rygorystyczne mają być testy ? Każda metoda ma być przetestowana dla każdej sytuacji ?

To zależy. Krytyczne częsci projektu powinny być przetestowane pod każdym możliwym względem (krytyczne-> te które faktycznie zarabiają pieniądze, ewentualnie kwestie bezpieczeństwa). Reszta natomiast zazwyczaj starczy jakiś happy path plus jakieś typowe przypadki skraje, bez jakiegoś cudowania.

Czyli osobny test dla sukcesu i osobny dla każdego możliwego wyjątku przez nią rzuconego? Jeśli np. 2 metody rzucają ten sam wyjątek w serwisie dla tej samej sytuacji to powinno się napisać 2 osobne testy dla nich, sprawdzające czy każda z nich rzuca ten wyjątek? Sorka za zasypywanie pytaniami :D

Nie rzucaj wyjątkami ;) Zależy jak różne są to sytuacje, ale najlepiej chociaż po teście na wyjątek.

Tu masz przykładowe z jakiegoś mojego pobocznego projektu. Może się jakoś nimi zasugerujesz ;)


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ

Pozostało 580 znaków

2019-04-02 20:23
1

Każda metoda ma być przetestowana dla każdej sytuacji ?

Tego w ogólnym przypadku nigdy nie osiągniesz (dla niektórych można zrobić przegląd przez wszystkie możliwe wartości, np. jeśli używasz 32-bitowego inta), ale istnieje coś takiego jak property testing gdzie opisujesz jakie właściwości ma mieć funkcja na uproszczonym modelu. W czasie testów biblioteka do property testingu generuje losowe wartości i sprawdza czy cechy, które są wymagane są spełnione. Przykładowy zbiór testów dla funkcji dodawania (pseudo składnia inspirowana Elixirem):

check all a <- integer(), b <- integer(), c <- integer() do
  assert a + b == b + a # przemienność
  assert a + 0 == a     # element neutralny
  assert (a + b) + c == a + (b + c) # łączność
end

W ten sposób jesteś w stanie często całkiem szybko wyłapać trochę mniej oczywiste błędy.

Pozostało 580 znaków

2019-04-13 02:19
0

Siemaneczko. Przez ostatnie dwa dni stworzyłem RESTową, ulepszoną wersję tej aplikacji. Poprawiłem testy jednostkowe i przeskoczyłem na JUnit5. Niestety ciągle nie napisałem testów integracyjnych. Jest to w sumie moja pierwsza REST`owa apka ( nie licząc restowego hello worlda ). Co ja się namęczyłem z MapStructem to szkoda gadać, a na końcu i tak część mapperów sam napisałem . Jak będziecie mieli ochotę to możecie rzucić okiem. Rady i konstruktywna krytyka zawsze mile widziane. Z góry dzięki !

Link do repo : https://github.com/DSniatecki/YourFleetManager.V2-REST

Przy okazji mam dwa pytanka :

  • czy metoda HTTP POST powinna zezwalać na edycję obiektu, czy zawsze ma dodawać go jako nowy ?
  • czy poza zwróceniem responsa OK DELETE powinien coś robić w przypadku sukcesu ?
edytowany 1x, ostatnio: DamianSn, 2019-04-13 02:19

Pozostało 580 znaków

2019-04-13 15:38
0

Od edycji jest PUT


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0