Какие паттерны проектирования применяются в автоматизации тестирования?

А, паттерны проектирования для автотестов, говоришь? Ну это ж, блядь, как инструкция по сборке мебели из Икеи, только если её не соблюдать — не комод развалится, а вся твоя тестовая архитектура накроется медным тазом, и ты потом неделю будешь ебаться, отлаживая, почему клик не работает. Слушай сюда, разжую.

1. Page Object (PО), он же POM. Ну, ёпта, святое дело. Это когда ты не раскидываешь селекторы по тестам, как говно мамонтовое по тундре, а засовываешь всю работу со страницей в отдельный класс. Представь: дизайнеры взяли и поменяли id у поля логина. Без PO тебе придётся бегать по сотне тестов и везде правки вносить, волнение ебать. А с PO — зашёл в один класс LoginPage, поправил в одном месте селектор, и все тесты, которые используют этот метод login(), автоматически подтянут изменение. Красота, блядь. Чистая инкапсуляция, в рот меня чих-пых.

public class LoginPage {
    private WebDriver driver;
    private By usernameField = By.id("username");
    private By passwordField = By.id("password");
    private By submitButton = By.id("submit");

    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }

    public HomePage login(String username, String password) {
        driver.findElement(usernameField).sendKeys(username);
        driver.findElement(passwordField).sendKeys(password);
        driver.findElement(submitButton).click();
        return new HomePage(driver); // Возвращает следующую страницу
    }
}

Вот видишь? Всё аккуратненько. Тест потом вызывает loginPage.login("вася", "123") и поехал дальше. Никакого говнокода.

2. Factory Method. Это когда тебе надо создавать что-то, но заранее не ясно, что именно. Типа драйвер браузера. Хочешь — хром, хочешь — фаерфокс, а хочешь — какой-нибудь ебучий эдж. Вместо того чтобы в каждом тесте городить if (browser.equals("chrome")), ты пишешь фабрику: WebDriverFactory.getDriver(browserName). Она тебе внутри сама разберётся, какой драйвер создать. Удобно, блядь. Особенно когда в CI/CD прогоняешь тесты на разных окружениях.

3. Singleton. О, этот пидарас шерстяной всех так достал в обычной разработке, но в автотестах он иногда нужен. Особенно для WebDriver. Чтобы не получилось, что в одном тесте у тебя три драйвера открыто и все друг другу ебла мешают. Singleton гарантирует, что драйвер будет один на весь прогон. Но, блядь, осторожно с ним — после тестов надо его убить нахуй, иначе в памяти висеть будет. А то потом удивление пиздец: "почему память кончилась?".

4. Builder. Представь, тебе надо создать тестового пользователя. У него имя, почта, телефон, адрес, статус, дата рождения — овердохуища полей. И в разных тестах нужны разные комбинации: где-то только имя и почта, где-то всё, кроме телефона. Писать кучу конструкторов — терпения ноль ебать. А вот Builder — красота.

User testUser = new UserBuilder()
    .withName("John")
    .withEmail("john@test.com")
    .withActiveStatus(true)
    .build();

Читаемо, как боженька. Хочешь — добавь поле, не хочешь — не добавляй. И не паришься.

5. Decorator. Хитрый паттерн, блядь. Допустим, ты хочешь логировать каждое действие с элементом: "кликнул на кнопку", "ввёл текст". Можно, конечно, в каждый метод PageObject запихнуть System.out.println, но это же пиздец как негибко. А Decorator позволяет обернуть стандартный WebElement в свой класс, который будет делать то же самое, но ещё и логировать. Динамически, сука, добавлять функциональность. Как надеть пиджак на футболку.

6. Strategy. Семейство алгоритмов, ёбта. Например, у тебя есть несколько способов аутентификации: по логину-паролю, по кукам, через OAuth. Вместо гигантского switch в тестах ты определяешь интерфейс AuthStrategy и разные реализации. И подсовываешь ту стратегию, которая нужна для конкретного теста. Гибко, блядь. Захотел поменять — подменил одну стратегию другой, и нихуя не сломалось.

Короче, использование этих паттернов — это не какая-то академическая хуйня. Это реально делает фреймворк устойчивым, когда дизайнеры или разработчики начинают всё двигать. Ты меньше тратишь времени на починку тестов и больше — на написание новых. А иначе будешь как тот Герасим, только топишь не Муму, а свои же тестовые сценарии, потому что поддерживать их станет невмоготу.