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

__>ну, то есть, у меня вырисовывается картина, что тесты могут избавить от дебагинга в случае, когда

__>- покрывают код настолько плотно, что юниты получаются очень простыми, а поэтому могут быть проанализированы на предмент ошибки и без дебагинга

Совершенно верно.

__>- тесты настолько специфичные, что по срабатыванию сразу можно сказать, где кроется ошибка в юните

Совершенно верно.

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

С вопросами веры в другой форум. Код обязан быть простым вне зависимости от сложности системы. Сложный для понимания и тестирования код даже специальное название имеет. Говнокод.

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

__>да и перерасход мысли программиста на создание тестов (а в примере с транспонированием матрицы ваши тесты во много раз по объему и затратам на придумывание превосходят саму реализацию транспонирования) не факт, что окупится.

А вот это уже пример так называемого вранья.

Есть такое правило — If it worth doing, it worth testing. If it not worth testing, why bother doing it in the first place?

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