Ну вреда от юнит тестов нету никакого

Это смотря с какой стороны посмотреть. С одной стороны - маслом кашу не испортишь. А с другой, от килограмма масла может и поплохеть.

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

Насколько я понял, у вас есть

Видимо плохо пояснил. Речь шла о совершенно разных проектах в совершенно разных фирмах, в разных временных интервалах.

И почему-то называете это все юнит-тестом

Сорри, как то незаметно смешалось. Делалось и то и другое.

За обеспечение работы по передаче данных отвечают модули "посылает в COM порт" и "принимаются данные из COM порта".

У нас концепция немного разная. За обеспечение работы по передаче данных отвечает "модуль обмена" и в первом случае это мог быть и СОМ порт и "синий зуб" и фиг знает что.

В другом варианте все тоже самое.

В том то и дело что нет. Для первого случая нужен был пулемет в доте, для второго достаточно и пистолета в руке.

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

мы просто возьем уже оттестированные модули

Для начала, этих модулей просто физически нет, другое место и время.

Кроме того, нам нужен модуль "весов АБС", в котором обмен занимает несколько строк и асинхронный обмен просто противопоказан.

нам будет начхать от куда взялись данные из COM порта

Это в общем случае так. А вот когда все конкретное, то ситуация меняется.

Вот на фирме все работало, а у заказчика ну никак.

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

А как быть если интерфейсов/классов многие десятки и зачастую не знаешь заранее сколько и каких там будет функций. А есть ООП TDD?

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