Page Object Model + Webdriver. Пример реализации на одном тесте

[akzhan]

Недавно как раз начали использовать. В Ruby это обеспечивает гем page-object.

[darthkwisatzhaderach]

Посмотрел ваш пример на github и пришел к выводу, что в описанном решении есть несколько архитектурных ошибок.

1. Driver статичен и хранится в BaseObject, от которого наследуются страницы. Когда кол-во ваших тестов перевалит за сотню / тысячу вам захочется запускать их параллельно. И вот тут статичный драйвер даст о себе знать.

2. Хэлперы в вашем описании либо дублируют функциональность страниц, либо отделяют функциональность страницы в отдельный класс. Опять же, при большом кол-ве страниц и тестов, получите много дублирующего кода. Лучше пользоваться прямо классами страниц в тестах. Так тест можно будет читать, т.е. понимать, куда он пошел, что нажал, что получил. Да, возможно иногда нужны вспомогательные классы, для случаев, когда тесты много раз используют метод, который задействует несколько страниц. Но, вероятнее всего, таких методов будет немного.

3. Когда речь идет о паттерне Page Object я отталкиваюсь от статьи code.google.com/p/selenium/wiki/PageObjects

Если кратко, то:

• The public methods represent the services that the page offers
• Try not to expose the internals of the page
• Generally don't make assertions
• Methods return other PageObjects
• Need not represent an entire page
• Different results for the same action are modelled as different methods

Assert'ы должны быть только в тесте (не в страницах). Хэлперы, в вашем случае, это функциональность страницы. Т.е. метод AssertUserName нужно переделать (и переименовать), чтобы он принимал имя и возвращал true / false. А уже в тесте вызывать например

Assert.IsTrue

У вас есть описание конкретного элемента:

[FindsBy(How = How.XPath, Using = USER_NAME_TEXT_FIELD)]
public IWebElement userNameTextField;

Для чего тогда эта константа? На мой взгляд присвоение лишнее.

public const string USER_NAME_TEXT_FIELD = "//input[@id='email']";

4. Вы создаете драйвер на фичу. В целом это правильно, т.к. позволяет сэкономить время выполнения. Но если у вас появится Alert или в тесте вводятся аутентификационные данные, то все следующие тесты провалятся. Нужно либо создавать драйвер на тест, либо заботиться о непредвиденных сценариях и чистить куки.

В целом, статья интересна. Неплохое исследование и заготовка. Однако чувствуется, что это решение не обкатывалось на большом количестве тестов в реальных проектах.