Перейти на PRO

Что такое ООП и как оно применяется в тестировании?

Тип вопроса: ООП Вероятность: 42% Категория: AQA / Automation

Ответ

ООП (Объектно-Ориентированное Программирование) — это парадигма, основанная на объектах, содержащих данные и методы. В автоматизации тестирования ООП используется для создания гибкого, поддерживаемого и переиспользуемого кода автотестов.

Как принципы ООП применяются в тестовых фреймворках:

  1. Инкапсуляция: Сокрытие внутренней логики страниц или компонентов. Например, в Page Object Model (POM) все локаторы и методы работы с веб-элементом инкапсулированы в классе страницы.

    public class LoginPage {
    private By usernameField = By.id("username"); // Локатор скрыт

    public void enterUsername(String user) { // Публичный интерфейс
        driver.findElement(usernameField).sendKeys(user);
    }
}

  2. Наследование: Создание базовых классов для общих функций. Все классы страниц могут наследоваться от BasePage, где реализованы общие методы (ожидание элемента, логирование).

    public class BasePage {
    protected WebDriver driver;
    public void waitForElement(By locator) { ... }
}
public class HomePage extends BasePage { ... }

  3. Полиморфизм: Возможность использовать один интерфейс для разных типов. Например, универсальный метод click() может работать с разными типами элементов (кнопка, ссылка).

  4. Абстракция: Определение контрактов через абстрактные классы или интерфейсы. Это позволяет создавать разные реализации для, например, работы с разными базами данных в тестах.

Использование ООП в тестировании позволяет эффективно структурировать код, уменьшать дублирование и упрощать поддержку больших наборов автотестов.

Ответ 18+ 🔞

Ну слушай, история про ООП в тестировании — это как раз тот случай, когда теория не просто для умников, а реально помогает не сойти с ума. Представь, ты пишешь автотесты без всякой структуры, как мартышлюшка с гранатой: всё в одну кучу, локаторы раскиданы, логика перемешана. Потом бац — и проект накрылся медным тазом, потому что изменить что-то — это пиздопроебибна задача. Вот тут ООП и выручает, ёпта.

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

Как эти ваши принципы в тестах притворяются в жизнь:

  1. Инкапсуляция. Суть в том, чтобы спрятать всю свою грязь внутрь. В Page Object Model (POM) ты создаёшь класс для страницы и засовываешь туда все эти свои By.id("username"), чтобы они нигде больше не торчали. Снаружи виден только красивый метод enterUsername(). Меняется локатор? Иди в один класс и поменяй его там, а не бегай по всему коду, как угорелый.

    public class LoginPage {
    private By usernameField = By.id("username"); // Спрятали, как золото. Снаружи не видно.

    public void enterUsername(String user) { // А это — парадная дверь. Пользуйтесь.
        driver.findElement(usernameField).sendKeys(user);
    }
}

    Идея в том, что тест-скрипт вообще не должен знать, как там кнопка ищется. Его дело — сказать: «эй, страница логина, введи-ка юзера». Доверия ебать ноль к тому, что кто-то в тесте не накосячит с локатором, если он спрятан.

  2. Наследование. Это когда у тебя есть общие штуки, которые нужны везде. Зачем в каждом классе страницы писать один и тот же метод waitForElement()? Создаёшь класс BasePage, пишешь это всё там один раз, а потом все остальные страницы просто говорят: «я твой сын, папа» (через extends).

    public class BasePage {
    protected WebDriver driver;
    public void waitForElement(By locator) { ... } // Общая магия для всех
}
public class HomePage extends BasePage { ... } // Всё, методы BasePage теперь и мои

    Получается экономия времени и сил — терпения ноль ебать переписывать одно и то же.

  3. Полиморфизм. Звучит сложно, а на деле — просто удобная хитрая жопа. Один интерфейс — много реализаций. У тебя может быть общий метод click(), и ему похуй, что ты кликаешь: на кнопку, на ссылку или на кастомный див. Главное, что у объекта есть нужный метод. В тестах это позволяет писать универсальные хелперы, которые работают с чем угодно.

  4. Абстракция. Это когда ты определяешь правила игры. Допустим, тебе нужно в тестах работать и с PostgreSQL, и с MongoDB. Ты создаёшь интерфейс DatabaseClient с методами connect(), query(). А потом делаешь две реализации: одну для Постгреса, другую для Монго. Твои тесты будут работать с абстракцией DatabaseClient, а подозрение ебать чувствую, какая именно база там под капотом — им уже не важно. Гибко, ёб твою мать.

Короче, если не применять ООП, то с ростом проекта код тестов превращается в такое месиво, что сам от себя охуеешь, когда попробуешь в нём что-то найти. А с этими принципами — есть шанс сохранить и код, и рассудок. Всё структурировано, переиспользуется и не вызывает желания кричать «идите вы все нахуй!» каждый раз при рефакторинге.

Видео-ответы

© ХакСобесов, 2026
support@hacksobesov.com