Если функция addNumbers нужна во многих тестах, то я действительно вынес бы этот код в отдельную функцию. Но вовсе не обязательно делать из этого ПэджОбжект. Это нормальная практика переиспользования кода, это не какой-то уникальный только для тестирования паттерн.
Но я очень хочу подчеркнуть, что тестировать множество комбинаций чисел и операций через UI - плохая идея. Комбинации надо покрывать юнит-тестами, а UI-тестов должно быть мало, и они должны покрывать один-два базовых сценария. Тогда вам и не понадобится выстраивать ракеты из пэдж обжектов.
В таких случах, когда человек не имеет большого опыта, лучше учить писать правильно, с пейдж обжектами и всеми делами. Я имею дело со студентами, им если сказать что можно писать без этого и этого, то потом получается адская кухня из спегетти кода
Вот скажем, тестирую я приложение под windows 7. И build validation tests, как и функциональные тесты, включают в себя работу с множеством окон. Окна эти по своему содержимому - не однородны, они содержат разные контролы, они различны также и по объему логики в каждом диалоговом окне. Где-то - это проходное окошко, где нужно ввести чекбокс и указать путь. А где-то: это панель с кучей данных в таблице.
Паттерны тем и хороши, что их можно употреблять, а можно и нет. Например, такая всем известная вещь, как визард виндоус, имеет внутри себя 2-3 кнопки. Для теста важно, что я точно знаю, что оказался в нужном окне на нужном шаге и нажал 1 из 3 кнопок. Пейдж объекты хороши в вебе, где контекст можно легко воссоздавать, например, за счет просто переданного POST запроса с JSON, который должным образом тебя к работе с конкретным PageObject и вернет. Мне кажется, что это - фундаментальная важность ПейджОбъектов - то, а) работа в них заключает большой(или потенциально большой) функционал, наличие контролов, методов и проч. б) при тестировании ПейджОбъекта можно будет на него попасть, принимая преимущества REST протокола и того, что в вебе по сути можно дойти до нужного состояния Сценария не используя автоматизацию.
В ОС контекст приходится либо дольше создавать, либо не бросать его. И во втором случае как по мне PageObjects - лишнее нагромождение, затратное по времени.
А давайте сформулируем более общим образом:
Кто не видит необходимости в декомпозиции тестовой логики и интерфейса взаимодействия с исследуемым объектом?
Представьте, что вы тестируете Single Page App, которое делалось для ентерпрайза. Так вот, роутинг (изменение URL в зависимости от состояния приложения) – это опциональная фича фреймворка на котором оно делалось, следовательно, чтобы добраться до n-й страницы, скрипту и пользователю нужно прокликать с первой.
В BorlandSilktest, с которого начался мой путь автоматизитора, есть понятие декларации окна как объекта в коде. Это аналог PageObject. Мы декларировали и это очень помогало не утонуть в коде. Этот подход можно использовать для всего где есть UI.
Да, фактически декларация PageObject будет отнимать время вначале. Чтобы сократить его я работаю над инструментом SWD Page Recorder. В случае поддержки и поиска ошибки в коде, за счет правильной архитектуры (это не только PageObject), вы можете сэкономить намного больше времени.
Да, но куда вынести эту функцию? Utils.java? В базовый класс?
А что если у нас есть еще логарифмический калькулятор на соседней странице и у него тоже должен быть addNumbers ?
Это (калькулятор) вымышленный пример. Есть разные ситуации, в которых использование юнит тестов или даже интеграционных может быть либо нереальным либо сложным. Я не говорю что это самое правильное решение, но хочу сказать что это в некоторых ситуациях может быть единственным решением.
Некоторые ситуации – это большие Legacy проекты, в которых можно найти код на фортране, который генерирует javascript из xslt; этот сгенерированный javascript вставляет IFRAME с SQL запросом в URL для отображения дополнительной информации. Переписать по человечески – значит потратить 3 года чтобы добится результата который есть сегодня.
Только не надо придраться, XSLT был лучшим шаблонизатором вначале 21-го века.
Из того, что вы говорите, следует, что пэдж обжекты действительно иногда полезны - когда в проекте технологии 90х, когда локаторы громоздкие, когда нет юнит-тестов, когда до разработчиков не достучаться. Вот поэтому не надо учить этому молодых, называя “хорошей практикой”.
Изначальный вопрос был - можно ли обойтись без пэдж обжектов. И мой ответ - прекрасно можно, там, где процесс разработки налажен грамотно.
[quote=“asolntsev, post:18, topic:7601”]
И мой ответ - прекрасно можно, там, где процесс разработки налажен грамотно.
[/quote]А вы писали когда-нибудь UI тесты в black_box_mode на проекте, где “процесс разработки налажен не очень грамотно”?
А видели тесты “молодых” на подобных проектах? Саппортили их?
Так может стоит перестраховаться и таки называть это “хорошей практикой”?
И расшифруйте понятие “грамотно” - это когда ты “сам на кодил сам натестил”? Топикстартер явно не из этой категории.
[quote=“asolntsev, post:18, topic:7601, full:true”]
Из того, что вы говорите, следует, что пэдж обжекты действительно иногда полезны - когда в проекте технологии 90х
[/quote]Может тогда ответите на
В данном контексте грамотно - это когда разработчики пишут юнит-тесты и сотрудничают с тестировщиками, совместными усилиями делая приложение легко тестируемым. Среди прочего это означает читаемые локаторы и эмуляторы внешних сервисов. Тогда в тесте проще использовать локатор, чем городить пэдж обжект.
Вредный вопрос. Идея красивая, я согласен. Но полезнее спросить: какую проблему мы решаем? Какую реальную проблему решает эта декомпозиция? Если разобраться, ту самую проблему неэффективного процесса разработки. И не решает, а прячет.
Я понимаю, это нужно. В большинстве компаний процесс именно такой. Локаторы плохие, разработчики в Индии, юнит-тестами и не пахнет. Это данность, ничего не поделаешь. Просто не говорите молодым, что это хорошая практика.
Код покрыт юнит-тестами, с разработачиками сотрудничаю)
Если говорить откровенно то у меня слабые знания в языке программирования, я конечно его активно учу, но не все как говорится сразу.
Выбрал cucumber потому что gherkin позволяет составлять человеческо понятные тесты.
Далее, Capybara добавляет того сахара, который упрощает всё.
Как локаторы использую xpath, некоторые да, повторяются, но я делаю дополнительные проверки.
Я понимаю, что это не совсем верно, не зная толком мат.части браться писать что-то. Но в данных условиях по-другому просто не получается.
Пробовал site-prism, непонравился. посчитал излишним нагромождением, DRY обхожу благодаря более обстоятельному описанию шагов, которое как мне кажется может помочь в будущем сразу понять для чего данный тест предназначен.
Имеет ли шансы мой подход, или же нет?
Только давайте объективно)
Я свой фреймворк переделывал 3 раза, пока не прочитал, что существуют паттерны и в сфере автоматизации используется PageObject. Может стоило в этой теме задаться вопросом, а понимает ли человек что такое PageObject? P.S. я не хочу никого оскорбить, но это действительно так и выглядит, не знание что такое паттерны.
На самом деле хотелось бы увидеть человека, который пользуется такими же инструментами как и я и объяснил почему нет или почему да.
Назначение page object-а видится мне в том, чтобы описывать страницы на которых будут выполняться тесты предварительно тем самым избежать самоповтора в тестах.
А в чём проблема-то? В том-то и дело, что я не вижу никакой проблемы с приведённым примером. Ну, можно вынести эти операции в методы пэдж обжекта, но он не станет более читабельным от этого. А кода будет вдвое больше.
Я писал автотесты на указанном стеке. Встречный вопрос - а почему не использовать? Задача - мы хотим инкапсулировать логику нахождения html элементов на странице. PageObject - не единственный возможный паттерн, но самый очевидный. На ruby есть готовые реализации, так что самому надо будет описывать только локаторы. Итак, в чем причина сомнений?
Но вообще да, встречался с ситуацией, в которой PageObject был бы неудачным решением. Проблема была с переиспользованием html объектов с динамическими локаторами, имеющиеся реализации PageObject на Java этого не позволяли.
Вот, в этом вся проблема!
Все используют пэдж обжекты, чтобы прятать локаторы. А на самом деле задача пэдж обжектов - инкапсулировать не нахождение элементов, а логику работы с этими элементами.
Ну это, мягко говоря, спорное утверждение. Есть ссылка на источник, как должно быть “на самом деле”? Давайте тогда начнем определения, что это вообще такое - “PageObject pattern”
testomat.io управление авто тестами