Сообщение Re: Как тестировать серверные сервисные приложения? от 16.12.2022 14:00
Изменено 16.12.2022 14:05 gyraboo
Re: Как тестировать серверные сервисные приложения?
Здравствуйте, vsb, Вы писали:
vsb>Имеется приложение. При старте запускает веб-сервер. Для работы использует СУБД. Принимает некие HTTP запросы с JSON телами и отвечает так же. Также само запрашивает некоторые другие сервисы по HTTP. Также в будущем будет работать с Rabbit MQ.
vsb>Хочется понять, как такое приложение тестировать на верхнем уровне.
vsb>Сейчас это делается юнит-тестами. Запускается несколько мок-серверов, запускается при старте теста БД, в эту БД код кладёт начальные данные, вызывает нужные эндпоинты, в конце проверяет, вызывались ли нужные эндпоинты у мок-серверов, проверяет, изменились ли данные в БД.
vsb>Проблема в том, что эти тесты очень муторно писать. Разработчики их писать ленятся, не-разработчики таким скиллом не обладают по-большому счёту.
vsb>Задача мне кажется типовой и достаточно универсальной. Но не очень понимаю, как гуглить.
Согласен, мокание — это зло. Я последние пару лет пришёл к такому способу: интегротесты сами с помощью библиотеки TestContainers подымают реальное приложение сервиса и реальную БД в докере, и прогоняют все тесты без моков. Типичный интегротест выглядит так:
1. Подготовит фикстуру (тестовые данные в БД)
2. Отправить в сервис запрос
3. Получить респонз и сравнить его с json-файлом ожидаемого респонза (сравнение происходит с помощью библиотеки javacrumbs.jsonunit)
Важно отметить 2 принципиальных момента:
— моков по возможности нет
— сравнение происходит "полное" json-файлов, а не "точечное" объектов DTO
Это позволяет писать малое количество простых и понятных тестов, покрывающих максимум кода.
И читать и поддерживать такие тесты проще, т.к. они простые и тупые как пробка, без моков и ада точечных сравнений.
Такие тесты также служат наглядным руководством к сервису, т.к. четко видно. что мы отсылаем в сервис и что ожидаем.
Ещё удобно то, что коммиты в expected json-файлы наглядко показывают, что меняется в сервисе с токи зрения конечного потребителя.
Также этот подход позволяет тестировать ситуации с транзакциями и блокировками, т.к. тесты работают против реальной БД и реального сервиса, с реально поднятым "настоящим" TX-манагером. На моках, на базе H2, на тестовых профилях и прочих упрощениях тестирование таких кейсов практически нереально.
vsb>Имеется приложение. При старте запускает веб-сервер. Для работы использует СУБД. Принимает некие HTTP запросы с JSON телами и отвечает так же. Также само запрашивает некоторые другие сервисы по HTTP. Также в будущем будет работать с Rabbit MQ.
vsb>Хочется понять, как такое приложение тестировать на верхнем уровне.
vsb>Сейчас это делается юнит-тестами. Запускается несколько мок-серверов, запускается при старте теста БД, в эту БД код кладёт начальные данные, вызывает нужные эндпоинты, в конце проверяет, вызывались ли нужные эндпоинты у мок-серверов, проверяет, изменились ли данные в БД.
vsb>Проблема в том, что эти тесты очень муторно писать. Разработчики их писать ленятся, не-разработчики таким скиллом не обладают по-большому счёту.
vsb>Задача мне кажется типовой и достаточно универсальной. Но не очень понимаю, как гуглить.
Согласен, мокание — это зло. Я последние пару лет пришёл к такому способу: интегротесты сами с помощью библиотеки TestContainers подымают реальное приложение сервиса и реальную БД в докере, и прогоняют все тесты без моков. Типичный интегротест выглядит так:
1. Подготовит фикстуру (тестовые данные в БД)
2. Отправить в сервис запрос
3. Получить респонз и сравнить его с json-файлом ожидаемого респонза (сравнение происходит с помощью библиотеки javacrumbs.jsonunit)
Важно отметить 2 принципиальных момента:
— моков по возможности нет
— сравнение происходит "полное" json-файлов, а не "точечное" объектов DTO
Это позволяет писать малое количество простых и понятных тестов, покрывающих максимум кода.
И читать и поддерживать такие тесты проще, т.к. они простые и тупые как пробка, без моков и ада точечных сравнений.
Такие тесты также служат наглядным руководством к сервису, т.к. четко видно. что мы отсылаем в сервис и что ожидаем.
Ещё удобно то, что коммиты в expected json-файлы наглядко показывают, что меняется в сервисе с токи зрения конечного потребителя.
Также этот подход позволяет тестировать ситуации с транзакциями и блокировками, т.к. тесты работают против реальной БД и реального сервиса, с реально поднятым "настоящим" TX-манагером. На моках, на базе H2, на тестовых профилях и прочих упрощениях тестирование таких кейсов практически нереально.
Re: Как тестировать серверные сервисные приложения?
Здравствуйте, vsb, Вы писали:
vsb>Имеется приложение. При старте запускает веб-сервер. Для работы использует СУБД. Принимает некие HTTP запросы с JSON телами и отвечает так же. Также само запрашивает некоторые другие сервисы по HTTP. Также в будущем будет работать с Rabbit MQ.
vsb>Хочется понять, как такое приложение тестировать на верхнем уровне.
vsb>Сейчас это делается юнит-тестами. Запускается несколько мок-серверов, запускается при старте теста БД, в эту БД код кладёт начальные данные, вызывает нужные эндпоинты, в конце проверяет, вызывались ли нужные эндпоинты у мок-серверов, проверяет, изменились ли данные в БД.
vsb>Проблема в том, что эти тесты очень муторно писать. Разработчики их писать ленятся, не-разработчики таким скиллом не обладают по-большому счёту.
vsb>Задача мне кажется типовой и достаточно универсальной. Но не очень понимаю, как гуглить.
Согласен, мокание — это зло. Я последние пару лет пришёл к такому способу: интегротесты сами с помощью библиотеки TestContainers подымают реальное приложение сервиса и реальную БД в докере, и прогоняют все тесты без моков. Типичный интегротест выглядит так:
1. Подготовить фикстуру (тестовые данные в БД)
2. Отправить в сервис REST-запрос
3. Получить респонз и сравнить его с json-файлом ожидаемого респонза (сравнение происходит с помощью библиотеки javacrumbs.jsonunit)
Важно отметить 2 принципиальных момента:
— моков по возможности нет
— сравнение происходит "полное" json-файлов, а не "точечное" объектов DTO
Это позволяет писать малое количество простых и понятных тестов, покрывающих максимум кода.
И читать и поддерживать такие тесты проще, т.к. они простые и тупые как пробка, без моков и ада точечных сравнений.
Такие тесты также служат наглядным руководством к сервису, т.к. четко видно. что мы отсылаем в сервис и что ожидаем.
Ещё удобно то, что коммиты в expected json-файлы наглядко показывают, что меняется в сервисе с токи зрения конечного потребителя.
Также этот подход позволяет тестировать ситуации с транзакциями и блокировками, т.к. тесты работают против реальной БД и реального сервиса, с реально поднятым "настоящим" TX-манагером. На моках, на базе H2, на тестовых профилях и прочих упрощениях тестирование таких кейсов практически нереально.
vsb>Имеется приложение. При старте запускает веб-сервер. Для работы использует СУБД. Принимает некие HTTP запросы с JSON телами и отвечает так же. Также само запрашивает некоторые другие сервисы по HTTP. Также в будущем будет работать с Rabbit MQ.
vsb>Хочется понять, как такое приложение тестировать на верхнем уровне.
vsb>Сейчас это делается юнит-тестами. Запускается несколько мок-серверов, запускается при старте теста БД, в эту БД код кладёт начальные данные, вызывает нужные эндпоинты, в конце проверяет, вызывались ли нужные эндпоинты у мок-серверов, проверяет, изменились ли данные в БД.
vsb>Проблема в том, что эти тесты очень муторно писать. Разработчики их писать ленятся, не-разработчики таким скиллом не обладают по-большому счёту.
vsb>Задача мне кажется типовой и достаточно универсальной. Но не очень понимаю, как гуглить.
Согласен, мокание — это зло. Я последние пару лет пришёл к такому способу: интегротесты сами с помощью библиотеки TestContainers подымают реальное приложение сервиса и реальную БД в докере, и прогоняют все тесты без моков. Типичный интегротест выглядит так:
1. Подготовить фикстуру (тестовые данные в БД)
2. Отправить в сервис REST-запрос
3. Получить респонз и сравнить его с json-файлом ожидаемого респонза (сравнение происходит с помощью библиотеки javacrumbs.jsonunit)
Важно отметить 2 принципиальных момента:
— моков по возможности нет
— сравнение происходит "полное" json-файлов, а не "точечное" объектов DTO
Это позволяет писать малое количество простых и понятных тестов, покрывающих максимум кода.
И читать и поддерживать такие тесты проще, т.к. они простые и тупые как пробка, без моков и ада точечных сравнений.
Такие тесты также служат наглядным руководством к сервису, т.к. четко видно. что мы отсылаем в сервис и что ожидаем.
Ещё удобно то, что коммиты в expected json-файлы наглядко показывают, что меняется в сервисе с токи зрения конечного потребителя.
Также этот подход позволяет тестировать ситуации с транзакциями и блокировками, т.к. тесты работают против реальной БД и реального сервиса, с реально поднятым "настоящим" TX-манагером. На моках, на базе H2, на тестовых профилях и прочих упрощениях тестирование таких кейсов практически нереально.