Jak się zabrać za junit testy dla filtrów

Witam,

Piszę program zadany przez jedną z firm w procesie rekrutacji na juniora.
Dla zainteresowanych, kod dostępny tu: https://github.com/mariusz-lesko/interview1_BankAccountProcessor

Program ma za zadanie wczytać listę kont bankowych z pliku xml następnie ją przefiltrować według kilku kryteriów.
Pozostałe po filtrowaniu konta ma przesortować i zapisać do nowego pliku xml.

Program mam napisany, działa (parę rzeczy mi się jeszcze nie podoba i są do poprawy ale nie o tym ten post ;) ). Z tym nie mam problemu.
Natomiast mam problem z tym, jak sensownie napisać junit testy dla filtrów.

Filtry napisałem jako małe klasy, które są składane w łańcuch za pomocą buildera a następnie wykonywane na liście kont bankowych.

I teraz problem: jak sensownie napisać testy dla tych klas/filtrów?

a) w setUp składać obiekty z xmla ze stringa na których wykonywane będą poszczególne filtry? (dla mnie trochę bez sensu)
b) mocki? jak? mocki czego?
c) ?????

Może Ktoś podpowiedzieć jak powinno się to robić?

Pozdrawiam,
Mariusz

1. Puste repo :)
2. Co ty chcesz mockować? o_O
3. Nie bardzo rozumiem problem. Mam nadzieje ze ładujesz dane z XMLa do jakiejś wewnętrznej reprezentacji, którą to filtrujesz a na koniec serializujesz do XMLa. Więc nie ma problemu żeby zbudować sobie taką reprezentacje (czyli ominąć krok ładowania tego z XMLa, do tego możesz zrobić osobny test) i na niej jednostkowo testować same filtry.
4. Warto też zrobić testy integracyjne/e2e tego rozwiązania -> generujesz losowego xmla z prekonfigurowanymi danymi i sprawdzasz cały flow aplikacji i czy na wyjsciu dostajesz oczekiwany wynik. Najlepiej napisać do tego małego DSLa żeby test czytało sie ładnie, w stylu

// given
TestConfiguration configuration = TestConfiguration.builder()
.withX(...)
.withY(...)
.with...
.build();

FilterConfiguration filters = FilterConfiguration.builder().with....build();

// when
Result result = mainParser.parse(configuration.generateXml(), filters );

// then
assert(result..., configuration...)
assert...

Shalom napisał(a):

1. Puste repo :)

już jest :)

2. Co ty chcesz mockować? o_O

prawdę mówiąc nie mam pojęcia ... kombinuję ;)

3. Nie bardzo rozumiem problem. Mam nadzieje ze ładujesz dane z XMLa do jakiejś wewnętrznej reprezentacji, którą to filtrujesz a na koniec serializujesz do XMLa. Więc nie ma problemu żeby zbudować sobie taką reprezentacje (czyli ominąć krok ładowania tego z XMLa, do tego możesz zrobić osobny test) i na niej jednostkowo testować same filtry.

problemem jest to, że chciał bym przez filtry przepuścić wiele różnych wersji takich reprezentacji (pusta, z danymi nieprawidłowymi, niekompletnymi,...). Zastanawiam się, jak najsensowniej przetestować te filtry przy wielu różnych wariantach danych wejściowych

4. Warto też zrobić testy integracyjne/e2e tego rozwiązania -> generujesz losowego xmla z prekonfigurowanymi danymi i sprawdzasz cały flow aplikacji i czy na wyjsciu dostajesz oczekiwany wynik. Najlepiej napisać do tego małego DSLa żeby test czytało sie ładnie, w stylu

// given
TestConfiguration configuration = TestConfiguration.builder()
.withX(...)
.withY(...)
.with...
.build();

FilterConfiguration filters = FilterConfiguration.builder().with....build();

// when
Result result = mainParser.parse(configuration.generateXml(), filters );

// then
assert(result..., configuration...)
assert...

dzięki ... przemyślę to

....

Po przespanej nocy i przemyśleniu tego jeszcze raz .. rzeczywiście sam nie wiem gdzie widziałem problem.
Poza tym, nie mam pojęcia po co chciałem tworzyć wiele reprezentacji danych wejściowych, toż wszystkie potrzebne warianty danych wejściowych mogę zawrzeć w jednej.

Dzięki i pozdrawiam,
Mariusz