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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

./build.sh --all

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

./build.sh --doc

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

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

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

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