Тестирование в инженерной разработке: как проверять код, модели и прошивки

Тестирование — это не формальная галочка в конце спринта и не этап, который можно безболезненно отложить до «потом». В инженерной разработке это один из базовых механизмов управления риском. Когда работаешь с микроконтроллерами, даже небольшой дефект в обработке данных с датчика может вылиться в неверные измерения, ложные срабатывания или нестабильную работу устройства на объекте. В ML-задачах картина похожая: код может быть синтаксически безупречным, пайплайн — аккуратно собранным, но если валидация данных сделана небрежно, модель начнёт уверенно ошибаться, а заметите вы это слишком поздно.

На практике особенно неприятны проекты на стыке embedded и AI. Там у вас одновременно есть ограничения по памяти, таймингам, питанию, качеству каналов связи, стабильности прошивки и, поверх этого, вероятностное поведение моделей. Ошибка в одном слое легко маскируется под проблему в другом: кажется, что виновата модель, а на деле у вас датчик даёт смещённые данные; кажется, что проблема в UART-драйвере, а по факту входной пайплайн некорректно нормализует значения.

В этой статье разберу, как выстраивать тестирование по уровням: от unit-тестов отдельных функций до проверки ML-моделей, интеграции компонентов и тестов прошивки на реальном железе. Без лишней теории — только те подходы, которые действительно работают в реальной разработке.

Почему тестирование нельзя игнорировать

Начнём с простой, но важной вещи: тестирование почти всегда дешевле отладки последствий. Ошибка, найденная в момент написания кода, обычно исправляется быстро — за часы, иногда за десятки минут. Та же ошибка, обнаруженная уже после релиза, может стоить дней или недель. А если речь идёт об устройстве, которое уже уехало в поле, или о модели, встроенной в рабочий процесс, цена проблемы резко растёт: время, нервы, репутация команды, иногда и прямые деньги.

Для embedded-систем и ИИ-проектов это особенно критично:

Embedded-код работает в условиях ограниченных ресурсов. Нехватка памяти, гонки, ошибка в обработке прерывания, некорректный таймаут или переполнение буфера могут привести не просто к багу, а к зависанию устройства или неправильной реакции в критический момент.
ML-модели зависят от данных сильнее, чем обычная прикладная логика. Модель можно «успешно» обучить на плохом датасете, с утечкой признаков или некорректной разметкой — и формально всё будет работать, пока не начнутся ошибки в реальном использовании.
Интеграция код + модель + hardware — это многослойная система. В таких системах особенно опасны ошибки, которые не проявляются напрямую. Например, дрейф входных данных может выглядеть как деградация модели, а рассинхронизация обмена с датчиком — как случайный шум в предсказаниях.

Если упростить: без тестирования вы разрабатываете вслепую. Да, что-то может работать «на глаз», особенно в демо или прототипе. Но как только проект усложняется, ручная проверка перестаёт масштабироваться. В какой-то момент команда начинает не разрабатывать, а постоянно перепроверять одни и те же сценарии после каждого изменения.

Уровни тестирования: от мелкого к крупному

Хорошо организованное тестирование обычно строится по принципу пирамиды: внизу много быстрых и дешёвых тестов, выше — меньше интеграционных, ещё выше — относительно редкие и дорогие end-to-end или hardware-in-the-loop проверки. Это не абстрактная методология, а вполне практичный подход. Чем раньше вы ловите ошибку, тем дешевле её исправлять.

Каждый уровень решает свою задачу. Unit-тесты ловят дефекты в локальной логике. Интеграционные показывают, что модули действительно умеют работать вместе. Функциональные проверяют поведение системы в терминах реальных сценариев. Если пытаться заменить всё только ручным тестированием на финальном этапе, вы получите дорогую и медленную схему, в которой дефекты будут находиться слишком поздно.

Unit-тестирование: проверка отдельных функций

