testomat.io управление авто тестамиНу скажем писать в каждом проекте пейдж фектори, драйвер фэктори тоже сомнительное удовольсвие. Тем более вы последний раз в спринг смотрели какой версии, все что нужно реально это три депенденси, которые тянут не так уж и много. Насчет 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. Вот потом когда у вас не иницаилизируется что-то - вам приходится кучу мест просмотреть, а указано ли тут или тут в нужном спрингу формате то или иное свойство?
В другом случае - вы просто смотрите на создание объекта прямо у себя в коде. На мой взгляд - это намного удобнее.
Вообщем это оффтоп явный. Это можно спорить до посинения, хорош он или нет.
Вот вы шутите, а мне реально пришлось его использовать, потому что база обновлялась раз в секунду 
А что значит использование одного паттерна? Для чего нужны паттерны проектирования - решения конректных задач.
Спросите у любого девелопера какой паттерн он использует?
Я думаю он на вас посмотрит в недоумении и назовет целую скоуп паттернов, который он использует для решения задач