Давно хотел написать о проблеме, которой, на мой взгляд, не уделяется достаточно
внимания в проектах. По крайней мере я не видел на эту тему ни одной публикации
или доклада на конференциях. Летом 2020 года я спросил у своих подписчиков
интересна ли им будет статья на тему быстрого регресионного тестирования.
Большинство проголосовало положительно и я написал черновик статьи, основанной
на материале из своего собственного опыта. Довести черновик до полноценной
статьи тогда я времени не нашёл, зато собрал больше материала по этой теме.
Как устроен процесс работы разработчика? Обычно это замкнутый цикл из
нескольких этапов: "создание изменения в кодовой базе проекта" -> "создание
тестовой сборки" -> "выполнение регресионных тестов".
Разработчик делает изменение и с помощью системы непрерывной интеграции
получает *обратную связь* о качестве своих изменений в кодовой базе. Результат
сборки и тестирования новых изменений может быть положительным и отрицательным.
В первом случае от разработчика ничего не требуется и изменения готовы для
мёржа. Во втором случае нужно прекратить выполнение текущей задачи,
восстановить контекст предыдущей задачи, разобраться почему тесты или сборка не
прошла, починить и отправить изменения опять в тестирование. А пока выполняются
сборка и тестирование разработчик переключается на другие задачи и *переключает
контекст между предыдущей и новой задачей*.
Не знаю насколько актуальна эта проблема в ваших проектах, но меня она
преследует из одного проекта в другой. Во многих продуктовых проектах, с
которыми я сталкивался, ожидание обратной связи может занимать значительное
время. О цикле обратной связи, о переключении контекста в разработке и
возможных способах сокращения времени обратной связи я и хотел поговорить в
этой статье.
Читать →