Unit-тест проверяет одну функцию, класс или небольшой модуль в изоляции. Это самый быстрый способ поймать ошибку в логике до того, как она утянет за собой полсистемы. В реальной практике именно unit-тесты дают основной выигрыш по скорости обратной связи: запустили — и сразу увидели, сломалось ли что-то после рефакторинга или изменения алгоритма.

Пример на Python:

def celsius_to_fahrenheit(c):
    return c * 9 / 5 + 32

def test_celsius_to_fahrenheit():
    assert celsius_to_fahrenheit(0) == 32
    assert celsius_to_fahrenheit(100) == 212
    assert celsius_to_fahrenheit(-40) == -40

Почему это работает:

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

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

Где это применяется:

Обработка данных с датчиков.
Преобразование форматов данных.
Математические функции для фильтрации сигналов.
Любая логика, которая не зависит от hardware.

Практический нюанс: если функция трудно тестируется, это часто сигнал о проблеме в архитектуре. Обычно она либо делает слишком много сразу, либо слишком жёстко связана с внешним миром — файловой системой, GPIO, сетью, БД, сериалом. В таких случаях тестирование помогает не только ловить баги, но и улучшать сам дизайн кода.

Интеграционное тестирование: проверка взаимодействия компонентов

Когда отдельные модули поодиночке работают нормально, это ещё не значит, что система ведёт себя корректно в сборке. Большая часть инженерных проблем как раз и возникает на стыке: один компонент возвращает данные в другом формате, другой ожидает иной порядок вызовов, третий не выдерживает задержки или даёт неожиданные исключения.

Пример: датчик → обработка → хранилище

from unittest.mock import Mock

def process_sensor(sensor, storage):
    value = sensor.read()
    processed = value * 1.5
    storage.save(processed)

def test_process_sensor():
    sensor = Mock()
    storage = Mock()
    sensor.read.return_value = 10

    process_sensor(sensor, storage)

    storage.save.assert_called_once_with(15.0)

Здесь мы используем mock-объекты — заменители реальных компонентов. Это полезно, когда не хочется тащить в тест реальное железо, сетевые запросы или базу данных. Такой подход позволяет проверить именно договорённость между частями системы: кто что вызывает, в каком порядке и с какими данными.

В embedded-проектах это особенно удобно для драйверного слоя и бизнес-логики поверх него. Например, можно замокать интерфейс чтения по I2C или SPI и проверить, как модуль реагирует на корректные данные, таймаут, битую контрольную сумму или пустой пакет. В AI-пайплайнах так же удобно тестировать этапы предобработки, сериализации признаков, отправки данных в inference-сервис и сохранения результата.

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

Функциональное тестирование: сценарии использования

Функциональные тесты поднимаются ещё на уровень выше. Их задача — проверить, что система делает то, что от неё ожидается в реальных рабочих сценариях. Здесь нас уже меньше интересует внутренняя структура кода и больше — внешний результат.

Пример для embedded-системы:

def test_device_alarm_trigger():
    device = Device()
    device.set_temperature(85)
    device.run_cycle()
    assert device.alarm_on is True

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

В проектах с ML функциональные тесты могут проверять не только сам факт выдачи предсказания, но и полный маршрут данных: пришёл входной кадр, сработала предобработка, модель отдала результат, логика приняла решение, в интерфейсе или в телеметрии появился ожидаемый эффект. Именно такие тесты дают уверенность, что система полезна не только как набор отдельно работающих модулей, но и как целостное решение.

Тестирование ML-моделей: свой подход

Модели машинного обучения тестируются иначе, чем обычный прикладной код. С классическим кодом всё сравнительно просто: на одних и тех же входах мы ожидаем одни и те же выходы. С ML так не работает. Модель может быть корректно обучена технически, проходить без ошибок весь пайплайн, но при этом давать плохие предсказания, нестабильно вести себя на новых данных или деградировать после выката.

Поэтому в тестировании ML важно смотреть не только на код, но и на данные, метрики, стабильность результатов и поведение на краевых случаях. Если говорить инженерно, тестируется не только реализация, но и статистическая пригодность решения.

