Вимоги до тестування

Кожна зміна в поведінці системи має містити тести, які підтверджують її правильність і забезпечують можливість налагодження.

Мінімальні очікувані показники

Для більшості завдань, пов’язаних із розробкою нових функцій, додайте або оновіть тести, які охоплюють:

• Правильність побудови конвеєра (очікувані фрагменти/формат рядка).
• Аналіз/перевірка поведінки (узгодження параметрів і випадки невдалої перевірки).
• Поведінка під час виконання (run), зокрема, шляхи обробки даних (push/pull) та завершення роботи, якщо це необхідно.
• Якість діагностики (корисність PipelineReport для аналізу сценаріїв виникнення помилок).

Необхідні типи тестів залежно від змін.

Новий вузол або група вузлів.

• Перевірки на рівні окремих модулів для детермінованого генерування фрагментів.
• Перевірка/аналіз охоплення для обмежень або припущень щодо зв’язків.
• Необхідно передбачити щонайменше один сценарій інтеграції, який підтверджує працездатність вузла в реалістичному ланцюгу.

Зміни в організації процесів у середовищі виконання/конвеєрі.

• Тест для перевірки успішного сценарію з метою підтвердження очікуваної поведінки.
• Тест на випадок помилки, що перевіряє перевищення встановленого часу, відсутність плагіна або недійсні умови для графа.
• Перевірки безпеки під час завершення роботи/життєвого циклу, коли змінюється обробка стану.

Зміни в сигнатурі публічного API

• Додайте або оновіть інформацію про покриття коду під час компіляції, щоб перевірити зміни у відкритих заголовках/способах їх використання.
• Для нерозривних розширень перевірте, чи існуючий код, що їх використовує, все ще компілюється.
• Для затверджених змін, що порушують зворотну сумісність, додайте тести/приклади, орієнтовані на міграцію, які підтверджують правильність заміни шляху API.

Зміни в прив’язці для Python (python/, pyneat)

• Додайте/оновіть покриття тестами pytest у рамках python/tests.
• Описуйте контракти взаємодії (шляхи NumPy/PyTorch DLPack, поведінка при копіюванні та створенні нульової копії).
• Додайте щонайменше один імпортний/функціональний тест для перевірки встановленого пакета або встановленого в режимі редагування.

Зміни в системах діагностики або моніторингу

• Додано/змінено тести для полів звіту.
• Безпечна поведінка в умовах одночасного доступу під час оновлення даних з потоків, що обробляють дані в режимі реального часу.

Політика щодо регресії та детермінізму.

• Виправлення помилок повинні містити регресійне тестування.
• Віддавайте перевагу тестам, які перевіряють детерміноване формування імен і стабільне створення конвеєра.
• Якщо вихідні дані мають бути навмисно недетермінованими, задокументуйте причину та обмежте перевірки стабільними інваріантами.

Витрати CPU в тестах пропускної здатності

async_yolov8_tput_test повідомляє користувацький, системний та загальний час CPU всього процесу в мікросекундах на завершений кадр, а також average_busy_cores. Останнє значення — це час CPU, поділений на астрономічний час, а не відсоток усієї плати чи завантаження прискорювача. Воно може перевищувати одиницю, коли кілька потоків CPU працюють одночасно.

Його cpu_window_fps використовує те саме вікно, що й лічильники CPU: від моменту перед першою вимірюваною подачею до звільнення останнього виходу. Прогрівання, перевірку результатів, звітування та завершальне очищення виключено. Наявне вікно avg_fps і критерій пропускної здатності не змінюються. output_extraction_included і output_validation визначають виконану тестом роботу; порівнюйте еквівалентні налаштування. Неповні або числово невдалі запуски повідомляють cpu_window_complete=0 без значень CPU на кадр. Невиконання критерію пропускної здатності все одно дає вимірювання для кадрів, які в іншому успішно завершено.

Нові бенчмарки можуть використовувати tests/perf/process_cpu_metrics.h для двох знімків лічильників усього процесу за запуск. Не опитуйте лічильники CPU покадрово й не додавайте потік моніторингу лише заради обчислення CPU на кадр.

Пропустіть політику.

• Розглядайте шляхи обходу як винятки, а не як звичайний потік керування.
• Суворі тести (за замовчуванням) повинні завершуватися з помилкою, якщо їх неможливо виконати через відсутність необхідного середовища виконання, інструментів або допоміжних компонентів.
• Лише тести, які чітко позначено як long, можуть використовувати семантику пропуску (return 77) і їх слід запускати у щотижневому циклі.
• Нові додані тести не повинні містити skip_test(...) у чітко визначених шляхах.

Практичні команди

Використовуйте точку входу для збірки проєкту:

./build.sh --all

Для змін, які впливають на документацію, також виконайте:

./build.sh --doc

Див. Створити, щоб отримати інформацію про всі підтримувані режими збірки та тестування.

