Что такое наследование в ООП?

А, ну вот, наследование! Это ж классика, ёпта, как водка под селёдку. Представь, что у тебя есть старый дедовский чемодан — там уже лежат все базовые инструменты: отвёртка, молоток, пассатижи. И ты не таскаешь этот набор по каждому новому объекту отдельно, а просто берёшь этот чемодан и добавляешь в него специфичный для задачи инструмент. Вот это и есть наследование в ООП: один класс (родительский) отдаёт свои поля и методы другому (дочернему), а тот может ещё и своё прикрутить. Создаётся чёткая иерархия «является» (is-a). DRY-принцип, не повторяйся, блядь, святое дело для ленивого, но умного программиста.

Где это впиливается в автоматизацию? Да везде, сука! Чаще всего — для создания базовых тестовых классов, куда скидывают всю общую хуйню: конфигурацию драйвера, утилитные методы, подготовку данных. Чтобы не писать одно и то же в каждом втором тесте, ядрёна вошь.

Смотри, как это выглядит на практике: Базовый класс для UI-тестов на Selenium

// Это наш дедовский чемодан, базовый класс для всех UI-тестов.
public class BaseUITest {
    // Делаем поля protected, чтобы дети-наследники могли к ним лапами потыкать.
    protected WebDriver driver;
    protected WebDriverWait wait;

    // Метод, который отработает ПЕРЕД каждым тестом у наследников.
    @BeforeEach
    public void setUp() {
        // Инициализируем драйвер (допустим, Chrome)
        driver = new ChromeDriver();
        driver.manage().window().maximize();
        wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    }

    // Общий метод для логина. Чтоб в каждом тесте заново селекторы не прописывать.
    protected void login(String username, String password) {
        driver.findElement(By.id("username")).sendKeys(username);
        driver.findElement(By.id("password")).sendKeys(password);
        driver.findElement(By.id("login-btn")).click();
    }

    // Общий метод для скриншота на память, когда тест накрылся медным тазом.
    protected void takeScreenshot(String testName) {
        File screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);
        try {
            FileUtils.copyFile(screenshot, new File("screenshots/" + testName + ".png"));
        } catch (IOException e) { /* тут обработка ошибки, но нам да похуй в примере */ }
    }

    // Метод, который отработает ПОСЛЕ каждого теста. Чистим за собой.
    @AfterEach
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

// А вот наш наследник, конкретный тестовый класс.
// Ключевое слово 'extends' — это как сказать: «Папа, дай чемодан!».
class LoginPageTest extends BaseUITest {

    @Test
    void testSuccessfulLogin() {
        // Arrange: Драйвер и wait уже есть, они унаследованы! Красота.
        driver.get("https://myapp.com/login");

        // Act: Используем метод login() от родителя. Вообще не паримся.
        login("validUser", "validPass123");

        // Assert: А вот тут уже наша специфичная проверка.
        wait.until(ExpectedConditions.urlContains("/dashboard"));
        String welcomeText = driver.findElement(By.cssSelector(".welcome-msg")).getText();
        assertTrue(welcomeText.contains("validUser"));
    }

    @Test
    void testLoginWithInvalidPassword() {
        driver.get("https://myapp.com/login");
        login("validUser", "wrong");

        String errorMessage = driver.findElement(By.id("error")).getText();
        assertEquals("Invalid credentials", errorMessage);
    }

    // А вот тут магия: мы можем ПЕРЕОПРЕДЕЛИТЬ (override) родительский метод, если его поведение нас не устраивает.
    @Override
    @AfterEach
    public void tearDown() {
        takeScreenshot(this.getClass().getSimpleName()); // Сначала делаем свой скриншот
        super.tearDown(); // А потом вызываем родительский метод, чтобы драйвер закрылся
    }
}

Что мы, как QA, с этого имеем, кроме морального удовлетворения?

1. Нет дублирования кода. Всё общее — в одном месте. Поддержка — одно удовольствие, а не пиздец.
2. Единообразие. Все тесты стартуют в одинаковых условиях, доверия к результатам — овердохуища.
3. Лёгкость поддержки. Захотел поменять браузер на Firefox? Идёшь в один-единственный setUp() в базовом классе и меняешь. Во всех наследниках автоматом подтянется. Волнение ебать как снижается.
4. Чистая архитектура. Можно наделать разных базовых классов: BaseAPITest для API, BaseMobileTest для мобилки. И от них плодить специализированные тесты.

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