Валидация на тестовом наборе данных

Это базовый уровень проверки модели. Данные разделяются на обучающую и тестовую части, после чего модель обучается на одной выборке и оценивается на другой:

from sklearn.model_selection import train_test_split
from sklearn.metrics import accuracy_score

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
model.fit(X_train, y_train)
y_pred = model.predict(X_test)
print("Accuracy:", accuracy_score(y_test, y_pred))

На первый взгляд всё просто, но именно здесь часто закладываются самые дорогие ошибки. Например, случайная утечка информации из test в train, неправильное перемешивание временных рядов, разбиение с нарушением групповой структуры данных, пересечение записей одного и того же объекта в обеих выборках. Формально метрика будет высокой, а в реальной эксплуатации модель начнёт проваливаться.

Что проверять:

Accuracy (общая точность) — процент правильных предсказаний.
Precision — из всех положительных предсказаний, сколько было верных.
Recall — из всех реальных положительных случаев, сколько модель предсказала.
F1-score — гармоническое среднее precision и recall.

На практике выбор метрики зависит от задачи. Если вы ищете дефекты на производстве или аномалии в телеметрии, recall часто важнее accuracy: пропущенный дефект обычно дороже ложной тревоги. Если система запускает дорогую последующую обработку, может быть важнее precision. И именно это обязательно нужно зафиксировать в тестах и критериях приёмки, а не оценивать модель по принципу «ну в среднем вроде нормально».

Кросс-валидация: проверка на разных подмножествах

Когда данных немного, одного test split недостаточно. Случайное разбиение может оказаться слишком удачным или, наоборот, слишком жёстким. В этом случае помогает кросс-валидация:

from sklearn.model_selection import cross_val_score

scores = cross_val_score(model, X, y, cv=5)
print("CV scores:", scores)
print("Mean score:", scores.mean())

Здесь модель обучается и проверяется на нескольких разных разбиениях. Если результаты от фолда к фолду сильно скачут, это обычно признак нестабильности: либо данных мало, либо признаки плохие, либо модель слишком чувствительна к конкретной выборке.

В инженерной практике это полезно ещё и как ранний индикатор того, насколько решение вообще пригодно к эксплуатации. Если модель показывает красивые результаты только на одном конкретном разбиении, это повод насторожиться. Особенно в edge-задачах, где потом придётся запускать inference на ограниченном железе, а значит, запас по качеству обычно и так не слишком большой после квантования, оптимизации и упрощения архитектуры.

Проверка на специальных случаях

Модели почти всегда ломаются не на «средних» данных, а на неудобных. Именно поэтому нужно отдельно проверять специальные и граничные случаи:

def test_model_on_edge_case():
    sample = [[0, 0, 0, 0]]
    prediction = model.predict(sample)
    assert prediction is not None

Разумеется, в реальном проекте такой тест стоит делать содержательнее. Нужно проверять не просто факт возврата значения, а адекватность поведения на редких и потенциально опасных входах: нулевые значения, пропуски, шумные данные, экстремальные диапазоны, нештатные комбинации признаков, повреждённые изображения, неожиданные единицы измерения.

Если модель потом будет работать рядом с реальными датчиками, особенно полезно воспроизводить сценарии, которые инженеры хорошо знают по железу: дребезг сигнала, скачок АЦП, потеря части пакета, насыщение сенсора, рассинхрон времени, плавающее питание, резкое изменение освещения в кадре. Такие тесты часто ценнее абстрактного повышения средней метрики на пару процентов.

Мониторинг дрейфа данных

Даже хорошая модель со временем может начать работать хуже, если изменятся входные данные. Это называется data drift. Для production-систем это не теоретическая проблема, а вполне обычная ситуация: поменялся датчик, изменилась среда, обновилась прошивка устройства, пользователи начали работать иначе, в кадре стало другое освещение, а распределение признаков ушло.

import numpy as np

def detect_drift(train_mean, new_data_mean, threshold=0.1):
    return abs(train_mean - new_data_mean) > threshold

