Testy jednostkowe MessageBoardService

[kkojot]

Cześć,

Po ukończeniu kursu chciałem dodać unit testy klasy MessageBoardService, np. sprawdzające, czy istnieją zdefiniowane topici:

class MessageBoardServiceTest {

    @Test
    public void messageBoardShouldHaveAllPredefinedTopics() {
        MessageBoardService service = new MessageBoardService();

        assertTrue(doesTopicExist(service, "test"));
        assertTrue(doesTopicExist(service, "general"));
        assertTrue(doesTopicExist(service, "java"));
    }

    @Test
    public void messageBoardShouldNotHaveUndefinedTopics() {
        MessageBoardService service = new MessageBoardService();

        assertFalse(doesTopicExist(service, "undefined"));
        assertFalse(doesTopicExist(service, ""));
    }

    private boolean doesTopicExist(MessageBoardService service, String topicName) {
        Option<Topic> topic = service.getTopic(topicName);
        return !topic.isEmpty();
    }

}

Niestety, testowanie tej klasy jest uciążliwe, bo musimy poczekać aż cały kontekst Springa wystartuje, a to trwa bardzo długo w porównaniu do testów w czystej Javie. Do tego próby testów metody addMessageToTopic(String topicName, Message newMsg) kończą się trwałym zapisem zmian w bazie danych. Rozwiązania jakie mi przychodzą do głowy:

1. Mockowanie - słabe, bo testy będą się nadal długo wykonywać, co wraz z rozrostem projektu doprowadzi do zaniechania pisania testów w ogóle
2. Wydzielenie metoda init() ładującą kontekst Springa - głupie, komplikowanie kodu tylko ze względu na testy
3. Nie pisanie testów takich klas w ogóle ;)

@jarekratajski co polecisz?

[jarekratajski]

Cześć! Dzięki za kontakt. Pytanie bardzo dobre i postaram się odpisać. Gdzieś w pn, wtorek. nie mam teraz warunków.

…

On Fri, 26 Oct 2018, 14:12 Wojtek, ***@***.***> wrote: Cześć, Po ukończeniu kursu chciałem dodać unit testy klasy MessageBoardService, np. sprawdzające, czy istnieją zdefiniowane topici: class MessageBoardServiceTest { @test public void messageBoardShouldHaveAllPredefinedTopics() { MessageBoardService service = new MessageBoardService(); assertTrue(doesTopicExist(service, "test")); assertTrue(doesTopicExist(service, "general")); assertTrue(doesTopicExist(service, "java")); } @test public void messageBoardShouldNotHaveUndefinedTopics() { MessageBoardService service = new MessageBoardService(); assertFalse(doesTopicExist(service, "undefined")); assertFalse(doesTopicExist(service, "")); } private boolean doesTopicExist(MessageBoardService service, String topicName) { Option<Topic> topic = service.getTopic(topicName); return !topic.isEmpty(); } } Niestety, testowanie tej klasy jest uciążliwe, bo musimy poczekać aż cały kontekst Springa wystartuje, a to trwa bardzo długo w porównaniu do testów w czystej Javie. Do tego próby testów metody addMessageToTopic(String topicName, Message newMsg) kończą się trwałym zapisem zmian w bazie danych. Rozwiązania jakie mi przychodzą do głowy: 1. Mockowanie - słabe, bo testy będą się nadal długo wykonywać, co wraz z rozrostem projektu doprowadzi do zaniechania pisania testów w ogóle 2. Wydzielenie metoda init() ładującą kontekst Springa - głupie, komplikowanie kodu tylko ze względu na testy 3. Nie pisanie testów takich klas w ogóle ;) @jarekratajski <https://github.com/jarekratajski> co polecisz? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGBjCLx2alG-1x7yqMI0XUxfCkOi2RLGks5uovxDgaJpZM4X8HEM> . On Fri, 26 Oct 2018, 14:12 Wojtek, ***@***.***> wrote: Cześć, Po ukończeniu kursu chciałem dodać unit testy klasy MessageBoardService, np. sprawdzające, czy istnieją zdefiniowane topici: class MessageBoardServiceTest { @test public void messageBoardShouldHaveAllPredefinedTopics() { MessageBoardService service = new MessageBoardService(); assertTrue(doesTopicExist(service, "test")); assertTrue(doesTopicExist(service, "general")); assertTrue(doesTopicExist(service, "java")); } @test public void messageBoardShouldNotHaveUndefinedTopics() { MessageBoardService service = new MessageBoardService(); assertFalse(doesTopicExist(service, "undefined")); assertFalse(doesTopicExist(service, "")); } private boolean doesTopicExist(MessageBoardService service, String topicName) { Option<Topic> topic = service.getTopic(topicName); return !topic.isEmpty(); } } Niestety, testowanie tej klasy jest uciążliwe, bo musimy poczekać aż cały kontekst Springa wystartuje, a to trwa bardzo długo w porównaniu do testów w czystej Javie. Do tego próby testów metody addMessageToTopic(String topicName, Message newMsg) kończą się trwałym zapisem zmian w bazie danych. Rozwiązania jakie mi przychodzą do głowy: 1. Mockowanie - słabe, bo testy będą się nadal długo wykonywać, co wraz z rozrostem projektu doprowadzi do zaniechania pisania testów w ogóle 2. Wydzielenie metoda init() ładującą kontekst Springa - głupie, komplikowanie kodu tylko ze względu na testy 3. Nie pisanie testów takich klas w ogóle ;) @jarekratajski <https://github.com/jarekratajski> co polecisz? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGBjCLx2alG-1x7yqMI0XUxfCkOi2RLGks5uovxDgaJpZM4X8HEM> .

