Тестовый runner

НАЧАЛО >> TestA >> Тестовый runner📄 Скачать в DOCX

1. Размещение тестов

Тесты хранятся рядом с модулем:

modules/<Module>/Tests/Module.inc
modules/<Module>/Tests/__call/<Name>.inc
modules/<Module>/Tests/Actions/<Name>.inc
modules/<Module>/Tests/Pages/<Name>.inc
modules/<Module>/Tests/Scenarios/<Name>.inc

2. Несколько проверок одной цели

Один файл теста соответствует одной цели TestA: модулю, функции __call, действию, странице или сценарию. Если у одной функции проверяется несколько независимых свойств, их не нужно выносить в отдельные файлы. Run() может вернуть массив результатов, а для формирования отдельных строк отчета используются методы CheckOk, CheckFailed, CheckBlocked, CheckSkipped, CheckWarning и CheckUnstable.

Для таких тестов GetInfo()['title'] задает общее название проверки цели, например "Проверка функции Queue/GetDbQ", "Проверка действия Queue/GetState" или "Проверка страницы Queue/InfoQueue". Каждая под-проверка получает собственный суффикс идентификатора и понятный заголовок:

return array(
    $this->CheckOk('readonlyOpen', 'Открытие базы очереди в режиме чтения', $details),
    $this->CheckOk('schema', 'Проверка схемы базы очереди', $details),
);

Если проверка падает, сообщение должно описывать конкретное нарушенное условие, а технические данные нужно передавать в details.

Класс теста должен наследоваться от TestA_TestCase и реализовать Run($options, $ctx).

3. Метаданные проверки

GetInfo() возвращает manifest проверки. Минимальные поля id, title, levels и requires поддерживаются для старых тестов; новые промышленные проверки должны дополнительно указывать владельца и трассировку требований:

function GetInfo()
{
    return array(
        'id' => 'Queue.scenario.RetryPolicy',
        'title' => 'Повтор фонового задания по retry policy',
        'ownerModule' => 'Queue',
        'systemValue' => 'TASKS-VALUE-023',
        'version' => '1.0',
        'levels' => array('safe-read'),
        'requires' => array('Queue', 'TestA'),
        'dependencies' => array('TraceContext', 'HealthCheck'),
        'frCoverage' => array('QUEUE-FR-017', 'QUEUE-FR-018'),
        'tags' => array('contract', 'queue', 'retry'),
        'fixtures' => array('Queue/system-json'),
        'datasets' => array('Queue/golden-safe-read'),
        'expectedArtifacts' => array('report', 'summary', 'diagnostics'),
        'environmentAssumptions' => array('safe-read профиль не изменяет рабочие данные'),
    );
}

requires описывает обязательные runtime-зависимости проверки. Если обязательный модуль отсутствует, TestA не запускает тело теста и возвращает blocked; необязательную зависимость можно описать массивом с required => false, тогда результат будет skipped.

При запуске TestA добавляет нормализованный testInfo к результатам проверки, а отчет содержит contractVersion и безопасный environmentProfile: уровни, разрешенные уровни, псевдонимы тестовых БД, provider matrix и CI-профиль.

4. Уровни проверок

Поддерживаются уровни:

безопасное чтение (safe-read);
требуется авторизация (requires-auth);
изменение данных (writes);
очередь заданий (queue);
внешние сервисы (external);
разрушительные проверки (destructive);
ручная проверка (manual).

Если тест указывает несколько уровней, для запуска должны быть выбраны все эти уровни. Пишущие проверки очереди помечаются парой writes,queue и запускаются только при явном allowUnsafe=1. Такие проверки должны использовать изолированную очередь, а не рабочую QueueInfo.db.

В АРМ Администратор уровни выбираются чекбоксами в настройках модуля TestA: отдельно задаются уровни по умолчанию и уровни, разрешенные для запуска из интерфейса.

5. Контрактные проверки провайдеров

Провайдеры, которые участвуют в контрактных проверках, выбираются чекбоксами в настройках модуля TestA в АРМ Администратор. В интерфейсе показываются понятные названия провайдеров, а технические коды используются только в API, отчетах и коде тестов.

6. Интерфейс и JSON

Панель запуска:

?id=TestA/Dashboard

Опция "Включить структурные проверки для целей без явных тестов" запускает минимальную техническую проверку целей, для которых еще не написан отдельный тест: модуль должен загружаться, __call должен содержать Exec, действие должно загружаться через WIrbis, страница должна содержать Show. Эта проверка не заменяет сценарный тест и не подтверждает пользовательскую бизнес-логику.

JSON реестра целей:

?id=WIrbis&action=TestA/GetInventoryJson

JSON реестра целей с manifest проверок:

?id=WIrbis&action=TestA/GetInventoryJson&includeTestInfo=1

Синхронный запуск:

?id=WIrbis&action=TestA/RunSuite&levels=safe-read&queue=0

Синхронный запуск пишущих проверок очереди на изолированной тестовой очереди:

?id=WIrbis&action=TestA/RunSuite&levels=writes,queue&allowUnsafe=1&queue=0

Запуск через очередь:

?id=WIrbis&action=TestA/RunSuite&levels=safe-read&queue=1

Чтение отчета:

?id=WIrbis&action=TestA/GetReportJson&runid=<runid>