assert detect_drift(0.5, 0.7) is True

Это очень упрощённый пример, но идея верная: поведение данных нужно контролировать. В production полезно отслеживать статистики входных признаков, долю пропусков, диапазоны значений, распределения классов, confidence модели, частоту срабатываний и обратную связь от downstream-систем. Если есть возможность, стоит хранить сэмплы для последующего анализа и переобучения.

На edge-устройствах эта задача сложнее из-за ограничений по памяти, каналу связи и вычислениям. Но даже там можно собирать компактную телеметрию: скользящие средние, гистограммы, min/max, число аномальных входов. Это уже даёт шанс поймать деградацию до того, как она превратится в эксплуатационную проблему.

Тестирование прошивок: от эмуляции к железу

С прошивками ситуация особая: код исполняется не на рабочем ноутбуке разработчика, а на конкретной аппаратной платформе со своими регистрами, таймерами, прерываниями, периферией и ограничениями по ресурсам. Из-за этого тестирование embedded-кода нельзя полностью свести к обычным unit-тестам, но и начинать сразу с проверки на реальной плате — плохая идея. Слишком медленно и слишком дорого по времени.

Рабочий подход обычно такой: сначала максимально возможную часть логики выносим в тестируемые модули, затем прогоняем её на хосте, потом используем эмуляцию или симуляцию там, где это применимо, и только после этого идём на реальное железо. Это заметно ускоряет цикл разработки.

Unit-тесты на компьютере (до загрузки на устройство)

Большую часть логики прошивки можно тестировать на обычном компьютере, если она отделена от аппаратно-зависимого слоя:

// sensor.c
int convert_raw_to_temp(int raw) {
    return (raw * 330) / 1024;
}

Компилируем и запускаем на компьютере:

gcc sensor.c test_sensor.c -o test_sensor
./test_sensor

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

Особенно хорошо так тестируются:

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

Симуляция на эмуляторе

Для более сложных случаев имеет смысл использовать эмуляторы. Например, QEMU позволяет эмулировать ARM-платформы и проверять код без физического устройства:

qemu-system-arm -M stm32-p103 -kernel firmware.elf -nographic

Эмулятор позволяет:

Отлаживать код без реального железа.
Проверять логику инициализации.
Тестировать обработку прерываний.

Конечно, эмуляция не заменяет реальную плату полностью. Некоторые особенности периферии, временные эффекты, нестабильность линии связи, взаимодействие с конкретными датчиками и энергопотребление она не покажет. Но как промежуточный этап это очень полезный инструмент. Особенно когда нужно быстро воспроизвести сценарий в CI, проверить boot sequence, регрессию в стартовой инициализации или поведение после изменений в low-level коде.

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

Интеграционное тестирование на реальном устройстве

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

Когда логика проверена, загружаем на реальный микроконтроллер:

st-flash write firmware.bin 0x8000000

На компьютере читаем данные через UART и проверяем:

import serial

ser = serial.Serial('/dev/ttyUSB0', 115200)
line = ser.readline().decode().strip()
assert "OK" in line

На практике я бы рекомендовал не ограничиваться только проверкой одной строки в UART. Лучше строить минимальные автоматизированные стенды: питание, управление reset, чтение логов, возможность подавать тестовые сигналы или имитировать ответы внешних устройств. Даже простой USB-релейный модуль и несколько скриптов уже позволяют автоматизировать то, что иначе проверялось бы вручную часами.

Если в системе есть ML-компонент на edge-устройстве — например, Raspberry Pi, Jetson Nano или иной Linux SBC, — тестирование на реальном железе становится ещё важнее. На десктопе модель может работать идеально, но на устройстве всплывут проблемы с латентностью, нехваткой RAM, конфликтами версий библиотек, форматами входных данных и тепловым троттлингом при длительной нагрузке. Это тоже нужно проверять отдельными интеграционными тестами.

Практический workflow: как организовать тестирование

