Появилася идея хранить все локаторы страниц в XML файлах, своего рода map of the page, для того что бы вносить изменения не лазя в код. Но тогда возникает вопрос, как при этом можно воспользоваться PageFactory.
На сколько я понимаю PageFactory инициализирует все элементы которые обьявлены на странице, для этого я использовал аннотации @FindBy
getXML() реализрвать : будет брать имя класса (название страницы), искать соответствующий xml file. Там в зависимости от атрибутов будет искать необходиые данные и возвращать элемент.
Но возникает вопрос, проинициализирует ли PageFactory webElement реализрванный таким образом?
Мы когда-то тоже так хотели - все локаторы выпихнули в отдельный xml-файл, правда не использовали PageFactory.
В итоге - вернулись к логике без xml.
"для того чтобы вносить изменения не лазя в код" - а так вы будете лезть в xml-файл вместо кода :) Причем в коде есть плюшки а-ля go to definition, а в xml-файле у вас будет максимум подсветка xml синтаксиса.
Мы решили, что если у нас локаторы и так находятся в проекте (package) UI и это отделено от логики самого теста - этого достаточно.
Возможно с Selenium и PageFactory это получится вкусно - не знаю, не готовил :)
Проблема в том, что скажем так коллеги когда видят любой код сразу входят в ступор и говорят, мол это програмирование, мы этого не знаем, мы не программисты. С XML попроще, хоть какую-то работу можно им отдать :) Да и косметическое редактирование тестов для непрограммиста упростится, как мне кажется.
имхо xml'ку с локаторами надо генерить автоматически (или полуавтоматически, если проблемно) - т.е. при серьёзных изменениях страницы или сайта, перегенерил страницу/ы или весь сайт (это кошмар - руками править множество не связанных между собой файлов. Вы им за что-то мстите? :))
А вот специфически-квалифицированную ("только xml") рабочую силу я бы занял на data-driven testing и подготовкой результатов.
Примерно так: генерится xml, для рукописцев делается запускалка по'xml'но - запустил файл xml контролов и файл, в котором подготовлены входные данные (данные в поля, клики и т.д.).
запустили, проверили, посмотрели результат, внесли результат в файл - прогон по страничке готов. и так для каждой странички или каждого типа страниц.
Я в своё время делал фреймворки типа NUnit/JUnit - они читали tab-separated файлы (название - значение), каждый файл имел номер тест-кейса типа 1.2.3.4.txt. Автотестовый движок запускался, читал файл за файлом и подставлял значения (это было тестирование API, которое поднимало несколько видов форм или эксепшн), а потом через MS UI Automation считывал поля форм и анализировал. Каждый тест работал независимо, отчего я и осмелился на сравнение.
Вот как раз для создания таких текстовых файлов и получения результатов для автотеста и следовало бы использовать coding-disabled товарищей.