После того, как я в 5ый раз написал фреймворк для тестирования перейдя в новую компанию, я пришёл к выводу, что не нужно писать код для тестирования кода. К тому же это дополнительные требования при найме QA (в вашем случае — го).
Рекоммендую посмотреть на готовый фреймворк Catcher — для микросервисов и дата пайплайнов самое то. Тест по шагам описывается в yaml. Куча готовых шагов + возможность писать свои. Мы в компании на него перешли с собственного велосипеда. Скорость деливери увеличилась.
Можно протестировать всю систему.
Разумеется каждый сервис в цепи задействованных сервисов изменяет данные по результатам своей работы (база/MQ/ftp/письмо). Catcher позволяет проверить любое изменение в базе данных или очереди сообщений с помощью соответствующих модулей.
В моем проекте на определенные запросы регистрации REST бэкэнд меняет данные в базе и/или посылает сообщения в кафку. Далее сервисы, которые подписаны на этот топик, получают сообщение, делают свои черные дела и пишут данные в базу/ftp/в другой топик. Третьи сервисы получают данные от вторых сервисов и опять что-то делают...
В регистрационном тесте по сообщениям в кафке и данным в базах я проверяю:
Были ли задействаны все необходимые сервисы?
Был ли пользователь реально зарегистрирован, или просто вернулось 200, а банковский счет не создался.
Был ли порядок обработки сообщений правильным или кто-то опять перепутал топики.
Правильно ли сервисы работают с данными, совместимы ли версии и схемы.
Все происходит асинхронно. Но для теста разницы нет. Мы последовательно проверяем выполнение бизнес логики. От начала регистрации до открытия банковского счета и посылки письма пользователю.
Вот тут описан пример такого теста для IOT сервисов. А тут реализован е2е тест с Travis интеграцией.
У вас съехал синтаксис.
Идея хорошая.
Я поставлю ее в очередь. Не вижу ничего сложного в автогенерации тестов для вашего случая.
На данный момент я работаю над Web-UI для упрощения отладки и интеграции с CI.
Спасибо.
У Фаулера хорошо описаны типы тестов. Вот здесь про интеграционные.
На практике, я не использую все те тесты, что он описал, т.к. не вижу смысла. Они часто друг друга дублируют, что не есть хорошо.
Обычно у меня есть:
юнит тесты. Проверяют отдельные сложные алгоритмы (математика и т.п.). Обычно их мало.
функциональные тесты. Проверяют какую-либо бизнес-функцию отдельного сервиса (на service-layer). Все другие сервисы, база данных и внешние сервисы замоккированы.
интеграционные тесты. Проверяют всю бизнес-логику по принципу черного ящика без моков базы данных и service layer. Внешние зависимости все еще замоккированы. Можно относиться к ним, как к Controller тестам с реальным service layer и базой данных, но заглушками для внешних сервисов, если мы говорим об http-бэкэндах
end-to-end тесты. Проверяют основную бизнес логику вместе со всеми зависимыми сервисами.
Первые 3 запускаются при изменении кода и локально. Для запуска им особо ничего не нужно (интеграционным нужна база данных/кеш, CI запускает через docker-compose).
Последние обычно запускаются на тестовом окружении (либо полностью поднимая все окружение в docker-compose, что может быть нереально) и им нужны все сервисы, задействованные в тесте (это главное отличие от интеграционных). Их время выполнения намного превышает все предыдущие вместе взятые.
3-4 теста быстрее написать на любом скриптовом ЯП. Однако, через несколько лет к этим тестам добавятся еще тесты.
А еще через несколько лет в коде будет мешанина из-за бизнес логики тестов и реализации шагов (в 2ух компаниях уже на такое натыкался). И по итогу будет рефакторинг всего велосипеда, для разделения бизнес логики (увеличение читаемости и поддерживаемости самих тестов) и реализации доступа к сервисам/базам/другим компонентам.
Вот я и подумал, хочу ли я каждый раз изобретать кэтчер. Всего 4 таких тулза и я понял, что лучше что-то сделать 1 раз, чем каждый раз писать с 0.
Ну и польза для других опять таки. У меня сейчас 3-4 теста, а у кого-то, может, под 40.
Верно.
Я лишь сделал упор на большое количество стандартных модулей и легкость их добавления, чтобы минимизировать количество кода, который должен написать конечный пользователь.
В идеале пользователь просто пишет свой тест, не задумываясь о необходимости что-то программировать, т.к. все модули уже написаны.
Можно без проблем реализовать все интеграционные тесты на питоне\руби\баш. Я описал этот вариант в статье.
Разница в том, что:
* DSL кэтчера — это стандартный json/yaml, который знает большинство.
* Тестируемая логика не зашита в сам инструмент тестирования. По моему опыту, года через 4 скриптовой ЯП с тестами будет напоминать кашу бизнес логики и реализации шагов (драйверы доступа к базам, очередям, хранилищам). И разработчик так или иначе попытается отделить реализацию от бизнес логики. Т.о. каждый, кто начнет со скриптового ЯП в итоге закончит своим собственным кэтчером.
1. в текущей компании 2 интеграционных теста, которые проверяют взаимодействие 5и сервисов (не так много тестировать). В предыдущей было 3-4 теста (я только начал применять там этот инструмент) для проверки взаимодействия 10+ сервисов.
2. мы используем только этот инструмент для e2e, однако он не включает проверку фронтенда (на данный момент у нас нет нормальных тестов для фронтенда). Также не стоит путать юнит/интеграционные тесты и е2е. Все разработчики пишут юнит/интеграционные тесты, каждый стандартную технологию своего ЯП (pyunit/pytest/junit/eunit...). Но только избранные пишут е2е тесты, т.к. это трудоемкий процесс, требующий понимания всей бизнес-логики.
3. использую этот инструмент уже около года, с тех пор как он появился.
4. да, требуется знание DSL кэтчера. Однако, он не привязан к какому-либо ЯП и по сути это просто стандартный yaml/json + спецификации шагов. Я специально сделал кэтчер простым и расширяемым. Свой первый тест можно написать за несколько минут.
5. не путайте е2е и интеграционные тесты. Вторые находятся непосредственно в бэкэнде и реализуются на стандартных технологиях для своего ЯП, с ассертом и моками. Запускаются на пул реквест при изменении этого бэкэнда и ничего не знают о зависимых сервисах (только моки). е2е же запускается сам по себе, обычно после деплоя на дев, либо по таймеру периодически и проверяет все сервисы в системе. Он изолирован от кода и тестирует API по принципу черного ящика.
Увы, сторонние компании работают таким же образом. Их сервера ждут url первой сессии и считают установку. И эту url также можно подделать.
К тому же, в большинстве случаев библиотека сторонних компаний трекинга использует свой секрет и id, что заставляет разработчика указвать их в коде.
Описанная проблема открывает не уязвимость трекинга установок, а невозможность безопасного хранения каких-либо данных на устройстве. А без этих данных (секреты и id) трекинг работать не будет.
Проверки по айпишникам это хороший выход, однако — не всегда действенный. Первое — злоумышленник может использовать распределённую сеть для атаки. Второе — торговые центры с wifi точками доступа также будут являться запросами с одного айпишника. Злоумышленнику нужно лишь не превысить количество запросов из торгового центра.
Касаемо вашей идеи — я здесь рассматривал интерес рекламной сети и разработчика приложения, игнорируя пользователей. Если разработчик в своём приложении реализует скрытое нажатие баннера, то это переведёт его из категории разработчик в категорию злоумышленник, т.к. рекламодатель, который платит реальные деньги за показ баннера заплатит за несуществующий показ.
Рекоммендую посмотреть на готовый фреймворк Catcher — для микросервисов и дата пайплайнов самое то. Тест по шагам описывается в yaml. Куча готовых шагов + возможность писать свои. Мы в компании на него перешли с собственного велосипеда. Скорость деливери увеличилась.
Можно протестировать всю систему.
Разумеется каждый сервис в цепи задействованных сервисов изменяет данные по результатам своей работы (база/MQ/ftp/письмо). Catcher позволяет проверить любое изменение в базе данных или очереди сообщений с помощью соответствующих модулей.
В моем проекте на определенные запросы регистрации REST бэкэнд меняет данные в базе и/или посылает сообщения в кафку. Далее сервисы, которые подписаны на этот топик, получают сообщение, делают свои черные дела и пишут данные в базу/ftp/в другой топик. Третьи сервисы получают данные от вторых сервисов и опять что-то делают...
В регистрационном тесте по сообщениям в кафке и данным в базах я проверяю:
Все происходит асинхронно. Но для теста разницы нет. Мы последовательно проверяем выполнение бизнес логики. От начала регистрации до открытия банковского счета и посылки письма пользователю.
Вот тут описан пример такого теста для IOT сервисов. А тут реализован е2е тест с Travis интеграцией.
Идея хорошая.
Я поставлю ее в очередь. Не вижу ничего сложного в автогенерации тестов для вашего случая.
На данный момент я работаю над Web-UI для упрощения отладки и интеграции с CI.
Спасибо.
У Фаулера хорошо описаны типы тестов. Вот здесь про интеграционные.
На практике, я не использую все те тесты, что он описал, т.к. не вижу смысла. Они часто друг друга дублируют, что не есть хорошо.
Обычно у меня есть:
Первые 3 запускаются при изменении кода и локально. Для запуска им особо ничего не нужно (интеграционным нужна база данных/кеш, CI запускает через docker-compose).
Последние обычно запускаются на тестовом окружении (либо полностью поднимая все окружение в docker-compose, что может быть нереально) и им нужны все сервисы, задействованные в тесте (это главное отличие от интеграционных). Их время выполнения намного превышает все предыдущие вместе взятые.
А еще через несколько лет в коде будет мешанина из-за бизнес логики тестов и реализации шагов (в 2ух компаниях уже на такое натыкался). И по итогу будет рефакторинг всего велосипеда, для разделения бизнес логики (увеличение читаемости и поддерживаемости самих тестов) и реализации доступа к сервисам/базам/другим компонентам.
Вот я и подумал, хочу ли я каждый раз изобретать кэтчер. Всего 4 таких тулза и я понял, что лучше что-то сделать 1 раз, чем каждый раз писать с 0.
Ну и польза для других опять таки. У меня сейчас 3-4 теста, а у кого-то, может, под 40.
Я лишь сделал упор на большое количество стандартных модулей и легкость их добавления, чтобы минимизировать количество кода, который должен написать конечный пользователь.
В идеале пользователь просто пишет свой тест, не задумываясь о необходимости что-то программировать, т.к. все модули уже написаны.
Разница в том, что:
* DSL кэтчера — это стандартный json/yaml, который знает большинство.
* Тестируемая логика не зашита в сам инструмент тестирования. По моему опыту, года через 4 скриптовой ЯП с тестами будет напоминать кашу бизнес логики и реализации шагов (драйверы доступа к базам, очередям, хранилищам). И разработчик так или иначе попытается отделить реализацию от бизнес логики. Т.о. каждый, кто начнет со скриптового ЯП в итоге закончит своим собственным кэтчером.
2. мы используем только этот инструмент для e2e, однако он не включает проверку фронтенда (на данный момент у нас нет нормальных тестов для фронтенда). Также не стоит путать юнит/интеграционные тесты и е2е. Все разработчики пишут юнит/интеграционные тесты, каждый стандартную технологию своего ЯП (pyunit/pytest/junit/eunit...). Но
только избранныепишут е2е тесты, т.к. это трудоемкий процесс, требующий понимания всей бизнес-логики.3. использую этот инструмент уже около года, с тех пор как он появился.
4. да, требуется знание DSL кэтчера. Однако, он не привязан к какому-либо ЯП и по сути это просто стандартный yaml/json + спецификации шагов. Я специально сделал кэтчер простым и расширяемым. Свой первый тест можно написать за несколько минут.
5. не путайте е2е и интеграционные тесты. Вторые находятся непосредственно в бэкэнде и реализуются на стандартных технологиях для своего ЯП, с ассертом и моками. Запускаются на пул реквест при изменении этого бэкэнда и ничего не знают о зависимых сервисах (только моки). е2е же запускается сам по себе, обычно после деплоя на дев, либо по таймеру периодически и проверяет все сервисы в системе. Он изолирован от кода и тестирует API по принципу черного ящика.
К тому же, в большинстве случаев библиотека сторонних компаний трекинга использует свой секрет и id, что заставляет разработчика указвать их в коде.
Описанная проблема открывает не уязвимость трекинга установок, а невозможность безопасного хранения каких-либо данных на устройстве. А без этих данных (секреты и id) трекинг работать не будет.
Касаемо вашей идеи — я здесь рассматривал интерес рекламной сети и разработчика приложения, игнорируя пользователей. Если разработчик в своём приложении реализует скрытое нажатие баннера, то это переведёт его из категории разработчик в категорию злоумышленник, т.к. рекламодатель, который платит реальные деньги за показ баннера заплатит за несуществующий показ.