Теперь к самому полезному — как собрать всё это в рабочий процесс, который не разваливается через неделю. Главная цель здесь не в том, чтобы написать как можно больше тестов, а в том, чтобы сделать проверку кода и системы регулярной, дешёвой и предсказуемой. Если тесты запускаются редко или требуют слишком много ручных действий, команда быстро перестаёт на них опираться.

Ниже — схема, которая хорошо работает и в софтверных проектах, и в разработке на стыке embedded и AI.

Шаг 1: Напишите тесты ДО кода (TDD)

Начните с тестов, которые формализуют ожидаемое поведение функции:

def test_sum():
    assert sum_values(2, 3) == 5

Потом пишется сама реализация. Подход TDD не обязателен буквально для каждого фрагмента кода, но как инженерный инструмент он очень полезен. Он заставляет сначала ответить на вопрос: что именно должна делать функция, каковы её границы, какие входы допустимы, что считать ошибкой. В результате код получается более предсказуемым, а API — более аккуратным.

Особенно хорошо это работает на новых модулях, библиотеках, парсерах, алгоритмах обработки данных и слоях бизнес-логики. Для embedded это также помогает заранее отделять чистую логику от аппаратной специфики. А в ML-проектах TDD полезен для проверки пайплайна обработки данных, валидации входов и формата выходов модели.

Шаг 2: Запускайте тесты после каждого изменения

Тесты дают эффект только тогда, когда запускаются регулярно. Идеально — после каждого заметного изменения в коде. Чтобы не надеяться на дисциплину вручную, стоит автоматизировать это через Git hooks:

#!/bin/sh
pytest || exit 1

Такой pre-commit hook не даст зафиксировать изменение, если базовый набор тестов падает. Это особенно полезно в проектах, где много мелких правок в обработке данных, API-клиентах, скриптах подготовки датасетов или низкоуровневых модулях. Один неаккуратный рефакторинг — и уже сломан импорт, изменён формат структуры, потерян байт в протоколе или сместился тип значения.

Правда, есть важный нюанс: в hook лучше ставить только быстрые тесты. Если вы попытаетесь запускать там тяжёлую интеграцию, сборку прошивки и полную проверку модели, разработчики начнут искать способы это обойти. Быстрый контур должен оставаться быстрым.

Шаг 3: Используйте CI/CD

Локальные тесты — это хорошо, но недостаточно. Нужен независимый контур, который проверяет изменения в одинаковой среде для всех разработчиков. Для этого и используется CI/CD: GitHub Actions, GitLab CI, Jenkins и другие системы.

name: Python tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
      - run: pip install -r requirements.txt
      - run: pytest

CI особенно важен в смешанных проектах, где часть команды пишет на Python, часть на C/C++, а итоговая система ещё и собирается под отдельную платформу. В таком пайплайне удобно разделять этапы: линтеры, unit-тесты, интеграционные тесты, сборка артефактов, проверка покрытия, возможно — запуск эмулятора или тестов на выделенном стенде.

Если есть возможность, полезно добавить отдельные джобы для прошивок, ML-пайплайнов и тестов API. Тогда регрессия будет ловиться ближе к месту возникновения, а не в виде абстрактного «что-то упало в системе».

Шаг 4: Отслеживайте покрытие кода

Покрытие показывает, какая часть кода действительно выполнялась во время тестов:

coverage run -m pytest
coverage report

Целевое покрытие для критичного кода — 80–90%. Для embedded и ML-кода я тоже ориентируюсь на уровень около 85% и выше, но с одной важной оговоркой: само по себе число покрытия ничего не гарантирует. Можно формально покрыть код и всё равно не проверить ничего важного.

Поэтому смотреть стоит не только на процент, но и на смысл. Хорошие тесты покрывают ветвления, ошибки, пограничные случаи, аварийные сценарии и реальное поведение на значимых входах. В embedded особенно важно, чтобы тестировались обработка таймаутов, невалидных пакетов, переполнений, пограничных диапазонов АЦП и логика состояний. В ML — валидация формата данных, стабильность предобработки, контроль отсутствия data leakage и воспроизводимость инференса.

