Buggy¶

Buggy - это надстройка над TestNG для быстрого создания/подключения тестового проекта, разработки и вариативнго запуска автотестов.

Основная документация содержит следующие разделы:

Описание¶

Позволяет¶

Легко и просто подключить TestNG к проекту с тестами. Как пример, смотреть модуль buggy-min-example.
Собирать готовый к исполнению jar.
Обрабатывать параметры запуска и расширять уже существующую конфигурацию (JCommander).
Автоматически собирать исполняемые тестовые классы в сьюты для последующего запуска в TestNG.
Автоматически собирать и добавлять в TestNG необходимые листенеры.
«На горячую» перезагружать настройки логирования.
Регулировать запуск тестов по типу.
Регулировать запуск тесов по компонентам, сервисам или интерфейсам тестируемой системы.
Транслировать результаты запуска в различные сервисы.

Реализовано¶

Управление конфигурацией запускаемых тестов.
Расширение существующей конфигурации через собственные интерфейсы.
Листенер для IntelliJ IDEA TestNG плагина для запуска тестов из IntelliJ IDEA
Атомарное логирование для каждого тестового или конфигурационного метода в отдельный файл.
Цветовая дифференциация консольных логов.
Механизм мониторинга исполняемых тестов.
Базовый Telegram-нотификатор.
Модуль к feign клиенту (утилиты).
Модуль к okhttp клиенту (утилиты).

Предстоит¶

Модуль интеграция c TestRail (трансляции результатов).
Модуль интеграция с ReportPortal (трансляции результатов).
Модуль к Retrofit клиенту (утилиты).
Модуль работы с protobuf.

Конфигурация¶

PrimaryConfig¶

Базовая конфигурация представлена индексируемым интерфейсом PrimaryConfig.
Класс реализации интерфейса PrimaryConfig будет автоматически подгружен, создан экземпляр и использован для конфигурации по умолчанию (получить: Buggy.getPrimaryConfig()).
В случае наличия несколькоих классов реализации интерфейса PrimaryConfig, класс требуемой конфигурации задаётся явно - Buggy.setPrimaryConfigClass() (в случае многомодульностьи тестового проекта).
Класс реализации интерфейса PrimaryConfig может быть имплементирован от множества конфигурационных интерфейсов, в том числе и из разных проектов.
Значения парамтеров „по умолчанию“ переназначаются в классе реализации. Пример org.touchbit.buggy.example.min.config.Config:

public class Config implements PrimaryConfig {

    public Config() {
        setPrintLogFile(true);
    }
}

SecondaryConfig¶

Дополнительная конфигурация (команды) представлена индексируемым интерфейсом SecondaryConfig.
Любой класс реализации интерфейса SecondaryConfig будет автоматически подгружен и создан экземпляр (получить список: Buggy.getSecondaryConfigs()).
Класс реализации интерфейса SecondaryConfig может быть имплементирован от множества конфигурационных интерфейсов, в том числе и из разных проектов.
Для класса реализации интерфейса SecondaryConfig обязательно наличие аннотации com.beust.jcommander.Parameters с объявленным commandNames.
Пример: org.touchbit.buggy.example.min.config.MinExampleSecondaryConfig

Параметры запуска¶

Параметры запуска¶
Keys		Default	Description
–help	-?	false	Вывести информацию с параметрами запуска.
–all		false	При запуске тестов вывести в лог все параметры конфигурации и их значения.
–check		false	Проверить конфигурацию на корректность без запуска тестов.
–version	-v	false	Вывести версию исполяемого jar.
–force	-f	false	Запуск всех тестов без исключения.
–print-suite		false	Вывести информацию о тестовом сьюте.
–print-cause		false	Вывести причину падения/исключения теста.
–print-log		false	Вывести в лог путь к файлу выполненного теста.
–log		logs	Относительный или абсолютный путь к директории ведения логов.
–status		null	Статус с которым следует принудительно завешить прогон тестов.
–threads		50	Количество потоков для исполняемых тестовых методов.
–services	-s	Runtime	Список доступных для тестирования сервисов.
–interface	-i	Runtime	Список доступных для тестирования интерфейсов.
–type	-t	INTEGRATION	Тип проводимого тестирования.
–artifacts-url		null	Url к логам тестов (CI)

Примеры¶

Вывод параметров запуска¶

$ java -jar buggy-min-example/target/Buggy.jar -?

