Комментарии 4
Все круто, но как-то получается, что вокруг автотестов (которые должны помогать) у вас слишком много проблем :) Такими темпами скоро появятся вакансии «Тестировщик фреймворков автотестирования».
Может подумать над корневой причиной — зачем вам часто менять базовый код в фреймворке и почему при изменениях есть риск, что автотесты сломаются?
И еще было бы круто, если бы был инструмент, который анализирует какие регрессионные тесты нужно запустить исходя из изменений в коде продукта!
Может подумать над корневой причиной — зачем вам часто менять базовый код в фреймворке и почему при изменениях есть риск, что автотесты сломаются?
И еще было бы круто, если бы был инструмент, который анализирует какие регрессионные тесты нужно запустить исходя из изменений в коде продукта!
что вокруг автотестов (которые должны помогать) у вас слишком много проблемА они нам и помогают :) Просто у нас просто очень большой и сложный продукт, на который написано 30000+ автотестов. В итоге сам проект автотестов тоже большой и сложный. Отсюда и столько проблем с его обслуживанием.
зачем вам часто менять базовый код в фреймворке и почему при изменениях есть риск, что автотесты сломаются?Кажется, что я не совсем понятно в статье выразился. На самом деле, совсем базовый код фреймворка мы меняем редко. Тут скорее проблема в том, что часто меняется наш продукт, и из-за него меняются отдельные куски проекта автотестов, которые могут затрагивать очень много тестов. Например, поменялось описание какого-то базового хэндлера, а он используется в 1000 тестов на разные части продуктов (где-то просто на этапе подготовки данных для теста). Вот для таких ситуаций плагин и используется в большинстве случаев.
И еще было бы круто, если бы был инструмент, который анализирует какие регрессионные тесты нужно запустить исходя из изменений в коде продукта!Согласен, что это крутая идея. Она у нас обсуждалась в свое время. К сожалению, пока что, цель не оправдывает средства. У нас моно-репозиторий бэкенд проекта, а вот фронтенд распилен на 400+ репозиториев разного размера. Поэтому создать подобный инструмент для анализа не выглядит простой задачей.
1) Время деплоя не тривиально, но можно посчитать. Во многих статьях по метрикам даются примеры. Это может быть как время между 2мя соседними релизами, там и время между началом работы над релизом и его деплоем.
2) А не получился ли этот плагин «выстрелом себе в ногу».
У вас 2 основных цели: сократить время деплоя и сократить затраты аппаратных ресурсов на прогон автотество
— по первому пункту без замера времени на деплой невозможно ответить, но можно представить себе ситуацию, когда время затраченное на «промежуточные прогоны» превышает время, которое тратиться на приведение тестов к зеленому состоянию во время ревью
— по второму пункту — по вашим графикам видно что кол-во запусков тестов выросло в 3-4 раза, соответственно и траты на аппаратные ресурсы выросли
2) А не получился ли этот плагин «выстрелом себе в ногу».
У вас 2 основных цели: сократить время деплоя и сократить затраты аппаратных ресурсов на прогон автотество
— по первому пункту без замера времени на деплой невозможно ответить, но можно представить себе ситуацию, когда время затраченное на «промежуточные прогоны» превышает время, которое тратиться на приведение тестов к зеленому состоянию во время ревью
— по второму пункту — по вашим графикам видно что кол-во запусков тестов выросло в 3-4 раза, соответственно и траты на аппаратные ресурсы выросли
На самом деле, у нас есть метрики времени деплоя и сложность заключается в другом. Существует много других задач для ускорения процесса деплоя, по которым непрерывно ведётся работа. Сложно понять, что реально повлияло на время в данный момент: плагин или другие активности.
Теперь по поводу графиков. У нас не было цели уменьшить количество прогонов (оно и не уменьшилось, просто раньше прогоны были в других билдах Teamcity, а теперь какая-то их часть перетекла в эту сборку). Цель была в том, чтобы в конкретном прогоне были только нужные тесты. Плагин обеспечивает это, а второй график показывает, что таких прогонов стало относительно много. Первый график лишь демонстрирует, что плагин увеличил популярность сборки, в которой используются Maven-модули для оптимального запуска.
Теперь по поводу графиков. У нас не было цели уменьшить количество прогонов (оно и не уменьшилось, просто раньше прогоны были в других билдах Teamcity, а теперь какая-то их часть перетекла в эту сборку). Цель была в том, чтобы в конкретном прогоне были только нужные тесты. Плагин обеспечивает это, а второй график показывает, что таких прогонов стало относительно много. Первый график лишь демонстрирует, что плагин увеличил популярность сборки, в которой используются Maven-модули для оптимального запуска.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вжух, и прогоны автотестов оптимизированы. Intellij IDEA плагины на службе QA Automation