Nowy test w AssetsServiceIntegrationTest jest prawie identyczny jak ten w ExpensesServiceIntergrationTest, metoda shouldThrowExceptionWhenOneOfTheFiltersKey (w Twoim wypadku możesz mieć dwie metody, w tej klasie, które powinny nazywać się podobnie, z zależności o Towjego podejścia i skorzystania z testów sparametryzowanych)

Po skończeniu tego zadnia w logach powinny występować dwa rodzaje logów, o błędzie:

- MissingAssetsFilterException, z komunikatem: "Missing filter key for Assets:"

- MissingExpensesFilterException, z komunikatem: "Missing filter key for Expenses:"

Wyjątek MissingAssetsFilterException będzie identyczny jak MissingExpensesFilterException, różni się jedynie nazwą.

Nowa klasa AssetsFilterParametersValidator, powinna zostać wstrzyknięta do FilterRange, podobnie jak ExpensesFilterParametersValidator.

Jak rozróżnić, którą metodę assertFilter wywołać, czy dla Assets, czy dla Expenses = możesz stworzyć nową abstrakcyjną metodę: getFilterName() w FilterRange - popraw błędyPodczas implementacji ta nowa metoda będzie zwracała String, "AssetsFilter", lub "ExpensesFilter" w zależności od klasy, która implementuje tą metodę

HINT: możesz stworzyć enum dla tych wartości - ale nie jest to konieczne

następnie wywołanie w kodzie może wyglądać podobnie jak pseudokod, dwa if'y:

```

if ("ExpensesFilter".equals(getFilterName())) expensesFilterParametersValidator.assertFilter(filter)

if ("AssetsFilter".equals(getFilterName())) assetsFilterParametersValidator.assertFilter(filter)

```

Stworzyłeś dwie pełnoprawne Fabryki: FilgerParametersValidator oraz FilterRange ;)

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

Strona www stworzona w kreatorze WebWave.