[jarekratajski]

Cześć! Przepraszam, bo trochęmi zajęło. MIałem nieco zajęć. Na pewno praktycznie warto by zrobić osobną baze na testy: w src/test/resources dodać application.properties z zawartością typu: spring.data.mongodb.database= myTestDb a w /src/main/respurces/application.properties spring.data.mongodb.database= myRealDB (jak nie ma takiego wpisu to domyślnie wpisuje do bazy o nazwie `test`) Mockowanie, generalnie uważam w tym (konkretnym) przypadku za słabe - bo nie pokaże potencjalnych, faktycznych problemów (np. że jakiś obiekt nie da sie zserializować do mongo). Ale wtedy wstawanie kontektu springowego jest długie i nie mam na to rady :-( Gdyby logiki w aplikacji było więcej ,to wtedy jakiś mock CrudRepository miałby sens: Można by wydzielić tworzenie MongoRepository i dać możliwość podania jako zależności w konstruktorze: ``` MessageBoardService(CrudRepository<BoardMessage, Long> mongoRepository) { ``` Niestety, z tego co wiem, nie ma springu jakieśgo repo typo InMemoryCrudRepository, którego możnaby podać w miejsce MongoRepository :-( I który pokazywałby te same potencjalne problemy. Taki mock miałaby sens, gdyby tej logiki javowej w serwisie było więcej. W praktyce tak bywa, i często mam takie mock repository (które pod spodem mają np. HashMapę). De fakto to nawet nie są mocki, tylko własne InMemRepository i robię je najpierw, zanim się przypnę do prawdziwej bazy danych. Dopiero jak mam logikę przetestowaną na InMemRepository (częściej nazwywam XYZDataProvider) to robię wersję korzystającą z realnej bazy danych i robię testy na bazie . Czasem dokładnie te same, robię abstrakcyjną klasę bazową dla testów i dwie implementacje z dwiema konfiuracjami Repo, przez to widze, które błedy wynikają ze złej logiki, a które z np. błednego/technicznego zapisu do bazy danych). Pozdrawiam, Jarek

…

On Fri, Oct 26, 2018 at 3:00 PM Jarek Ratajski ***@***.***> wrote: Cześć! Dzięki za kontakt. Pytanie bardzo dobre i postaram się odpisać. Gdzieś w pn, wtorek. nie mam teraz warunków. On Fri, 26 Oct 2018, 14:12 Wojtek, ***@***.***> wrote: > Cześć, > > Po ukończeniu kursu chciałem dodać unit testy klasy MessageBoardService, > np. sprawdzające, czy istnieją zdefiniowane topici: > > class MessageBoardServiceTest { > > @test > public void messageBoardShouldHaveAllPredefinedTopics() { > MessageBoardService service = new MessageBoardService(); > > assertTrue(doesTopicExist(service, "test")); > assertTrue(doesTopicExist(service, "general")); > assertTrue(doesTopicExist(service, "java")); > } > > @test > public void messageBoardShouldNotHaveUndefinedTopics() { > MessageBoardService service = new MessageBoardService(); > > assertFalse(doesTopicExist(service, "undefined")); > assertFalse(doesTopicExist(service, "")); > } > > private boolean doesTopicExist(MessageBoardService service, String topicName) { > Option<Topic> topic = service.getTopic(topicName); > return !topic.isEmpty(); > } > > } > > > Niestety, testowanie tej klasy jest uciążliwe, bo musimy poczekać aż cały > kontekst Springa wystartuje, a to trwa bardzo długo w porównaniu do testów > w czystej Javie. Do tego próby testów metody addMessageToTopic(String > topicName, Message newMsg) kończą się trwałym zapisem zmian w bazie > danych. Rozwiązania jakie mi przychodzą do głowy: > > 1. Mockowanie - słabe, bo testy będą się nadal długo wykonywać, co > wraz z rozrostem projektu doprowadzi do zaniechania pisania testów w ogóle > 2. Wydzielenie metoda init() ładującą kontekst Springa - głupie, > komplikowanie kodu tylko ze względu na testy > 3. Nie pisanie testów takich klas w ogóle ;) > > @jarekratajski <https://github.com/jarekratajski> co polecisz? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1>, or mute the > thread > <https://github.com/notifications/unsubscribe-auth/AGBjCLx2alG-1x7yqMI0XUxfCkOi2RLGks5uovxDgaJpZM4X8HEM> > . > On Fri, 26 Oct 2018, 14:12 Wojtek, ***@***.***> wrote: > Cześć, > > Po ukończeniu kursu chciałem dodać unit testy klasy MessageBoardService, > np. sprawdzające, czy istnieją zdefiniowane topici: > > class MessageBoardServiceTest { > > @test > public void messageBoardShouldHaveAllPredefinedTopics() { > MessageBoardService service = new MessageBoardService(); > > assertTrue(doesTopicExist(service, "test")); > assertTrue(doesTopicExist(service, "general")); > assertTrue(doesTopicExist(service, "java")); > } > > @test > public void messageBoardShouldNotHaveUndefinedTopics() { > MessageBoardService service = new MessageBoardService(); > > assertFalse(doesTopicExist(service, "undefined")); > assertFalse(doesTopicExist(service, "")); > } > > private boolean doesTopicExist(MessageBoardService service, String topicName) { > Option<Topic> topic = service.getTopic(topicName); > return !topic.isEmpty(); > } > > } > > > Niestety, testowanie tej klasy jest uciążliwe, bo musimy poczekać aż cały > kontekst Springa wystartuje, a to trwa bardzo długo w porównaniu do testów > w czystej Javie. Do tego próby testów metody addMessageToTopic(String > topicName, Message newMsg) kończą się trwałym zapisem zmian w bazie > danych. Rozwiązania jakie mi przychodzą do głowy: > > 1. Mockowanie - słabe, bo testy będą się nadal długo wykonywać, co > wraz z rozrostem projektu doprowadzi do zaniechania pisania testów w ogóle > 2. Wydzielenie metoda init() ładującą kontekst Springa - głupie, > komplikowanie kodu tylko ze względu na testy > 3. Nie pisanie testów takich klas w ogóle ;) > > @jarekratajski <https://github.com/jarekratajski> co polecisz? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1>, or mute the > thread > <https://github.com/notifications/unsubscribe-auth/AGBjCLx2alG-1x7yqMI0XUxfCkOi2RLGks5uovxDgaJpZM4X8HEM> > . >

