Здравствуйте, Ceceron, Вы писали:

C>Hi All!
.............
C>Кто что думает?

— насчет "перекроить архитектуру, что бы можно было потестить"

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

— "тестировать только через интерфейс ( через паблик методы )"
+1

— нужны ли юнит тесты для приватных классов

если очень нужно, то можно использовать некий компромис —
у сборки прописать атрибут

  [assembly: InternalsVisibleTo( "MyAsmUnit" )]    //   у MyAsm.dll

и тогда эта конкретная сборка будет видеть внутренние типы
( в MyAsmUnit.dll будут доступны internal типы MyAsm.dll )

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

можно конечно вообще включить юнит тесты в саму сборку, но имхо это неправильно.

— использовать рефлекшн для тестов — а нафига?