Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Те, кто не первый год читает мой блог, возможно, заметили, что если я хочу что-то изучить – я ставлю себе задачу написать об этом статью. В 2020 году я читала по книге о тестировании в месяц и писала отзывы на них. В 2023 я изучала по одной логической ошибке в месяц, и писала объясняющие эти ошибки статьи (и в результате написала книгу о логических ошибках для тестировщиков).

Ближайшие пять месяцев у меня новый челлендж: изучить принципы чистого кода (SOLID). Я много лет хотела в них разобраться, но меня всегда пугала терминология («принцип подстановки Лисков» звучит, как что-то сложное). Я, однако, сделаю все, чтобы изучить эти принципы и объяснить их на примерах, полезных тестировщикам. Начнем с принципа единственной ответственности – буквы S в акрониме SOLID.

Принцип единственной ответственности гласит, что каждый класс должен иметь лишь одну ответственность. Рассмотрим класс Login:

class Login {
    constructor() {}
    login(username, password) {
       driver.findElement(By.id('username'))
        .sendKeys(username)
    driver.findElement(By.id('password'))
        .sendKeys(password)
    driver.findElement(By.id('submit')).click()
    }
 
    navigate(url) {
       driver.get(url)
    }
}

У класса Login два метода: login и navigate. Это имеет смысл для любого автоматизатора – логин и навигация часто осуществляются в начале теста. Однако логин и навигация – по сути совершенно разные вещи.

Представим, что теперь пользователям доступна многофакторная аутентификация. Инженер-автоматизатор хочет добавить новый метод входа, включающий многофакторную аутентификацию. Но как это повлияет на метод навигации? Возможно, что никак, но если в класс добавляются новые импорты пакетов, они потенциально способны сломать метод навигации.

Каждый раз, когда класс меняется, перемены могут сломать существующую функциональность. Инженеру-автоматизатору придется проверить все тесты, где есть навигация, а также все тесты, где есть вход в систему.

Поэтому лучше, когда у каждого класса лишь одна-единственная ответственность. Метод навигации надо вынести в его собственный класс. Тогда при добавлении новых методов входа это никак не затронет метод навигации. К тому же можно будет добавлять новые навигационные методы, никак не повлияв на методы входа!

Обсудить в форуме