===============================================
Usage: Buggy [options] [command] [command options]
  Options:
    --artifacts-url
      The storage address for the builds (artifacts).
    --check
      Check buggy configuration without test run.
    -f, --force
      Running all tests, including those that fall.
    -?, --help
      Print usage.
    -i, --interface
      List of tested interfaces in the format: NAME,NAME,NAME.
      Default: [API]
    --print-cause
      Print the cause of a fail or skip test in the console log.
    --print-log
      Print the test log file path in the console log
    --print-suite
      Display information on the Suite in the console log.
    -s, --services
      List of tested services in the format: NAME,NAME,NAME.
      Default: [GITLAB]
    --threads
      The number of threads to run the test methods.
      Default: 50
    -t, --type
      Type of tests to run.
      Default: INTEGRATION
      Possible Values: [SMOKE, MODULE, INTEGRATION, SYSTEM]
    -v, --version
      Print program version
  Commands:
    network
      Usage: network [options]
        Options:
          --connection-timeout
            Connection timeout for request
            Default: 10
          --host
            Tested host
            Default: http://example.com
          --read-timeout
            Read timeout for response
            Default: 10
          --write-timeout
            Write timeout for request
            Default: 10

Запуск тестов c флагами¶

Подключение¶

Maven зависимости¶

Для подключения проекта необходимо в первую очередь добавить в pom.xml репозиторий

<repositories>
    <repository>
        <id>touchbit</id>
        <url>https://touchbit.org/repository/</url>
    </repository>
</repositories>

Далее есть 2 пути развития событий, простой и правильный.

Простое подключение проекта¶

Для уменьшения головной боли при создании нового проекта с тестами, рекомендуется унаследоваться от корневого pom.xml Buggy.

Для этого необходимо добавить в pom.xml на уровне <project> родителя:

<parent>
    <groupId>org.touchbit.buggy</groupId>
    <artifactId>buggy</artifactId>
    <version>?.?.?</version>
</parent>

Это нам даёт следующие приемущества:

Версия gdfgdggdfgdggdfgdg

Конфигурирование проекта¶

Зависимости¶

buggy-core¶

buggy-min-example¶

buggy-testrail¶

TestRail¶

If you plan to use one TestRail Run ID for autotests, then you need to make changes to the TestRail database.

Connect to DB (for example mysql)

mysql -u 'testrail@192.168.1.1' -pPASSWORD testrail

Remove restrictions from statuses
UPDATE statuses SET is_final=0;

Using¶

Совет

More clearly the module connecting mechanism is shown in the buggy-min-example module.

Configuring pom.xml¶

If buggy is not used as a parent project

<dependency>
    <groupId>org.touchbit.buggy</groupId>
    <artifactId>buggy-testrail</artifactId>
    <version>0.3.0</version>
    <scope>compile</scope>
</dependency>

If buggy is used as parent project

<dependency>
    <groupId>org.touchbit.buggy</groupId>
    <artifactId>buggy-testrail</artifactId>
</dependency>

Configuring project¶

StatusMapper¶

Совет

If you do not use custom statuses, then this item can be skipped.

To manage statuses and transfer custom statuses, you need to create a class implementing the StatusMapper<> interface and define your own mapping for the statuses used. This is necessary in order for match statuses used in Buggy with TestRail statuses. For example:

import org.touchbit.buggy.core.model.Status;
import org.touchbit.buggy.testrail.StatusMapper;
import org.touchbit.testrail4j.core.type.Statuses;

public class StatusMap implements StatusMapper<Status> {

    @Override
    public long getId(Status status) {
        switch (status) {
            case SUCCESS:       return Statuses.PASSED.getId();
            case BLOCKED:       return Statuses.BLOCKED.getId();
            case UNTESTED:      return Statuses.UNTESTED.getId();
            case FAILED:        return Statuses.FAILED.getId();
            case FIXED:         return Statuses.CUSTOM_STATUS1.getId();
            case IMPLEMENTED:   return Statuses.CUSTOM_STATUS2.getId();
            case CORRUPTED:     return Statuses.CUSTOM_STATUS3.getId();
            case EXP_FIX:       return Statuses.CUSTOM_STATUS4.getId();
            case SKIP:          return Statuses.CUSTOM_STATUS5.getId();
            case EXP_IMPL:      return Statuses.CUSTOM_STATUS6.getId();
            default:
                throw new RuntimeException("Unhandled status received: " + status);
        }
    }
}

DefaultTestRailListener¶

Create a listener inherited from the class DefaultTestRailListener and, if necessary, pass your specific StatusMapper to the super class. For example:

import org.touchbit.buggy.testrail.listeners.DefaultTestRailListener;

public class TestRailListener extends DefaultTestRailListener {

    public TestRailListener() {
        super(new StatusMap());
    }

}

Or develop your own listener like DefaultTestRailListener with your own implementation of the afterInvocation (IInvokedMethod, ITestResult) method

Examples¶

Overview¶

Custom StatusMapper¶

Default StatusMapper¶