Обновить

Красное не мёржим: как мы внедрили e2e тесты в разработку

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели7K
Всего голосов 3: ↑3 и ↓0+6
Комментарии7

Комментарии 7

сквозное тестирование в стартапе это боль. а как убедили разработчиков что это надо? какой порог входа был?

Буквально по одному убеждал. Сначала находил ломающие коммиты и приходил с ними к виновнику. Он, как починил, прогнал все локально. Увидел, что в другом месте сломалось, и там тоже починил) Потом просто сарафанное радио и в какой то момент блок мержа)
Еще тесты супер полезны, когда идет большое обновление библиотек. Обычно много проблем вылезает.

Порог входа, в целом, был невысоким. Думаю, что больше всего мешало нежелание. Но, все позади)

Я правильно понимаю, что автор предложил внутри компании решение и он же его поддерживает в рабочем состоянии или для этого у вас есть специальные роли? И кто у вас решает условно, что именно покрывать тестами, а что нет?

Да, все верно. один AQA на проекте отвечает за инфру, тестовое покрытие и стабильность инфры. Решения по покрытию принимает тоже он. Цель - максимально снизить время на регресс и покрыть критичные сценарии.

И у меня возник еще вопрос относительно выбора detox. Вероятно вы проводил сравнение и можете назвать причины почему не appium?

Детокс и быстрее, и умнее в плане ожиданий (читает состояние приложения в рантайме)
Ну и общий стек с проектом
И еще платные девайс фермы нам не подходили, поэтому appium отпал)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации