Этой статьей мы продолжаем серию публикаций о том, как мы автоматизировали в одном из крупных проектов ЛАНИТ процесс ручного тестирования (далее – автотесты) большой информационной системы (далее – Системы) и что у нас из этого вышло.

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

Источник

В этой статье мы описываем структуру классов и организацию кода, которая позволила нам небольшими силами разработать более полутора тысяч end-2-end UI тестов на базе Junit и Selenium для крупной системы федерального значения. Более того, мы ее успешно поддерживаем и постоянно дорабатываем существующие сценарии.

Здесь вы сможете найти практическое описание структуры иерархии базовых классов автотестов, разбиения проекта по функциональной модели java-packages и шаблоны-образцы реальных классов.

Статья будет полезна всем разработчикам, которые разрабатывают автотесты на базе Selenium.

Эта статья является частью общей публикации, в которой мы описывали, как небольшой командой выстраивали процесс автоматизации UI тестирования и разрабатывали для этого фреймворк на базе Junit и Selenium.

Предыдущие части: 

• Часть 1. Организационно-управленческая. Зачем нам была нужна автоматизация. Организация процесса разработки и управления. Организация использования
• Часть 2. Техническая. Архитектура и технический стек. Детали реализации и технические сюрпризы

Реализация базового класса для всех тестов и JUnit RuleChain

Концепция разработки автотестов, как было показано в предыдущей статье (Часть 2. Техническая. Архитектура и технический стек. Детали реализации и технические сюрпризы), базируется на идее фреймворка, при которой для всех автотестов предоставляется набор системных функций – они бесшовно интегрируются и дают возможность разработчикам автотестов концентрироваться на конкретных вопросах бизнес-реализации тест-классов.

Фреймворк включает следующие функциональные блоки:

• Rules – инициализация и финализация тестовых инфраструктурных компонентов как инициализация WebDriver и получение видеотеста. Более подробно описаны далее;
• WebDriverHandlers – вспомогательные функции для работы с веб-драйвером как исполнение Java Script или доступ к логам браузера. Реализованы как набор статических state-less методов;
• WebElements – библиотека типовых веб-элементов или их групп, которая содержит требуемую cross-function функциональность и типовое поведение. В нашем случае к такой функциональности относится возможная проверка завершения асинхронных операций на стороне веб-браузера. Реализованы как расширения веб-элементов из библиотек Selenium и Selenide.

Инициализация тестового окружения. Rules

Ключевым классом для всех тест-классов является BaseTest, от которого наследуются все тест-классы. BaseTest-класс определяет Junit «ранер» тестов и используемый RuleChain, как показано далее. Доступ из прикладных тестовых классов к функциям, предоставляемым rule-классами, осуществляется через статические методы rule-классов.   

Образец кода BaseTest представлен на следующей врезке.

@RunWith(FilterTestRunner.class)
public class BaseTest {
    private TemporaryFolder downloadDirRule                                                    
              = new TemporaryFolder(getSomething().getWorkingDir());
 
    @Rule
    public RuleChain rules = RuleChain
            .outerRule(new Timeout(TimeoutEnum.GLOBAL_TEST_TIMEOUT.value(),              
                                                         TimeUnit.SECONDS))
            .around(new TestLogger())
            .around(new StandStateChecker())
            .around(new WaitForAngularCreator())
            .around(downloadDirRule)
            .around(new DownloaderCreator(downloadDirRule))
            .around(new EnvironmentSaver())
            .around(new SessionVideoHandler())
            .around(new DriverCreator(downloadDirRule))
            .around(new BrowserLogCatcher(downloadDirRule))
            .around(new ScreenShooter())
            .around(new AttachmentFileSaver())
            .around(new FailClassifier())
            .around(new PendingRequestsCatcher());
 
   // набор методов провайдеров общесистемных данных из проперти файлов
   final protected SomeObject getSomething() {
        return Something.getData();
   }
   …
}

FilterTestRunner.class – расширение BlockJUnit4ClassRunner, обеспечивает фильтрацию состава исполняемых тестов на базе регулярных выражений по значению специальной аннотации Filter(value = «some_string_and_tag»). Реализация приведена далее.

org.junit.rules.Timeout – используется для ограничения максимального продолжения тестов. Должна устанавливаться первой, так как запускает тест в новой ветке.

TestLogger – класс, который позволяет тесту логировать события в формате json для использования в ELK-аналитике. Обогащает события данными теста из org.junit.runner.Description. Также дополнительно автоматически генерирует события для ELK в формате json для начала-завершения теста с его длительностью и результатом