Перелік вимог до авторів

Перед тим, як відкрити або об’єднати запит на внесення змін:

• Додано/оновлено тести, які відповідають змінам у поведінці системи.
• Наявні пов’язані тести все ще успішно проходять.
• Документацію оновлено, щоб відобразити зміни в поведінці, які користувачі можуть бачити.
• Зміни в API/архітектурі відображаються в Архітектура.
• Зміни у публічному API відповідають політиці сумісності API, визначеній у Стандарт кодування.

Обов’язкове покриття та профілі можливостей

Канонічні групи CTest записують точний вибір тестів перед виконанням і звіряють його зі свіжими результатами JUnit. Порожній вибір, відсутні чи дубльовані результати, пропуски, вимкнені тести та невдале виконання означають невиконання обов’язкового покриття. Селекторами, аргументами й граничними строками тестів керує група перевірки, а не інструмент обліку.

Реєстрація нетривалого тесту не може обійти вимоги через SKIP_RETURN_CODE, регулярний вираз пропуску чи середовище лише для тривалих тестів. Обов’язкова група також може вибрати наявні тривалі тести з канонічною реєстрацією коду 77, але фактичний пропуск усе одно є невдачею. Fast зберігає свої стрес-тести з міткою тривалих; вони не виключаються непомітно. Кількість посилань на пропуск у джерелах має довідковий характер і не є кількістю пропущених тестів.

cmake/NeatGuardedTests.cmake реєструє тести й навчальні приклади через наявний апаратний супервізор, коли SIMANEAT_GUARDED_HARDWARE_TESTS=ON. Це не створює апаратного допуску. Захищена кваліфікація вмикається явно; стандартний CI виконує тести безпосередньо, без сокета супервізора. Отримайте налаштоване володіння пристроєм і допуск перед запуском захищених нативних груп. Валідатор результатів перевіряє політику реєстрації; він не замінює супервізор і не дозволяє апаратне виконання.

Групи Python записують вибрані та явно виключені ідентифікатори тестів. Обов’язкові результати підготовки, виклику й завершення мають бути успішними. Налаштуйте необов’язкове покриття до вибору:

Профіль	Налаштування	Вимога
Середовище виконання Python	NEAT_CI_PYTHON_PROFILE=runtime (типово)	Вмикає Graph Phase 3 з підготовленими тестовими даними ResNet; Torch явно виключено.
Інтеграція Torch	NEAT_CI_PYTHON_PROFILE=torch	Задайте перевірену точну версію NEAT_CI_TORCH_VERSION; встановлення та імпорт мають завершитися успішно.
Камера MIPI	SIMA_NEAT_TEST_MIPI_CAMERA=1	Надайте камеру, SIMA_NEAT_TUTORIAL_MODEL_MIPI та SIMA_NEAT_TUTORIAL_MIPI_DECODE.
Щотижневі потоки HTTP	NEAT_CI_STREAM_PROFILE=http (типово)	Надайте URL потоків HTTP MJPEG і додатну частоту FPS. Обидва випадки HTTP та синхронна базова перевірка залишаються обов’язковими.
Щотижневі потоки HTTP + RTSP	NEAT_CI_STREAM_PROFILE=all	Додатково надайте URL потоків RTSP H264, H265 та MJPEG і додатну частоту MJPEG FPS.

Тест API камери без обладнання завжди входить до профілю середовища виконання. Виключення камери та Torch залишаються прогалинами покриття, а не успіхами. Профілі потоків охоплюють реєстрації codec_stream; вони не кваліфікують інші виключені групи RTSP. Кожний потоковий випадок має окремі результати базової перевірки та повторної перевірки контракту, тому доступний потік HTTP не може приховати невиконаний випадок RTSP під загальним PASS.

Для щотижневої підготовки моделей задайте локальний шлях або адресу HTTPS і перевірений SHA-256 для кожного з SIMA_CI_MNIST_MODEL, SIMA_CI_SSD300_MODEL, SIMA_CI_MNIST_IMAGES та SIMA_CI_MNIST_LABELS. Кожна контрольна сума використовує відповідну змінну _SHA256. Вхідні дані набору — стиснені тестові файли MNIST IDX. Підготовка перевіряє точні байти й готує кеш та змінні наявних тестів; відсутні або невідповідні входи є помилками підготовки. Вона ніколи не змінює сторонній наявний кеш. Підготовка моделей не залежить від доступності RTSP.

Зберігайте звіти вибору, результатів і виключень профілю разом із результатами групи. Успіх вибраного профілю не означає, що пройшли всі необов’язкові апаратні або інтеграційні профілі.

Локальна щотижнева підготовка

Використовуйте tools/ci/prepare_weekly_fixtures.py і для локальних запусків, і для CI. Типово підготовка потребує і mnist, і ssd300. Щоб кваліфікувати лише MNIST, явно передайте --fixture-group mnist; звіт позначить SSD300 як некваліфікований. Цей вибір не змінює вибір CTest і не перетворює пропущений обов’язковий випадок на успішний. Повна щотижнева кваліфікація все одно потребує обох груп.

