Год съёмок: 2017 Автор: Кирилл Трифонов
Как известно, чем раньше найден баг, там дешевле его починить. Лучше всего, когда проблема обнаруживается юнит-тестами или статическим анализатором на самой ранней стадии. Иначе обстоят дела с проблемой, проникшей в общую ветку. В этом случае необходимо дождаться прохождения автоматической регрессии, формально описать баг, а после исправления — проверить, что в свежем билде его действительно больше нет. Всего этого мы могли бы избежать, запустив регрессию на dev-бранче перед коммитом в общую ветку. Но это тоже малоэффективно потому, что регрессия выполняется долго и не все тесты в ней имеют отношение к измененному коду
Как с этим бороться? В докладе я расскажу про наш опыт автоматизации поиска тестов, покрывающих изменения в dev-бранче, с помощью информации о покрытии кода.
Нет обсуждений для отображения.

Если у вас есть, что сказать, можете представиться и исправить ситуацию.

Прицельная регрессия, или запускаем только релевантные автотесты

Категории

Язык
Область
Мероприятие

На заметку
В разделе «События» можно узнать о надвигающихся событиях мира Python, а также поделиться своими. Если вы являетесь организатором встречи/конференции/спринта, зарегистрируйте это событие в указанном разделе, чтобы о нём узнали все желающие.