StandStateChecker – класс, который проверяет доступность веб-интерфейса целевого стенда ДО инициализации веб-драйвера. Обеспечивает быструю проверку, что стенд доступен в принципе.

WaitForAngularCreator – класс, который инициализирует веб-драйвер хэндлер для контроля завершения асинхронных операций ангуляра. Используется для индивидуальной настройки «особых» тестов c длительными синхронными обращениями.

org.junit.rules.TemporaryFolder – используется для задания уникальной временной папки для хранения файлов для операций загрузки и выгрузки файлов через веб-браузер.

DownloaderCreator – класс, который обеспечивает поддержку операций выгрузки во временную директорию файлов, загруженных браузером и записанных через Sеlenoid видеофункцию.

EnvironmentSaver – класс, который добавляет в Allure-отчет общую информацию о тестовом окружении.  

SessionVideoHandler – класс, который выгружает файл видеотеста, при его наличии, и прикладывает к отчету Allure.

DriverCreator – класс, который инициализирует WebDriver (самый главный класс для тестов) в зависимости от установленных параметров – локальный, solenoid или ggr-selenoid. Дополнительно класс исполняет набор обязательных для нашего тестирования Java Scripts. Все правила, которые обращаются к веб-драйверу, должны инициализироваться после этого класса.

BrowserLogCatcher – класс, который считывает Severe сообщения из лога браузера, журналирует их для ELK (TestLogger) и прикладывает к Allure-отчету.

ScreenShooter – класс, который для неуспешных тестов снимает скриншот экрана браузера и прикладывает его к отчету аллюр как WebDriverRunner.getWebDriver().getScreenshotAs(OutputType.BYTES)

AttachmentFileSaver – класс, который позволяет приложить к Allure-отчету набор произвольных файлов, требуемых по бизнес-логике тестов. Используется для прикладывания файлов выгруженных или загружаемых в систему.

FailClassifier – особый класс, который пытается в случае падения теста определить, было ли это падение вызвано инфраструктурными проблемами. Проверяет наличие на экране (после падения) особых модальных окон типа «Произошла системная ошибка №ХХХХХХХХХ», а также системных сообщений типа 404 и тому подобное. Позволяет разделить упавшие тесты на бизнес-падения (по сценарию) или системные проблемы. Работает через расширение org.junit.rules.TestWatcher.#failed метод.

PendingRequestsCatcher – еще один особый класс, который пытается дополнительно классифицировать, было ли падение вызвано незавершенными, зависшими или очень длительными рест-сервисами между ангуляром и веб-фронтендом. Дополнительно к функциональному тестированию дает возможность определять проблемные и зависающие рест-сервисы при больших нагрузках, а также общую стабильность релиза. Для этого класс логирует в ELK все события с зависшими рест-запросами, которые он получает, запуская специальный js в браузере через открытый веб-драйвер.

Шаблон реализации тест-класса 

package autotest.test.<sub-system>;
@Feature("Развернутое название подсистемы как в TMS")
@Story("Развернутое название теста согласно TMS")
@Owner("фамилия автоматизатора вносящего последние правки в тест кейс")
@TmsLink("Номер теста согласно тест линку. Соответствует настроенному шаблону")
public class <Сквозной номер тест кейса>_Test extends BaseTest {
    /**
    * Объявляем логин от которой проходит целевой тест
    **/
    Login orgTest;
 
    /** Объявляем все логины участвующие в тесте как вспомогательные **/
    Login loginStep1;
    ...
    Login loginStepN;
    
    /**
    * Здесь перечисляются бизнес-объекты которые требуются для проведения теста - Тестовая сцена
    * ... для всех требуемых бизнес объектов
    **/
      /**
    * Инициализация тестовой сцены
    * Для каждого бизнес объекта необходимо вывести в отчет инициализированное значение
    *       Utils.allure.message("Бизнес имя объекта в контексте тест-сценария", business_object)
    * Если класс инициализируется как null, то его выводят в отчет с указанием на каком шаге он будет заполнен.
    * Далее этот тип объекта должен быть дополнительно выведен в отчет в методах preconditions или actions
    *       Utils.allure.message("Номер созданного документа заполняемого на шаге Х", documentNumber)
     **/
 
    @Step("Инициализация тестовых объектов")
    private void init(Login login) {
        some_business_object = // создание требуемого объекта в или вне зависимости от login
        Utils.allure.message("Бизнес имя объекта в контексте тест-сценария", some_business_object)
                            // ... для всех требуемых бизнес объектов
 
        /** Получаем значения вспомогательных логинов */
        loginStep1 = LoginFactory.get(_Some_Login_);
        ...
        loginStepN = LoginFactory.get(_Some_Login_);
 
    }
    
