#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 применительно к данному случаю.
