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