ага и после каждого изменения я буду запускать все тесты.

Конечно! А как может быть иначе? :) Я перед каждым коммитом запускаю все тесты локально. Благо, что юнит-тесты исполняются очень быстро :)

для этого вообще не нужно менять тесты, они изменятся автоматом

Ну это совсем не обязательно.

"то на это должны быть веские основания" почему? Было например "Anzahl" стало "Count", либо просто буква не та.

Потому что в случае, если ты уже выпустил интерфейс, то изменение сигнаруры ведет к потере обратной совместимости. Не знаю как у тебя на работе, а я уже очень много раз сталкивался с тем, что начальство хотело выкатить фикс, но при этом не хотело устанавливать новую версию. И тогда надо было заменить 1-2 dll'ки простым copy-paste.

Я уж не говорю о случаях, когда одна и тебя библиотека используется несколькими продуктами - это еще более распростаненный use-case.

Это парадигма давно в мусоре у нас валяется. Есть модуль и есть список сообщений.

Зря она у вас в мусорке :) Эта парадигма позволяет использовать модули как блэк боксы и комбинировать их по необходимости. Например заменять один модуль (связь с реальным COM портом) другим (например сгенерированным NSubstitute'ом).

Это уже интересно, а как проверить, что будет делать наш декодер если ему придет дата 29 февраля в любой год например?

А в чем проблема? Делаешь 2 теста:

1) создаешь экземпляр декодера и пишешь в него 29 февраля 2020г. Получаешь ответ и проверяешь правильность ответа.

2) создаешь экземпляр декодера и пишешь в него 29 февраля 2018г. Получаешь ответ и проверяешь правильность ответа.

Все.

ссылочку тогда мона? Чтобы и наследование заранее сделать и все прочее что там для объектов нужно.

Не понял, ссылочку на что?

Но до этого мы уже написали пару десятков тестов, что с ними делать?

Изменение в требованиях - это достаточно веская причина для того, чтобы изменить тесты.