-- Jaroslaw Ratajski

[kkojot]

Dzięki za odpwiedź ;)

Wpis w application.properties: spring.data.mongodb.database=myRealDb działa mi prawidłowo w typowej springowej aplikacji, niestety przy startowaniu Springa w sposób przedstawiony w kursie propertiesy są ignorowane, wiesz jak temu zaradzić?

Podsumowując:

• wydzielam kod ładujący kontekst Springa z konstruktora klasy MessageBoardService do innej klasy, która zwróci mi mongoRepository typu CrudRepository<BoardMessage, Long>
• dodaję w niej konstruktor MessageBoardService(CrudRepository<BoardMessage, Long> mongoRepository) {
• piszę klasę MessageBoardDataProvider implements CrudRepository<BoardMessage, Long>
• implementuję w niej odpowiednio metody save, findAll itp. i ewentualnie dodaję wewnątrz HashMapę
• testując logikę w klasie MessageBoardService używam MessageBoardDataProvider jako parametr konstruktora
• w MessageBoardApplication za to przekazuję MongoRespository, tutaj też startuję kontekst Springa

Jest trochę klepania, ale podoba mi się. W ten sposób mogę testować logikę przy użyciu szybkich unit testów i nie babrać się ze Springiem.
Poza logiką można dołożyć do tego testy na bazie, żeby sprawdzić czy obiekty się odpowiednio serializują (bo np. ZonedDateTime zapisuje się w jakiejś dziwnej postaci).

Pozdrawiam,
Wojtek.