Инструменты для тестирования

Язык	Unit-тесты	Интеграционные тесты	Покрытие
Python	pytest, unittest	pytest-docker	coverage
C/C++	Google Test, Catch2	CMake + CTest	gcov
JavaScript	Jest, Mocha	Cypress, Playwright	Istanbul
Embedded (C)	Unity, CMocka	QEMU + скрипты	gcov

Мой выбор:

Python: pytest + coverage (просто и мощно).
C: Google Test для unit-тестов, QEMU для интеграции.
ML: pytest + scikit-learn metrics.

Если чуть расширить этот список практическими замечаниями, то для Python я почти всегда предпочитаю pytest из-за удобных фикстур, параметризации и хорошей экосистемы. Для C/C++ многое зависит от сборочной системы, но связка CMake + CTest + Google Test обычно даёт достаточно предсказуемый результат. В embedded-проектах полезны Unity и CMocka, когда нужен лёгкий тестовый контур без тяжёлой инфраструктуры.

Для ML, кроме обычных тестов, часто стоит держать отдельные проверки на качество данных, reproducibility и консистентность модели после сериализации. Отдельно полезны smoke-тесты на загрузку модели, прохождение одного inference-запроса и проверку размеров/типов входов. Это спасает от очень приземлённых, но регулярных проблем: несовпадение версий библиотек, битый артефакт модели, изменение схемы признаков, другой порядок колонок.

Часто встречающиеся ошибки в тестировании

Ошибки в тестировании обычно не менее опасны, чем ошибки в коде. Тесты могут создавать ложное чувство уверенности: вроде бы всё зелёное, а на практике система не проверяет действительно важные сценарии. Ниже — самые частые проблемы, которые я вижу в инженерных проектах.

Ошибка 1: Тесты не покрывают реальные сценарии

Плохо:

def test_temperature():
    assert convert_raw_to_temp(100) == 32

Хорошо:

def test_temperature_bounds():
    assert convert_raw_to_temp(0) == 0
    assert convert_raw_to_temp(1023) <= 330
    assert convert_raw_to_temp(-1) >= 0

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

Если функция работает с измерениями, полезно прогнать минимумы и максимумы. Если это парсер протокола — проверить битые пакеты и частично обрезанные данные. Если это ML-предобработка — подать пропуски, NaN, неожиданные категории, пустые массивы. Настоящая устойчивость проверяется именно на неудобных случаях.

Ошибка 2: Тесты зависят друг от друга

Плохо:

global_state = []

def test_add():
    global_state.append(1)
    assert len(global_state) == 1

def test_remove():
    global_state.pop()
    assert len(global_state) == 0

Хорошо:

def test_add():
    state = []
    state.append(1)
    assert len(state) == 1

def test_remove():
    state = [1]
    state.pop()
    assert len(state) == 0

Зависимые тесты особенно коварны тем, что могут случайно проходить в одном порядке и падать в другом. Это одна из причин «плавающих» CI-падений, которые потом все ненавидят. Каждый тест должен быть самодостаточным: сам подготовил вход, сам проверил результат, сам завершился без побочных эффектов.

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

Ошибка 3: Тесты медленные и редко запускаются

Медленные тесты — почти всегда неиспользуемые тесты. Если прогон занимает слишком много времени, разработчики начинают откладывать его «на потом», а значит, обратная связь теряется именно тогда, когда она нужна больше всего. Поэтому тесты нужно разделять по скорости и стоимости запуска:

pytest -m "not slow"
pytest -m slow

Запуск:

pytest -m "not slow"   # быстро, на каждый commit
pytest -m slow         # реже, например в CI ночью

Это хорошая практика и для обычного бэкенда, и для embedded, и для ML. Быстрый контур — локально и на каждый push. Медленный — по расписанию, перед релизом или на выделенной ветке. Для hardware-тестов это особенно актуально: не стоит блокировать разработку ожиданием длительного прогона на стенде, если можно раньше отсеять большую часть ошибок дешёвыми проверками.

