- Test będzie wykorzystywał trzy wstrzyknięte komponenty, oznaczone adnotacją @Autowired:

  -- ExpensesService

  -- ExpensesRepository

  -- UserRepository

- Testy powinny sprawdzać tylko podstawowe zachowanie, wystarczy zapisać kwotę i sprawdzenie czy poprawnie się zapisała

- Tworzony test będzie podobny do już istniejącego: AssetServiceIntegrationTest, możesz dostosować rozwiązania w nim zastosowane, pod potrzeby nowego testu

- Przyjżyj sie metodzie initDefaultMockUserInDatabase w klasie AssetServiceIntegrationTest

- Pobierając wszytkie wydatki jednego użytkownika, niezbędne jest stworzenie w 'ExpensesRepository' nowej metody 'findAllByUser'

HINT: jeżeli dodałeś niepoprawną nazwę pola w ExpensesEntity, testy mogą nie przechodzić, dostaniesz błąd: 'Column "nazwa kolumny" not found', wszystkie nazwy kolumn, pól klasy encji, jakie powinny być użyte, są wyszczególnione w resources/db/migration/007-expenseseSchema.yaml, wyjątek stanowi 'user_id' - poprawna nazwa pola to 'user'.

HINT: nazwa kolumny 'purchase_date' w pliku resources/db/migration/007-expenseseSchema.yaml, odpowiada 'purchaseDate', znak '_' można traktować jako informację, że litera stojąca za tym znakiem będzie literą wielką, w polu klasy, czyli 'd' zmieni się w 'D', już bez '_' w polu klasy

HINT: przy pobieraniu wszystkich wydatków, możesz sprawdzić jak zachowa się logika, gdy w bazie danych będzie występował drugi użytkownik, czyli dodania nowego wydatku dla innego usera

Robert Szczygielski Dice Dev. Polityka Prywatności i Regulamin Szkoleń Online

Strona www stworzona w kreatorze WebWave.