Комментарии 7
Классная статья, спасибо! Сколько прогон длится? Как ускоряете? Flaky-тесты есть? :)
спасибо, хорошие вопросы!
Прогон на разных сервисах длится по-разному, самый масштабный и сложный 1 час. Сейчас в нем 1980 тестов, из которых flaky тестов 3 штуки.
Ускорили несколько месяцев назад путем параллелизации read only тестов, уменьшения числа рестартов сервисов с помощью группировки тестов на сервис с одной конфигурацией, переписали некоторые тесты, упростив сам сценарий. Общее время сократилось с 1ч 20мин до 1часа
Прогон на разных сервисах длится по-разному, самый масштабный и сложный 1 час. Сейчас в нем 1980 тестов, из которых flaky тестов 3 штуки.
Ускорили несколько месяцев назад путем параллелизации read only тестов, уменьшения числа рестартов сервисов с помощью группировки тестов на сервис с одной конфигурацией, переписали некоторые тесты, упростив сам сценарий. Общее время сократилось с 1ч 20мин до 1часа
Не рассматривали ли вариант не делать вообще интеграционные тесты, а ограничиться функциональными/юнит тестами на отказы внешних сервисов? Как много встречается на практике таких интеграционных багов, которые такие функциональные тесты бы не нашли?
Рассматривали, часть тестов у нас как раз юнит и функциональные. По возможности стараемся добавлять тесты именно туда.
Почему пошли в сторону интеграционных тестов:
— При написании функциональных и юнит тестов можно не учесть flow запросов / действий сервисов и не покрыть сценарии. Поскольку сервисов много и нужно в голове четко представлять какой алгоритм взаимодействия, при написании теста и во время ревью можно пропустить сценарии. В интеграционных тестах flow запросов/действий системы отрабатывает полностью. Мы запускаем всю инфраструктуру, создаем ситуацию, дальше система сама отрабатывает flow.
— В каких-то случаях сложно написать корректные юнит и функциональные тесты. Например, если есть большой сервис со сложным кодом, иногда для написания тестов нужно полностью зарефакторить код. Это трудоемкая задача.
— Проверить взаимодействие какой-то части кода (модуля) сервиса и библиотеки, которую использует сервис, может быть проблематично без старта сервиса и инфраструктуры. Например, нужно проверить как сервис реагирует на переполнение буфера в библиотеке, которая пишет в Кафку. Мы можем написать тест, в котором подменим все вызовы библиотеки на свои и зная способ оповещения о переполнении буфера, который реализован в библиотеке, оповестим наш сервис о переполнении. Тут нужно знать детали реализации библиотеки, что усложняет написание теста. По сути мы мокаем библиотеку, а значит в более сложных сценариях мы можем просто не правильно воспроизвести последовательность действий и будем проверять не то, либо не будем проверять вовсе. В этом случае проще написать интеграционный тест, который поднимет сервис и Кафку, создаст сетевую проблему, подождет ожидаемое время, разблокирует доступ в Кафку и проверит, что данные отправились/записались на диск/применились в памяти.
— Можно написать по функциональному тесту на сервисы, но допустить ошибку в одном из них. Или обновить тест только на один сервис и забыть обновить на второй. При этом тесты будут проходить, а на devel’e не поднимутся сервисы. Пример: нужно проверить, что при старте сервис корректно регистрируется в Consul, а другие сервисы подхватывают это. В интеграционном тесте ошибка сразу отловится. Причем если меняется формат данных при регистрации сервиса в Consul, не нужно переписывать интеграционный тест в отличие от функционального.
Не могу сказать как много на практике встречается таких интеграционных багов, которые функциональные тесты не нашли тк не считала. А чтобы прикинуть, нужно перечитать наши 1980 тестов и посмотреть) Опять же, иногда выгоднее написать интеграционный тест тк это быстрее, чем N функциональных с моком библиотек и рефакторингом. Нужно понимать, что интеграционные тесты лучше всего подходят для распределенных систем, которые состоят из многих отдельных сервисов и именно на такие кейсы наш фреймворк идеально ложится.
Почему пошли в сторону интеграционных тестов:
— При написании функциональных и юнит тестов можно не учесть flow запросов / действий сервисов и не покрыть сценарии. Поскольку сервисов много и нужно в голове четко представлять какой алгоритм взаимодействия, при написании теста и во время ревью можно пропустить сценарии. В интеграционных тестах flow запросов/действий системы отрабатывает полностью. Мы запускаем всю инфраструктуру, создаем ситуацию, дальше система сама отрабатывает flow.
— В каких-то случаях сложно написать корректные юнит и функциональные тесты. Например, если есть большой сервис со сложным кодом, иногда для написания тестов нужно полностью зарефакторить код. Это трудоемкая задача.
— Проверить взаимодействие какой-то части кода (модуля) сервиса и библиотеки, которую использует сервис, может быть проблематично без старта сервиса и инфраструктуры. Например, нужно проверить как сервис реагирует на переполнение буфера в библиотеке, которая пишет в Кафку. Мы можем написать тест, в котором подменим все вызовы библиотеки на свои и зная способ оповещения о переполнении буфера, который реализован в библиотеке, оповестим наш сервис о переполнении. Тут нужно знать детали реализации библиотеки, что усложняет написание теста. По сути мы мокаем библиотеку, а значит в более сложных сценариях мы можем просто не правильно воспроизвести последовательность действий и будем проверять не то, либо не будем проверять вовсе. В этом случае проще написать интеграционный тест, который поднимет сервис и Кафку, создаст сетевую проблему, подождет ожидаемое время, разблокирует доступ в Кафку и проверит, что данные отправились/записались на диск/применились в памяти.
— Можно написать по функциональному тесту на сервисы, но допустить ошибку в одном из них. Или обновить тест только на один сервис и забыть обновить на второй. При этом тесты будут проходить, а на devel’e не поднимутся сервисы. Пример: нужно проверить, что при старте сервис корректно регистрируется в Consul, а другие сервисы подхватывают это. В интеграционном тесте ошибка сразу отловится. Причем если меняется формат данных при регистрации сервиса в Consul, не нужно переписывать интеграционный тест в отличие от функционального.
Не могу сказать как много на практике встречается таких интеграционных багов, которые функциональные тесты не нашли тк не считала. А чтобы прикинуть, нужно перечитать наши 1980 тестов и посмотреть) Опять же, иногда выгоднее написать интеграционный тест тк это быстрее, чем N функциональных с моком библиотек и рефакторингом. Нужно понимать, что интеграционные тесты лучше всего подходят для распределенных систем, которые состоят из многих отдельных сервисов и именно на такие кейсы наш фреймворк идеально ложится.
Классная статья!
Мы сейчас как раз пытаемся сделать интеграционные тесты, пока что только апи тесты и они на тестовом окружении со всей обвязкой, работают по 8 часов в несколько потоков.
Спасибо за статью, думаю, много чего сможем использовать ( в первую очередь инфраструктуру)
Мы сейчас как раз пытаемся сделать интеграционные тесты, пока что только апи тесты и они на тестовом окружении со всей обвязкой, работают по 8 часов в несколько потоков.
Спасибо за статью, думаю, много чего сможем использовать ( в первую очередь инфраструктуру)
После того, как я в 5ый раз написал фреймворк для тестирования перейдя в новую компанию, я пришёл к выводу, что не нужно писать код для тестирования кода. К тому же это дополнительные требования при найме QA (в вашем случае — го).
Рекоммендую посмотреть на готовый фреймворк Catcher — для микросервисов и дата пайплайнов самое то. Тест по шагам описывается в yaml. Куча готовых шагов + возможность писать свои. Мы в компании на него перешли с собственного велосипеда. Скорость деливери увеличилась.
Рекоммендую посмотреть на готовый фреймворк Catcher — для микросервисов и дата пайплайнов самое то. Тест по шагам описывается в yaml. Куча готовых шагов + возможность писать свои. Мы в компании на него перешли с собственного велосипеда. Скорость деливери увеличилась.
не поленился, нашёл свою статью, в которой рассказывал про разные уровни тестирования микросервисов. Вы находитесь на втором :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система под контролем: как автоматизировать интеграционные тесты