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