Комментарии 3
По мотивам:
насколько я смог охватить JDI — тесты «развиваются» вместе с «предметом тестирования» и «насыщают» существующий продукт «тестовой составляющей». Нечто похожее уже было почти во всех тестфрэймворках. Каким образом вы решаете проблему изменения тестов вследствии:
— изменения требований к программе,
— новому функционалу,
— удаленным возможностям
?
На написание тестов порой уходит времени и сил не меньше чем на саму разработку. Что происходит с тестами ( по вашему опыту ) при малых средних и больших изменениях в тестируемом продукте?
...
Разобраться во «внутренностях» фреймворка смогут разработчики уровня Senior.
...
насколько я смог охватить JDI — тесты «развиваются» вместе с «предметом тестирования» и «насыщают» существующий продукт «тестовой составляющей». Нечто похожее уже было почти во всех тестфрэймворках. Каким образом вы решаете проблему изменения тестов вследствии:
— изменения требований к программе,
— новому функционалу,
— удаленным возможностям
?
На написание тестов порой уходит времени и сил не меньше чем на саму разработку. Что происходит с тестами ( по вашему опыту ) при малых средних и больших изменениях в тестируемом продукте?
Добрый день,
Так как JDI использует UI Objects, модифицированную версию всем известного шаблона PageObjects, то подобные проблемы решаются очень легко.
* При изменении верстки проприложения (допустим вы выпускаете новую версию вашей программы — редизайн прошлой, где значительно меняется внешний вид, а бизнес логика почти полностью сохраняется), то изменения затронут только UI Objects.
* Если же напротив добавляется новый функционал, а элементы из которых он сделан уже давно описан, то вы просто пишите новые сценарии из уже имеющихся хорошо отлаженных элементов UI Obkects.
* При удалении функционала нужно лишь удалить тестовые сценарии. UI Objects можно не трогать. Во-первых, это сэкономит вам время, а, во-вторых, вдруг пригодятся?
Подобный подход позволяет значительно сэкономить время инженера на поддержку тестов.
Так как JDI использует UI Objects, модифицированную версию всем известного шаблона PageObjects, то подобные проблемы решаются очень легко.
* При изменении верстки проприложения (допустим вы выпускаете новую версию вашей программы — редизайн прошлой, где значительно меняется внешний вид, а бизнес логика почти полностью сохраняется), то изменения затронут только UI Objects.
* Если же напротив добавляется новый функционал, а элементы из которых он сделан уже давно описан, то вы просто пишите новые сценарии из уже имеющихся хорошо отлаженных элементов UI Obkects.
* При удалении функционала нужно лишь удалить тестовые сценарии. UI Objects можно не трогать. Во-первых, это сэкономит вам время, а, во-вторых, вдруг пригодятся?
Подобный подход позволяет значительно сэкономить время инженера на поддержку тестов.
Не смотрели на gebish.org?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фреймворк для UI-тестирования JDI: как и зачем использовать