Где хранить локаторы при автоматизации UI?

Стратегии хранения локаторов в UI-автоматизации

Хранение локаторов — фундаментальный аспект архитектуры UI-тестов, напрямую влияющий на поддерживаемость, читаемость и устойчивость тестового кода. После 10+ лет в автоматизации я выделяю несколько проверенных стратегий, которые можно комбинировать в зависимости от масштаба и сложности проекта.

Основные подходы к хранению локаторов

1. Page Object Pattern (POP) / Page Object Model (POM)

Наиболее распространенный и рекомендуемый подход. Локаторы инкапсулируются внутри классов, представляющих страницы или компоненты приложения.

// Пример на Java с Selenium
public class LoginPage {
    // Локаторы хранятся как поля класса
    private By usernameField = By.id("username");
    private By passwordField = By.cssSelector(".password-input");
    private By submitButton = By.xpath("//button[@type='submit']");
    
    public void login(String user, String pass) {
        driver.findElement(usernameField).sendKeys(user);
        driver.findElement(passwordField).sendKeys(pass);
        driver.findElement(submitButton).click();
    }
}

Преимущества:

• Полная инкапсуляция логики страницы
• Простота использования и понимания
• Легкий рефакторинг при изменении локаторов

2. Отдельные файлы конфигурации

Локаторы выносятся во внешние файлы (JSON, YAML, XML, .properties), что позволяет изменять их без перекомпиляции кода.

# locators.yaml
login_page:
  username: "#username"
  password: ".password-input"
  submit: "//button[@type='submit']"

search_page:
  search_field: "input.search"
  results: ".results li"

# Пример загрузки в Python
import yaml

class LocatorLoader:
    def __init__(self, file_path):
        with open(file_path, 'r') as file:
            self.locators = yaml.safe_load(file)
    
    def get_locator(self, page, element):
        return self.locators[page][element]

3. Фабрика локаторов (Locator Factory)

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

public class LocatorFactory {
    public enum LocatorType {
        CSS, XPATH, ID, CLASS_NAME
    }
    
    public static By getLocator(LocatorType type, String value) {
        switch(type) {
            case CSS: return By.cssSelector(value);
            case XPATH: return By.xpath(value);
            case ID: return By.id(value);
            case CLASS_NAME: return By.className(value);
            default: throw new IllegalArgumentException("Unsupported locator type");
        }
    }
}

Критерии выбора стратегии

При выборе подхода учитывайте:

• Размер проекта: Для небольших проектов достаточно чистого POM. Крупные проекты выигрывают от комбинирования подходов.
• Частота изменений UI: Если интерфейс часто меняется, внешнее хранение локаторов упрощает поддержку.
• Командные соглашения: Единый стандарт в команде важнее "идеального" подхода.
• Язык программирования: Некоторые языки предлагают удобные DSL для работы с локаторами.

Рекомендации по организации

1. Единый стиль именования: Используйте понятные имена, отражающие бизнес-логику (submitButton, а не btn1).
2. Иерархическая структура: Группируйте локаторы по страницам, модулям или компонентам.
3. Избегайте хрупких локаторов: Отдавайте предпочтение id и data-test-id перед сложными XPath.
4. Документация: Комментируйте сложные или неочевидные локаторы.
5. Version Control: Все файлы с локаторами должны храниться в системе контроля версий.

Комбинированный подход (рекомендуемый)

На практике я рекомендую гибридный подход:

// Основные локаторы в Page Objects
public class BasePage {
    protected Map<String, By> componentLocators;
    
    protected void loadLocators(String pageKey) {
        // Загрузка дополнительных локаторов из внешнего источника
        componentLocators = LocatorConfigLoader.getLocatorsForPage(pageKey);
    }
}

// + внешний конфиг для часто меняющихся или кросс-платформенных локаторов

Такой подход дает гибкость: базовые локаторы в коде обеспечивают типобезопасность и навигацию по коду, а внешние конфиги позволяют быстро адаптироваться к изменениям UI без пересборки тестов.

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