    /**
    * Реализация конкретного теста
    **/
    @Test
    @Filter("Название теста для использования фильтрации на уровне JUnit")
    @DisplayName("Развернутое название теста согласно TMS")
    public void <Сквозной номер тест кейса>_<Полномочие>_<Уникальный_номер_проверки>_Test() {
       // Получаем значение тестовой организации
        orgTest = LoginFactory.get(_Some_Login_);  
        
        // Инициализируем тестовые данные в зависимости от логина
        init(orgTest);
    
        // Выполняем шаги тестовых сценариев-предусловий. Шаги предусловия не должны зависеть от значения логина
        preconditions();
        
        // Выполняем шаги целевого тестового сценария
        actions(orgTest);
    }
    
    /**
    * Выполнение требуемого набора активности для предусловий теста
    **/
    @Step("Предварительные условия")
    protected void preconditions() {
        loginStep1.login();
        new SomeAction().apply(someTestObject1, ..., someTestObjectN);
            Utils.allure.message("Получено значение для - Бизнес имя объекта в контексте тест-сценария", someTestObjectN)
        ...
    } 
    
    /**
    * Метод содержит декларативный перечень операций тестового сценария
    */
    @Step("Шаги теста")
    protected void actions(Login testLogin) {
        testLogin.reLogin();
        
        // Выполнение требуемой активности или набора активностей основного теста
        new SomeAction().apply(someTestObject1, ..., someTestObjectN);
    }
}

 

Шаблон реализации класса тест-сценария

package autotest.business.actions.some_subsystem;
 
public class SomeAction {
    
                // ИНИЦИАЛИЗИРУЕМ СТРАНИЦЫ
    PageClassA pageA = new PageClassA();
    PageClassB pageB = new PageClassB();
 
    @Step("Полное наименование тестового сценария согласно TMS")
    @Description("Краткое описание тестового сценария согласно TMS")
    public void apply(someTestObject1, ..., someTestObjectN) {
        //Шаги сценария по TMS
        step_1(...);
        step_2(...);
        ...
        step_N(...);
    }
 
    @Step("Наименование шага 1 тестового сценария согласно TMS")
    private void step_1(...) {
       pageA.createSomething(someTestObject1);// just as an example create
    }
 
    @Step("Наименование шага 2 тестового сценария согласно TMS")
    private void step_2(...) {
    pageA.checkSomething(someTestObject1);// just as an example
    }
                
                ...
}

Реализация класса фильтрации тестов FilterTestRunner

Здесь показана реализация расширения BlockJUnit4ClassRunner для фильтрации тестов на основании произвольных наборов тегов.

/**
 * Custom runner for JUnit4 tests.
 * Provide capability to do additional filtering executed test methods
 * accordingly information that could be provided by {@link FrameworkMethod}
 */
 
public class FilterTestRunner extends BlockJUnit4ClassRunner {
    private static final Logger LOGGER = Logger.getLogger(FilterTestRunner.class.getName());
    public FilterTestRunner(Class<?> klass) throws InitializationError {
        super(klass);
    }
    /**
    * This method should be used if you want to hide filtered tests completely from output
    **/
    @Override
    protected List<FrameworkMethod> getChildren() {
        //Получаем экземпляр фильтра, который сравнивает заданный фильтр со значением аннотации @Filter по требуемой логике
        TestFilter filter = TestFilterFactory.get();
        List<FrameworkMethod> allMethods = super.getChildren();
        List<FrameworkMethod> filteredMethod = new ArrayList<>();
        for (FrameworkMethod method: allMethods) {
            if (filter.test(method)) {
                LOGGER.config("method [" + method.getName() +"] passed by filter [" + filter.toString() + "]"  );
                filteredMethod.add(method);
            } else {
                LOGGER.config("method [" + method.getName() +"] blocked by filter [" + filter.toString() + "]" );
            }
        }
        return Collections.unmodifiableList(filteredMethod);
    }
 
 
    /**
    * This method should be used if you want to skip filtered tests but no hide them
    @Override
    protected boolean isIgnored(FrameworkMethod method) {
        …
        if (filter.test(method)) {
            return super.isIgnored(method);
        } else {
           return true;
        }}
    */
}

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

Кстати, будем рады пополнить свою команду. Актуальные вакансии вот здесь.