Интеграционные тесты

В этом документе представлена информация о фреймворке интеграционного тестирования, используемом в проекте.

Обзор

Интеграционные тесты предназначены для проверки функциональности Qwen Code от начала до конца. Они запускают собранный бинарный файл в контролируемой среде и проверяют, что он ведёт себя ожидаемым образом при взаимодействии с файловой системой.

Эти тесты находятся в каталоге integration-tests и запускаются с помощью специального тестового раннера.

Запуск тестов

Интеграционные тесты не выполняются как часть команды по умолчанию npm run test. Их необходимо запускать явно с помощью скрипта npm run test:integration:all.

Интеграционные тесты также можно запустить с помощью следующего сокращения:

npm run test:e2e

Запуск определённого набора тестов

Чтобы запустить подмножество тестовых файлов, можно использовать npm run <команда_интеграционного_теста> <имя_файла1> ...., где <команда_интеграционного_теста> — это test:e2e или test:integration*, а <имя_файла> — любой из файлов .test.ts в каталоге integration-tests/. Например, следующая команда запускает list_directory.test.ts и write_file.test.ts:

npm run test:e2e list_directory write_file

Запуск одного теста по имени

Чтобы запустить один тест по его имени, используйте флаг --test-name-pattern:

npm run test:e2e -- --test-name-pattern "reads a file"

Запуск всех тестов

Чтобы запустить весь набор интеграционных тестов, используйте следующую команду:

npm run test:integration:all

Матрица песочниц

Команда all запускает тесты для no sandboxing, docker и podman. Каждый отдельный тип можно запустить с помощью следующих команд:

npm run test:integration:sandbox:none

npm run test:integration:sandbox:docker

npm run test:integration:sandbox:podman

Диагностика

Тестовый раннер интеграционных тестов предоставляет несколько опций для диагностики, чтобы помочь отследить причины падения тестов.

Сохранение вывода тестов

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

Чтобы сохранить вывод тестов, установите переменную окружения KEEP_OUTPUT в значение true.

KEEP_OUTPUT=true npm run test:integration:sandbox:none

Когда вывод сохраняется, тестовый раннер выведет путь к уникальному каталогу для данного тестового запуска.

Подробный вывод

Для более детальной отладки установите переменную окружения VERBOSE в значение true.

VERBOSE=true npm run test:integration:sandbox:none

При использовании VERBOSE=true и KEEP_OUTPUT=true в одной команде вывод транслируется на консоль и также сохраняется в файл журнала внутри временного каталога теста.

Подробный вывод форматируется таким образом, чтобы чётко идентифицировать источник логов:

--- TEST: <log dir>:<test-name> ---
... вывод команды qwen ...
--- END TEST: <log dir>:<test-name> ---

Линтинг и форматирование

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

Запуск линтера

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

npm run lint

Вы можете добавить флаг :fix к команде для автоматического исправления исправимых ошибок линтинга:

npm run lint:fix

Структура каталогов

Интеграционные тесты создают уникальный каталог для каждого тестового запуска внутри каталога .integration-tests. Внутри этого каталога создаётся подкаталог для каждого тестового файла, а внутри него — подкаталог для каждого отдельного тестового случая.

Такая структура упрощает поиск артефактов для конкретного тестового запуска, файла или случая.

.integration-tests/
└── <run-id>/
    └── <test-file-name>.test.ts/
        └── <test-case-name>/
            ├── output.log
            └── ...другие артефакты теста...

Непрерывная интеграция

Чтобы гарантировать, что интеграционные тесты запускаются всегда, в файле .github/workflows/e2e.yml определён рабочий процесс GitHub Actions. Этот рабочий процесс автоматически запускает интеграционные тесты для pull request’ов в ветку main или когда pull request добавляется в очередь слияния.

Рабочий процесс запускает тесты в различных средах изоляции (sandboxing), чтобы Qwen Code был протестирован в каждой из них:

• sandbox:none: Запускает тесты без какой-либо изоляции.
• sandbox:docker: Запускает тесты в контейнере Docker.
• sandbox:podman: Запускает тесты в контейнере Podman.