Allure 1.5 development page

Данная страница предназначена исключительно для сохранения некоторых мыслей и планов про новую версию Аллюра. Мы считаем, что пора уже выпускать новую кленовую версию 2.0. Основные изменения/улучшения:

• Сосредоточиться на стабилизации модели. Продумать возможные использования. Модель должна лежать в отдельном репозитории, хорошо документированная. Какие планируются изменения модели:
  • Избавиться от сущности TestSuiteResult. Информация о тестах может находиться в двух типах файлов: .*-testcase.xml и .*-testcase-group.xml
  • Добавить возможность сохранять в модели фазы before, after etc
  • Шаги - добавить аттрибут threadId
  • Шаги - может стоит добавить параментры?
• Миграции. Теперь каждое изменение модели, должно сопровождаться файлом миграции. Отчет всегда строится последней версии, предварительно применив миграции к файлам
  • Написать миграции с 1.3
• Система нотификаций. Информация о прерванных тестах и прочее

Генерация отчета

Одной из больших проблем сейчас является генерация данных для отчета из xml. Проблемы:

• XSLT требует достаточно много памяти
• Сложно разобраться/модифицировать XSLT
• Плохая расширяемость

Как это выглядит сейчас

Минусы:

• В рамках данной архитектуры сложно реализовать замену имен аттачей (хочется заменить на sha256 чтобы убрать дубликаты)
• Сбор всех данных о тестах в один файл - не лучшая идея

Как я вижу себе новую систему генерации

• Большую часть тест кейса (степы, аттачи etc) мы может сразу сохранить в testcase.json
• В объекте Stats считается время начала рана, конца, длительность и статистика (количество упавших etc).
• Также в Stats хранится список TestCaseInfo, который содержит тайтл кейса, статус и его лейблы.

Тут еще должны быть файлы {testSuiteName.xml}, пока не придумал что с ними делать

Немного мыслей

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

pubic class DescriptionConverter implements Converter<Description, Description> {
    public Description convert(Description description) {
        if (MARKDOWN.equals(description.getType())) {
            description.setText(new Pegdown().process(description.getText()));
        }
        return description;
    }
}

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

Report generation phases

1. Before generation
2. Prepare
3. Process cases
4. Execute providers
5. After generation

Report generation algorithm

1. Find all test cases by pattern in result directories
2. Create empty TestRunInfo object
   1. Run start/stop/duration
   2. Tests statuses. Count of passed/failed etc
   3. List of TestCaseInfo. Each element contains the following information
      1. Name/title
      2. Start/stop/duration
      3. Status
      4. List of labels
3. For each test case:
   1. Convert to new format [we can do it async]
      1. Add duration
      2. Move severity from labels
      3. NOTE: can load some data using plugins from external systems
      4. NOTE: attachments. We should be able to process attachments during this step. And example - rename each attachment using sha256
   2. Update TestRunInfo
4. Find all providers [plugins?]
5. Execute providers [we can do it async]

An example of provider logic (xUnit)

1. Create AllureXUnit object
2. Copy stats from TestRunInfo
3. Group test cases by suite label
4. For each group
   1. Create AllureTestSuite object
   2. Find suite data . By default by pattern in result directories. Can be overloaded/amended using plugins (an example using @TestId annotation from TMS)
   3. Update AllureTestSuite
5. Serialize AllureXUnit to report directory