#patterns #automation

О неправильном понимании Принципа единственной ответственности (Single-responsibility principle) применительно к PageObject.

На днях один из моих студентов задал вопрос:

Добавили в РО вместе с остальными шагами. Насколько правильно шаги с ассертом объединять в одном РО?
Вот в РО на авторизацию. У меня есть и шаг заполнения полей с кликом и проверка результата. На работе настучали по рукам, чтобы проверка была не в РО, а именно в тесте

Казалось бы, простой вопрос с простым ответом🙂
И далее:

Я после своего вопроса решил сам исследовать проблему. В некоторых "умных книжках", сказали, что нельзя использовать ассерты. Так как разделяют на: "методы для взаимодействия с элементами страницы" и "методы для проверки состояния элементов страницы". Это, как я понимаю, ведет к нарушению принципа SOLID по единой ответственности и поэтому нельзя.

И вот тут я понял, что надо писать пост.

Всем мы на подсознательном или осознанном уровне понимаем, что такое Single responsibility. Это - максимально упрощая - когда класс UserController отвечает за создание и редактирование юзеров, и не отвечает за отправку e-mail-ов с прогнозом погоды.

На чем базируется это с технической точки зрения в ООП?

На инкапсулированных зависимостях UserController-а. Нет, я понимаю что все можно написать на static методах, но все-таки, UserController должен выглядеть примерно так:

class UserController {
   private final UserRepository userRepository;

и вот этот userRepository - он работает с юзерами в БД (я в курсе, что инжектить репозитории в контроллеры не надо, это просто пример).

Важно тут то, что наш UserController не должен инкапсулировать EmailWeatherNotifier, и чисто технически не должен получить возможность отвечать за что-то не то (нарушать S в слове SOLID).

А теперь к PageObject🙂:

class LoginPage {
   private final SelenideElement usernameInput = $("#username");
   private final SelenideElement passwordInput = $("#password");

Что он инкапсулирует? Элементы на странице. У этих элементов есть метод click(), setValue(...) и, внезапно, shouldBe(...).
Я не понимаю, как использование shouldBe(...) (ассерта) может являться здесь нарушением Single responsibility, а setValue(...) - нет.

И то, и другое - это работа со страницей авторизации. И это и есть одна ответственность класса LoginPage.

Пока в ваших PageObjecta-х инкапсулированы только элементы страницы, вы не нарушите никаких Solid-ов.

Добавляйте методы с ассертами и проверками в свои PageObject-ы на здоровье, если хотите - не добавляйте, создавайте AssertObject-ы, но во всех этих случаях - не слушайте псевдоумные рассуждения про SOLID применительно к данному случаю.