Данная страница предназначена исключительно для сохранения некоторых мыслей и планов про новую версию Аллюра. Мы считаем, что пора уже выпускать новую кленовую версию 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;
    }
}

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

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

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]

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