Средства и методы разработки

Выскажу своё мнение, без вообще каких-либо претензий на грамотность/профессионализм. Я тоже любитель TDD, но... не профессионал. 

Но! Это просто кладезь (без)полезной информации.

Всё свалено в одну кучу (я про архив). Я кое-что из того что там есть читал, и подход "вот вам все мои источники информации" сильно неудобен. Например, TDD на C++ (Джефф Лангр) и TDD на C (Джеймс Грининг) это кардинально разные вещи.

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

У автора, видимо, имеется куча времени и удобная работа, которая позволяет заниматься тем чем ему интересно. Мне кажется, большинство программистов встраиваемых систем управления делают максимальные деньги за минимально возможный срок; практика российских КБ ещё не сложилась таким образом, что на первом месте стоит качество кода (судя по разным КБ в Екатеринбурге).

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

ПМСМ, сейчас тестированию уделяется больше времени чем нужно; лучше бы уделяли времени на разработку архитектур, учили разбивать код на малосвязанные программные модули, применять паттерны проектирования, давали фундаментальные знания насчёт работы линкера. Это всё также имеется в том архиве (ключевые слова: "чистый код", "чистая архитектура"). Меняется причина и следствие: применим TDD (или модульное тестирование), и в результате научимся писать чистый код, а должно быть наоборот: мы умеем писать чистый код (и понимаем, зачем это надо), и поэтому можем мизинцем левой ноги с полпинка настроить TDD.

Видео ещё не смотрел, нет времени, так что потом могу изменить свой комментарий.

Ну и вдогонку.

Как правило, я свои проекты строю так, что есть аппаратно-зависимая часть и бизнес-логика. Писать модульные тесты для аппаратно-зависимой части совершенно неразумно, проще отладить на макетке с осциллографом и пошаговой отладкой, и это делается один раз. А бизнес-логика легко тестируется на хост-ПК, это стандартный классический C/C++ с вызовом низлежащих аппаратно-зависимых функций через API (которые подменяются "обманками" при тестировании). Поэтому подход "мы сделаем код-спагетти и монолитное ПО, а потом будем его модульно тестировать в железе используя отладчик" у меня вызывает отторжение (в данном случае тестируется не модуль ПО, а система ПО).

Если речь идёт не о модульном тестировании, а о интеграционном или функциональном, то это другое дело. Обычно объект представляется "чёрным ящиком с внешним интерфейсом", и проверяется правильность поведения (ответ) при контролируемом внешнем изменении, на рабочей прошивке.

Нужно и модульное тестирование, и интеграционное, и функциональное, об этом также статьи есть. Сильный перегиб в какую-либо сторону не будет полезным.