Год назад я рассказывала о том, как рассчитать риски и перейти на новый инструмент автоматизации тестирования. В этот раз я бы хотела немного углубиться в технические детали реализации инструмента, позволяющего гибко производить командное тестирование на компонентном и интеграционном уровне.

Я расскажу про динамические конфигурации, позволяющие писать универсальные тесты для всех ваших сред, и покажу пример реализации Spring-подобного синтаксиса, который позволил нам значительно упростить технику написания тестов, используя связку Java + Selenide, а так же сделать этот процесс понятным и привычным для разработчиков.

Проработав в трех компаниях на роли автоматизатора, общаясь с коллегами из других команд и компаний, приезжая на конференции я встречаю людей, стоящих перед дилеммой - стоит ли переходить на новый фремворк для автоматизации, если изначально выбранный по каким-то причинам сложно использовать, расширять или поддерживать? Что дороже - тратить ресурсы на рефакторинг и обучение сотрудников старому фреймворку или использовать новый? Через какое время новый фреймворк принесет первые результаты?

В данном докладе мы попробуем рассмотреть основные моменты, на которые стоит обратить внимание в процессе принятия решения, посчитать риски и возможные варианты решения проблемы.