Використовуйте --environment-json <file> для локального засобу запуску, --github-env <file> для GitHub Actions або обидва параметри. Обидва виходи містять те саме відображення середовища. Локальний засіб запуску має додати JSON-відображення до середовища тестового процесу перед записом вибору чи допуском апаратного процесу. JSON не є сценарієм оболонки або результатом тесту. Саме створення файла не експортує змінні.

Допоміжний засіб експортує SIMA_RUN_MNIST_PREPROC_CHANNELS1=1, лише коли вибрана модель і файли MNIST gzip/IDX пройшли перевірку. Він перевіряє CRC gzip, геометрію IDX, довжину, кількість зображень і міток та діапазон міток і відхиляє суперечливі стиснені чи сирі записи кешу. Використовуйте новий вихідний каталог для кожної спроби підготовки; невдалі підготовлені байти залишаються для діагностики.

Встановлені пакети та інтеграція у приватному префіксі

Розрізняйте ці області кваліфікації:

• Інтеграція у приватному префіксі перевіряє вибрані заголовки, бібліотеки та зовнішні модулі без зміни глобальної бази пакетів. Вона не кваліфікує встановлення Debian.
• Кваліфікація встановлених пакетів звіряє фактичну кореневу файлову систему DevKit, записи dpkg, байти вмісту, символічні посилання та володіння файлами з вибраними перевіреними архівами. Приватний префікс не задовольняє цю перевірку.

Продовжуйте перевіряти склад дистрибутива через scripts/ci/verify_core_dist.sh, зокрема з незалежно вибраними входами --expected-manifest, --expected-receipt і --expected-deb-dir під час локального збирання. Використовуйте повний дистрибутив виробника, включно з п’ятьма варіантами метаданих. Віддалене встановлення через sima-cli готує вибрані ресурси, але не зберігає ці файли метаданих. Робочий процес CI окремо завантажує повний артефакт neat-core-dist цього запуску, а потім звіряє фактично встановлені через CLI пакети з цим незалежним входом. Не відтворюйте метадані виробника зі встановленої машини.

Явно виберіть потрібний профіль пакетів:

Профіль	Обов’язкові ролі
core	Середовище виконання й розробка Core, розробка Kernels, Runner, Scheduler і пакет сумісності середовища виконання
core-codecs	core плюс пара середовища виконання й розробки Codecs
core-codecs-llima	core-codecs плюс пара середовища виконання/CLI LLiMa

Використані необов’язкові постачальники бекендів залишаються обов’язковими за вибраними записами виробника. Профіль не виводиться з відсутніх архівів. LLiMa та вилучена реалізація пам’яті не є безумовними залежностями тестів лише Core.

На DevKit збережіть --capture-platform-baseline <file> через tools/ci/verify_core_dist.py перед використанням наявного інсталятора. Після встановлення запустіть перевірку дистрибутива з --package-profile <profile>, --verify-installed, --platform-baseline <file> та --write-package-inventory <file>. Початковий стан записує, які відстежувані нативні пакети встановлені або відсутні. Він зберігає цей стан, версії сторонніх нативних пакетів і доступність команди OTA. Якщо вона наявна, її канонічний шлях, володіння й байти мають залишатися незмінними. Історичні назви пакетів і команда OTA не обов’язково існують у кожному образі; Palette залишається обов’язковим. Постачальника, явно включеного до перевіреного дистрибутива, можна оновити; тоді його звіряють із вибраним архівом.

Передайте абсолютний шлях переліку як SIMA_TEST_PACKAGE_INVENTORY, а шлях початкового стану до встановлення — як SIMA_TEST_PLATFORM_BASELINE наявній групі CTest devkit-package-inventory. Не знімайте початковий стан повторно після встановлення. Вибраний перелік містить очікувані дані архівів, а не PASS встановлення. Нативний тест незалежно перевіряє фактичні версії й архітектури пакетів, завантажені шляхи Core/бібліотек та володіння, незмінну наявність або відсутність невибраних нативних пакетів, відсутність вилучених пакетів та доступність і ідентичність OTA. Окремо продовжуйте компілювати приклади з установленими заголовками; наявність пакета не доводить, що споживач компілюється або бекенд виконався правильно.

Передумови нативних інструментів збирання

На Ubuntu встановіть build-essential, file, nlohmann-json3-dev та python3-venv перед виконанням вибору pytest інструментів збирання з .github/workflows/vulcan-ci.yml. Перевірка початкового стану платформи компілює свій справжній спільний контракт C++ з -Werror; відсутність компілятора чи заголовка є помилкою підготовки тесту, а не пропуском перевірки. За помилки включаються stdout/stderr компілятора, а file перевіряє нативний виконуваний файл перед запуском.