Comments 5
А на сколько это вообще применимо, если для микроконтроллера в реальности может использоваться один компилятор со своей оптимизацией, а для юнит теста другой? И даже если вы компилите одни и те же файлы, есть риск получить разный результат на выходе.
Может просто сам уже слишком закостенел, но сколько статей не читал, так и не увидел полезности в юнитах для встроки
я всегда использую одно и тоже окружение для рабочего и тестового проекта, как в проектах на Windows(VisualGDB) так и в проектах на Linux(gcc/clang + cpputest), в редких случаях могу понизить опции оптимизации.
Полезность в юнит-тестах точно есть, попробуйте :), еще пару побочных причин могу привести:
тестами можно показать как пользоваться каким-либо методом, вместо документации. (помня о том что и в будущем этот тест будет приносить пользу как юнит-тест)
более безопасный и быстрый рефакторинг кода.
А на сколько это вообще применимо, если для микроконтроллера в реальности может использоваться один компилятор со своей оптимизацией, а для юнит теста другой? И даже если вы компилите одни и те же файлы, есть риск получить разный результат на выходе.
IMHO, результат исполнения одного и того же кода написанного на языке высокого уровня должен быть один и тот же, вне зависимости от уровня оптимизации, версии компилятора и прочее. Иначе или код содержит "неопределённое поведение" (UB) или есть проблемы в компиляторе, что менее вероятно, чем первое. Задача программиста писать код без UB и кроссплатформенные unit test'ы помогают в этом.
Пример полезности unit test'ов из моей практики. Пишу код для обмена сообщениями с "железкой" через UART. В данный момент времени у меня нет в наличии этой "железки". Код разделён на две части - протокол сообщений и собственно связь через UART. Код протокола написан, обвязан unit test'ами и протестирован на desktop компьютере с бытрой компиляцией и удобным отладчиком. И я могу быть с высокой доли уверенности сказать, что этот код заработает на целевом железе и останется оттестировать только UART код.
Плюсы:
1. есть ускорение времени разработки как из за быстрой компиляции на desktop компьютере, отсутствия загрузки скомпилированного кода в целевой микропроцессор, удобного отладчика, так из-за того, что не нужно ждать когда появится "железка";
2. Нет "боязни" изменения кода и изменения версии компилятора.
наличие такого слоя абстракции "железа" очень облегчает разработку.
Вы "обернули" всё "железо", весь код может работать на хосте? Или только выборочные модули?
Второе ближе к реальности. Код реализующий протокол обмена "знает" только об абстрактном интерфейсе связи, один из методов которого send_buffer. Реализация интерфейса для кода протокола не важна. Код реализующий интерфейс может быть работать с uart, или другим физическим интерфейсом, а так же быть частью unit test'а.
Упрощение отладки с помощью unit-тестов