testomat.io управление авто тестамиЕсли я не ошибаюсь, то тестовый класс должен наследоваться от AbstractTestNGSpringContextTests (в случае с TestNG), как-то можно избежать этого наследования?
В Spring 4.x помоему можно просто обойтись аннотацией? А чем вам наследование мешает?
Мне просто нужно наследоваться от другого класса в тестовом классе.
наследуйте тот класс от AbstractTestNGSpringContextTests. Конечно было бы приятнее, если бы был интерфейс, но увы
Действительно, можно и так, спасибо.
Потому что в силу разных причин мы его точно использовать не будем. А посмотреть и знать, как можно, для себя, хотелось
По старинке, инициализацией объекта
Удобно. Возьму на заметку.
Спринг в автотестах… Не надо так…)
Вместе с спрингом придет очень много того, что вам не нужно.
4 лайка
Например?
У нас из шаблонов в основном Builder и фабрика. Используются для создания объектов близких по смыслу, но немного по разному обрабатывающихся приложением.
Для автоматизации UI использую паттерн Page Object или Screen Object в мобильной автоматизации
Ну во первых не очень понятно, зачем усложнять и нагружать проект всеми зависимостями, который тащит за собой спринг, при том, что очень реальная помощь от него сомнительна - все, что он может с легкостью делается без него.
Во вторых - код автотестов должен быть понятным, все должно быть на виду, в спринге же все скрывается “за xml файлами настроек”.
В третьих - при падении тестов например из за отсутствия коннекшна к базе - мы получаем адовый стектреейс из кучи фабрик и тому подобной фигни, хотя причина то вот она, лежит на поверхности.
Понятно, что многое из вышеперечисленного можно считать не сильными проблемами, но для меня лично не понятно, что вы выигрываете со спрингом? если просто хорошенько взглянуть, то он делает ооочень простые вещи, но приэтом их усложняет.
5 лайков
Ну скажем писать в каждом проекте пейдж фектори, драйвер фэктори тоже сомнительное удовольсвие. Тем более вы последний раз в спринг смотрели какой версии, все что нужно реально это три депенденси, которые тянут не так уж и много. Насчет xml - там он всего один, и к тому же есть аннотешин дривен или groovy конфигурация. Использовать xml в 2015 - пережиток прошлого. И напоследок, тот же сусидидис (серена) он написан на спринге, потому вы невольно им пользуетесь, если используете Thucydides
Что касается вопроса топика, то если честно, всегда хотелось использовать какой-нибудь паттерн 
В сложных ситуациях, когда приходится придумывать решение для серьезной проблемы, перечитываю паттерны, пытаясь подобрать готовое решение на их основе, но пока ни разу не пригождалась ни Фабрика, ни Строитель, ни Visitor. Может быть потому, что я не понял как они мне смогут помочь.
Из тех паттернов, которые приходилось использовать: Singleton, Decorator, Wrapper, Page Object
2 лайка
Мне как-то приходилось делать автоматизацию на уровне сервисных классов продукта. То есть не через UI или внешнее API, а через обращение непосредственно к коду продукта. Продукт использовал Spring, соответственно мне тоже пришлось с ним столкнуться.
Впечатления двойственные. Некоторые вещи со Spring решать было очень просто. Например, DB rollback после выполнения теста, как это принято в Spring, решается добавлением нужной аннотации. Autowiring используемых зависимостей тоже удобен. И т.д. Это что касается плюсов.
Из минусов очевидно, чтобы его грамотно использовать необходимо потратить значительные усилия на преодоление “порога вхождения” в эту технологию. При этом плюсы для тестов, как уже выше @sidelnikovmike сказал, довольно мизерные.
В общем, я этот фреймворк на практике не применяю. По причине, на мой взгляд, неоправданной (для автоматизации тестирования) сложности
2 лайка
Spring, Spring. В python нет никакого спринга и все хорошо и без него 
. Да и многих design patterns в python нету в силу динамичности и специфики самого языка. Но при этом в реализации автотестов использую decorator, proxy, bridge, builder, composite, facade, factory, singleton.
Кстати есть хорошая ссылочка на примеры реализаций различных дизайн паттернов в python GitHub - faif/python-patterns: A collection of design patterns/idioms in Python
2 лайка
Я и thucydides не советую использовать 
Никто не мешает вам сделать один раз все эти фектори, и потом подключать их в каждом проекте зависимостью.
Из плюсов - вот писали про Autowired. Вот потом когда у вас не иницаилизируется что-то - вам приходится кучу мест просмотреть, а указано ли тут или тут в нужном спрингу формате то или иное свойство?
В другом случае - вы просто смотрите на создание объекта прямо у себя в коде. На мой взгляд - это намного удобнее.
Вообщем это оффтоп явный. Это можно спорить до посинения, хорош он или нет.
Вот вы шутите, а мне реально пришлось его использовать, потому что база обновлялась раз в секунду 
А что значит использование одного паттерна? Для чего нужны паттерны проектирования - решения конректных задач.
Спросите у любого девелопера какой паттерн он использует?
Я думаю он на вас посмотрит в недоумении и назовет целую скоуп паттернов, который он использует для решения задач