Комментарии 14
В этом случае можно воспользоваться отладкой. Обычно в больших проектах времени на реализацию драйверов уходит меньше, чем на написание бизнес логики. Если у вас проект заключается в настройке периферии МК, то применение TDD не имеет смысла.
TDD предназначен в первую очередь для разработки той части программы, которая от платформы не зависит (а выделить эту часть из программы — достаточно сложный навык, которому надо учиться) — то есть к пересылке данных через DMA он отношения вообще не имеет. Вы-же фактически утверждаете что пинцетом неудобно гвозди забивать, а значит пинцеты бесполезные.
В данной статье нет привязки к компьютерным интерфейсам. В ней был описан способ устранения зависимостей от любой периферии микроконтроллера на примере UART и флеш памяти. Тестирование логики без зависимостей производится на компьютере без какой-либо связи с устройством.
Через симулятор, например. Если Вам интересна тема, советую книгу James Grenning, "Test Driven Development for Embedded C"
Чем больше читаю про TDD для МК, тем больше мне нравятся формальные спецификации, например TLA+ для них же. В любом случае нам надо описывать поведение и представлять краевые случаи, но в TLA+ "покрытие" больше.
TLA проверяет спецификацию, а не код, что тоже полезно, но корректная спецификация ещё не гарантирует корректной реализации — для этого нужны либо тесты, либо средства, позволяющие генерить код прямо из спеки.
Тесты-то мы тоже по спеке пишем (ну или расширяем спеку тестами, как удобнее понимать), так что корректная спека нужна. Про генерацию всё довольно грустно: или берём Indris/Cog, или пишем спеку на Abstract Automata, а потом генерируем через PlantUML, которая их более-менее поддерживает. Оба способа я не пробовал, только вскользь читал, что так можно.
Тема TDD актуальна и для МК, но проблем такой подход (прогон тестов на ПК а не на целевом МК) иногда добавляет.
Например: Написали заглушку для записи во флеш, откатали бизнес логику на ПК (допустим пусть это будет какой нибудь хитрый протокол для обновления прошивки МК), залили код на целевую железку — погоняли на столе в режиме точка-точка — все работает. Привезли прибор на объект — воткнули в стойку с оборудованием — «все сломалось», почему? А вот оказывается что именно это семейство МК 4 байта пишет во флеш за 1 мкс, 16 байт за 2 мкс, а при попытке записать блок из 256 байт повисает аж на 1-5 миллисекунд (время — чистый рандом). За это время срабатывает вотчдог и портит всю оттестированную картину. Производитель МК говорит что такое видит первый раз, но добавит в эррата щит этот баг.
Или еще вариант — пишем TCP клиента на всем любимой связке LwIP + FreeRTOS, используем Socket вариант (то есть рассчитываем что все как в linux).
Отлаживаем на ПК логику — код работает, работа с сокетами почти не отличается.
Начинаем тестить в железе — сначала работает — потом падает.
Причем день работает, два работает, неделю и падает.
А бывает и пол дня не работает.
Оказалось — сделали heapsize 16 мегабайт, тестили с heapsize 16 мегабайт, а рамку в плату запаяли на 4 мегабайта.
А TDD что, все тесты passed…
Никоим образом никого не хочу обидеть, просто накипело.
Хоть отдельную статью про вылезшие баги пиши.
Спасибо за вашу работу по просвещению дремучих ширнармасс. Видимо, до осознания некоторых вещей надо дорасти. Вот я, на 3-м десятке лет работы в индустрии, повидал всякого и практически дорос. А благодаря таким статьям начал что-то понимать и даже запустил в кейле первый тест )
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей