Какие паттерны програмирования вы используете в автоматизации?

design-patterns
framework
Теги: #<Tag:0x00007fedb8ad8100> #<Tag:0x00007fedb8f1bf00>

(Vadim Chehovich) #9

Если я не ошибаюсь, то тестовый класс должен наследоваться от AbstractTestNGSpringContextTests (в случае с TestNG), как-то можно избежать этого наследования?


(Sergey Pirogov) #10

В Spring 4.x помоему можно просто обойтись аннотацией? А чем вам наследование мешает?


(Vadim Chehovich) #11

Мне просто нужно наследоваться от другого класса в тестовом классе.


(Sergey Pirogov) #12

наследуйте тот класс от AbstractTestNGSpringContextTests. Конечно было бы приятнее, если бы был интерфейс, но увы


(Vadim Chehovich) #13

Действительно, можно и так, спасибо.


(James May) #14

Потому что в силу разных причин мы его точно использовать не будем. А посмотреть и знать, как можно, для себя, хотелось

По старинке, инициализацией объекта

Удобно. Возьму на заметку.


(sidelnikovmike) #15

Спринг в автотестах… Не надо так…)
Вместе с спрингом придет очень много того, что вам не нужно.


(Sergey Korol) #16

Думаю, многие оценят, если вы зальете пример работы со спрингом в нашу БЗ. :wink:


(Sergey Pirogov) #17

Например?


(Максим Таран) #18

У нас из шаблонов в основном Builder и фабрика. Используются для создания объектов близких по смыслу, но немного по разному обрабатывающихся приложением.


(Mikulasi) #19

Для автоматизации UI использую паттерн Page Object или Screen Object в мобильной автоматизации


(sidelnikovmike) #20

Ну во первых не очень понятно, зачем усложнять и нагружать проект всеми зависимостями, который тащит за собой спринг, при том, что очень реальная помощь от него сомнительна - все, что он может с легкостью делается без него.
Во вторых - код автотестов должен быть понятным, все должно быть на виду, в спринге же все скрывается “за xml файлами настроек”.
В третьих - при падении тестов например из за отсутствия коннекшна к базе - мы получаем адовый стектреейс из кучи фабрик и тому подобной фигни, хотя причина то вот она, лежит на поверхности.

Понятно, что многое из вышеперечисленного можно считать не сильными проблемами, но для меня лично не понятно, что вы выигрываете со спрингом? если просто хорошенько взглянуть, то он делает ооочень простые вещи, но приэтом их усложняет.


(Sergey Pirogov) #21

Ну скажем писать в каждом проекте пейдж фектори, драйвер фэктори тоже сомнительное удовольсвие. Тем более вы последний раз в спринг смотрели какой версии, все что нужно реально это три депенденси, которые тянут не так уж и много. Насчет xml - там он всего один, и к тому же есть аннотешин дривен или groovy конфигурация. Использовать xml в 2015 - пережиток прошлого. И напоследок, тот же сусидидис (серена) он написан на спринге, потому вы невольно им пользуетесь, если используете Thucydides


(Александр Таранков) #22

Что касается вопроса топика, то если честно, всегда хотелось использовать какой-нибудь паттерн :slight_smile: В сложных ситуациях, когда приходится придумывать решение для серьезной проблемы, перечитываю паттерны, пытаясь подобрать готовое решение на их основе, но пока ни разу не пригождалась ни Фабрика, ни Строитель, ни Visitor. Может быть потому, что я не понял как они мне смогут помочь.

Из тех паттернов, которые приходилось использовать: Singleton, Decorator, Wrapper, Page Object


(Александр Таранков) #23

Мне как-то приходилось делать автоматизацию на уровне сервисных классов продукта. То есть не через UI или внешнее API, а через обращение непосредственно к коду продукта. Продукт использовал Spring, соответственно мне тоже пришлось с ним столкнуться.

Впечатления двойственные. Некоторые вещи со Spring решать было очень просто. Например, DB rollback после выполнения теста, как это принято в Spring, решается добавлением нужной аннотации. Autowiring используемых зависимостей тоже удобен. И т.д. Это что касается плюсов.

Из минусов очевидно, чтобы его грамотно использовать необходимо потратить значительные усилия на преодоление “порога вхождения” в эту технологию. При этом плюсы для тестов, как уже выше @sidelnikovmike сказал, довольно мизерные.

В общем, я этот фреймворк на практике не применяю. По причине, на мой взгляд, неоправданной (для автоматизации тестирования) сложности


(Mykhailo Poliarush) #24

Spring, Spring. В python нет никакого спринга и все хорошо и без него :smile: . Да и многих design patterns в python нету в силу динамичности и специфики самого языка. Но при этом в реализации автотестов использую decorator, proxy, bridge, builder, composite, facade, factory, singleton.

Кстати есть хорошая ссылочка на примеры реализаций различных дизайн паттернов в python https://github.com/faif/python-patterns


(sidelnikovmike) #25

Я и thucydides не советую использовать :smile:
Никто не мешает вам сделать один раз все эти фектори, и потом подключать их в каждом проекте зависимостью.
Из плюсов - вот писали про Autowired. Вот потом когда у вас не иницаилизируется что-то - вам приходится кучу мест просмотреть, а указано ли тут или тут в нужном спрингу формате то или иное свойство?
В другом случае - вы просто смотрите на создание объекта прямо у себя в коде. На мой взгляд - это намного удобнее.

Вообщем это оффтоп явный. Это можно спорить до посинения, хорош он или нет.


(Михайло Єдемський) #26

ну конечно же sleep паттерн!!! http://www.slideshare.net/orgeirIngvarsson/ui-automation-patterns-sleep


(Urtow) #27

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


(Прокопук Дмитрий) #28

А что значит использование одного паттерна? Для чего нужны паттерны проектирования - решения конректных задач.
Спросите у любого девелопера какой паттерн он использует?
Я думаю он на вас посмотрит в недоумении и назовет целую скоуп паттернов, который он использует для решения задач