Java Spring MVC Phonebook - proszę o code review + podpowiedz co testować.

0

Cześc,

chciałem Was poprosić o ocenę kodu, jest to prosty Spring MVC.

Brakuje mi testów jednostkowych, ale nie do końca wiem jak się do nich zabrać w przypadku np.: @Controller

Co w takiej aplikacji powinienem przetestować i od czego zacząć?

Jak testować i czy tesować metody z CRUD Repository?
Jakieś Mocki?

poniżej link do github'a:
https://github.com/krzysztof83/SpringMVCPhonebook

0

ale nie do końca wiem jak się do nich zabrać w przypadku np.: @Controller

Jeśli się nad tym zastanawiasz to znaczy ze źle napisałeś kod, bo kontroler nie powinien zawierać logiki do testowania

Co w takiej aplikacji powinienem przetestować

Swój kod, który coś robi. U ciebie praktycznie go nie ma, może ewentualnie te walidatory.

Jak testować i czy tesować metody z CRUD Repository?

Nie bardzo rozumiem co tam chcesztestować. Czy Spring Data działa? Czy JPA działa? o_O

Jakieś Mocki?

Chcesz testować czy EasyMock dziala?

Możesz ewentualnie zrobić tam test integracyjny z bazą embedded.

0

@Shalom: dzięki, to mi sporo wyjaśnilo, jeszcze ostatnie pytanie.

Czy poniższa metoda w @Controllerze robi zbyt dużo?

    @RequestMapping(value = "/person/create", method = RequestMethod.POST)
    public String saveForm(@Valid Person person, BindingResult result, ModelMap model) {
        FormValidation formValidation = new FormValidation();

        formValidation.validate(person, result);

        if (result.hasErrors()) {
            return "create";
        }

        person = (Person) result.getModel().get("person");
        personDAO.save(person);
        return "redirect:/contactList";
    }

reszte zrozumiałem, jeszcze raz dzięki.

0

Jeżeli chodzi o walidację formularza, to przeniósłbym to zdecydowanie do serwisu. Wtedy, możesz stworzyć w serwisie metodę addPerson, która będzie przyjmowała dane z tego formularza, sprawdzała ich poprawność i zapisywała osobę i zwracała jakieś PersonDto. Wtedy możesz przetestować ten serwis jednostkowo z użyciem np. bazy h2, albo jakiejś twojej implementacji bazy in-memory np. concurrent hash mapy, sprawdzając czy odpowiednio walidujesz dane. Adnotacje @Valid można wywalić i przenieść tę logikę do serwisu - szczególnie, że i tak dwa razy walidujesz dane.
Przede wszystkim rozdzielłbym klasę Person na:

  • AddPersonDto - dane potrzebne do stworzenia osoby,
  • Person - encja Person, którą zapisujesz w bazie,
  • PersonDto - dane na temat osoby zwracane przez serwis,
    Te klasy niekoniecznie będą miały te same pola, przykładowo encja Person może przechowywać zahashowane hasło, gdy AddPersonDto będzie posiadało hasło podane przez użytkownika, a PersonDto w ogóle nie będzie posiadało tego hasła.

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