FAQ

Вопрос: Сколько тестов нужно писать?

Ответ: Столько, чтобы вы действительно контролировали риск. Для критичного кода — особенно в embedded и ML — ориентир 80–90% покрытия вполне разумен. Для прототипов можно меньше, но ноль почти всегда превращается в технический долг уже через несколько итераций. Если код влияет на безопасность, деньги, реальные устройства или качество решений модели, экономить на тестах обычно выходит дороже.

Вопрос: TDD (тесты до кода) — это нужно?

Ответ: Для новых функций — да, часто это реально экономит время. Не потому, что это «правильная методология», а потому что помогает сразу формализовать требования и избежать расползания логики. Для рефакторинга существующего кода подход тоже полезен: сначала фиксируете текущее поведение тестами, потом меняете реализацию. Иначе очень легко сломать что-то, что казалось второстепенной деталью, а на деле было частью контракта.

Вопрос: Как тестировать асинхронный код и прерывания?

Ответ: Используйте mock-объекты и контролируемую симуляцию событий. Для async Python — pytest-asyncio. Для embedded — эмуляторы вроде QEMU, фейковые источники прерываний и тестовые обвязки вокруг ISR-зависимой логики. Хорошая практика — выносить максимум обработки из самого обработчика прерывания в отдельные функции, которые можно тестировать детерминированно.

Вопрос: Нужны ли тесты для ML-моделей, если я использую готовые библиотеки?

Ответ: Да. Библиотека может быть надёжной, но ваша задача — проверить собственный пайплайн и применимость модели к данным. Тесты должны подтверждать:

Что модель обучилась (loss уменьшается).
Что предсказания на тестовом наборе находятся в ожидаемом диапазоне.
Что модель корректно обрабатывает граничные случаи.
Что между train и test нет data leakage.

И я бы добавил ещё два практических пункта: проверку стабильности предобработки и проверку совместимости сериализованной модели с production-средой. Очень частая проблема не в самой модели, а в том, что в рантайме используется другой препроцессинг, другая схема признаков или другая версия зависимостей.

Вопрос: Как быть с legacy-кодом без тестов?

Ответ: Не пытайтесь покрыть всё сразу. Это почти всегда заканчивается ничем. Начните с критичных функций и участков, которые вы собираетесь менять. Сначала зафиксируйте текущее поведение regression-тестами, даже если код внутри вам не нравится. Затем постепенно расширяйте покрытие. Для старых embedded-проектов это особенно разумно: сначала тестируются протоколы, преобразование данных, расчётные модули и всё, что можно вынести из аппаратно-зависимого слоя. Потом уже остальное.

Заключение

Тестирование — это не трата времени и не бюрократия ради красивого CI-значка. Это инвестиция в предсказуемость разработки. В embedded-проектах ошибка может привести к сбою устройства, а в ML-системах — к неправильным решениям на реальных данных. В проектах, где встречаются и прошивки, и Python-сервисы, и модели, цена неконтролируемой регрессии ещё выше.

Unit-тесты, интеграционные проверки, валидация моделей, тесты на эмуляторе и испытания на реальном железе — это не конкурирующие подходы, а слои защиты. Вместе они сильно снижают вероятность того, что баг дойдёт до пользователя, заказчика или production-стенда. А ещё они экономят время команды: вместо бесконечной ручной перепроверки появляется воспроизводимый процесс.

Начать можно с малого: написать несколько unit-тестов для критичной функции, включить их в CI/CD, посмотреть покрытие, добавить пару интеграционных сценариев. Потом постепенно расширять контур. Обычно уже через несколько недель становится заметно, насколько спокойнее и быстрее идёт разработка, когда базовые проверки автоматизированы.

Главная мысль простая: код без тестов — это не завершённая работа, а источник неопределённости. А в инженерной разработке неопределённость почти всегда обходится слишком дорого.