Пожалуй стоит открыть новую тему "вред и польза от юнит тестов"

Ну вреда от юнит тестов нету никакого :D Так что ветку можно не открывать ;)

Вот был проект, довольно долгий. Там данные от устройства передавались по СОМ порту и декодировались. Это была одна из важных функций. Были отдельные тесты для "декодера" и была сделана система для генерации потока данных через СОМ порт, был даже человек который какое то время только и писал сценарии тестирования. Но это было необходимо, так как различных устройств было довольно много, партии устройств были довольно крупные и устройства не могли запросто выдавать неверные данные типа "30 февраля". Реализация всей системы заняла несколько недель, не считая кучи сценариев и того что через какое то время пришлось все сценарии перекраивать, так как в устройствах что то изменилось.

Теперь допустим есть другой проект, только для одного заказчика который выполняет какую то важную работу и как бы между прочим получает данные о весе через СОМ порт (которые впрочем можно ввести и вручную). Будем ли мы городить все тоже самое для этого проекта?

Я, честно говоря, не совсем понял твой пример :D

Насколько я понял, у вас есть генератор сообщений, есть COM порт и есть декодер, вы все это собираете и тестируете. И почему-то называете это все юнит-тестом :D Это не юнит-тест, это интеграционный тест. Юнит-тестом тестироался бы только декодер и никаких потоков данных через COM порт. Да и вообще никаких портов и привязок к железу или к другим компонентам. Тестируя декодер мы исходим из того, что все остальные компоненты работают правильно и не нуждаются в тестировании.

Например, у нас есть такой процесс:

ПО снимает данные с датчиков -> обрабатывает эти данные -> посылает в COM порт -> принимаются данные из COM порта -> декодируются.

Очевидно, что тут минимум 5 юнитов, каждый из которых должен быть протестирован независимо от других. Так наприме, декодер не должен уметь справляться с ситуацией, когда прервалось соединение COM порта. За обеспечение работы по передаче данных отвечают модули "посылает в COM порт" и "принимаются данные из COM порта".

В другом варианте все тоже самое. COM порт не при чем. От слова совсем.

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

зачем?

У TDD есть один большой плюс - заставляет продумать удобство используемого интерфейся до того, как начинаешь писать функционал.

и почему не допустим BDD?

BDD подходит для описания системных или интеграционных тестов. Описание всех тест-сценарием на BDD займет слишком много времени, да и сопровождать такие тесты гораздо сложнее. ИМХО. Если у тебя другой опыт - это ж только плюс :D

Каким образом из положения бумажек видно "почему"?

Каждое утро команда собирает у доски и каждый из членов команды отвечает на 3 вопроса: 1) что было сделано вчера? (передвигая бумажку) 2) какие возникли друдности? (увеличивая время на задачу) и 3) что планируется делать сегодня? (передвигая бумажку)

Таким образом сразу становится понятно, почему какая-то задача занимает больше времени.