Comments 6
Статья несколько банальная, но высказанные мысли весьма здравые, потому пусть будет, как и тривиальные статьи о пользе резервных копий.
Не думаю, что это особо поможет, вот к примеру я хочу обновить пакет, у него в зависимостях еще 3 пакета, а у тех еще по 5, должен ли я прочитать release notes всех пакетов? Будет ли в обновляемом пакете информация достаточная для того что произойдет? Мы например пришли к тому, что автотесты нужно писать по тем же принципам, что и приложение. Написали интеграционные тесты, что кнопочки ищутся и тыкаются, формы вводятся и так далее, прогоняем эти тесты на каждый коммит, а при слиянии из dev в master прогоняем регресс, тогда сразу видно упадет ли этот регресс после вливания в мастер. Ну и еще важное правило, что обновления пакетов делаем отдельным коммитом, чтобы в случае чего можно было быстро его откатить. Собственно это касается не только обновления пакетов, но и любых изменений в инфраструктурных классах например если вы обновляете метод инициализации и очистки в базовом классе теста.
вот к примеру я хочу обновить пакет, у него в зависимостях еще 3 пакета, а у тех еще по 5, должен ли я прочитать release notes всех пакетов?
Смотреть и подробно изучать зависимости зависимостей может и не стоит. Но по какой-то причине Вы же хотите обновить этот пакет. Значит знаете зачем.
Ну и странно не почитать, что нового принесла очередная версия. Вдруг теперь можно ускорить тесты в три раза добавив какой-нибудь НЕ дефолтный флаг… откуда Вы об этом узнаете, если не прочитаете change list? :)
Моя мысль была в том, что обновлять пакеты или софт надо не потому что «надо», а с какой-то целью. Четко осознавая плюсы и минусы этого действа.
Написали интеграционные тесты, что кнопочки ищутся и тыкаются, формы вводятся и так далее, прогоняем эти тесты на каждый коммит, а при слиянии из dev в master прогоняем регресс, тогда сразу видно упадет ли этот регресс после вливания в мастер.
Это очень крутое и правильно решение. И оно всем правильное. Только стоит упомянуть, что оно довольно дорогое. Для подобные тестов на тесты надо А — выделить время в человекочасах, Б — поднять где-то аналог приложения с простыми формами, Ц — продумать сценарии, которые будут ловить не только поломанный примитивный click(), но и какой-нибудь драг-н-дроп какого-нибудь хитро сверстанного модуля. Иначе ценность этих тестов будет не очень высокой.
В целом, было бы интересно узнать про Ваш подход больше. Будет время, обязательно напишите как подобные интеграционные тесты работают у Вас.
Автоматизация: как работать с обновлениями