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

L>>А код и должен сводить эти ситуации к простым.
__>всегда ли это возможно... вот в чем вопрос

Ээээ, всегда.

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

L>>Доказать? Гхм, я этот код написал, я знаю, какие сценарии мне нужно покрыть.

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

Ничего никто чесать не будет. Сценарии покрыты на 100% — значит проблема в другом месте. Разматываем клубок, находим виновника.
В этом-то и соль юнит-тестов — отдаешь код джуну, он что-то меняет, что ломает юнит-тест в другом модуле. Обнаруживается это сразу и исправляется тоже сразу.

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

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

Не надо никакого пошагового выполнения.

__>>>ну и сколько затрат времени и сил уходит на то, чтобы просчитать эти сценарии
L>>Нисколько, это происходит автоматически.
__>это неправда. создание тестов — алгоритмически неразрешимая задача.

Еще раз напомню — с вопросами веры в другой форум.
Тестирование юнитов — это общепринятая инженерная методология, которая в разработке ПО почему-то до сих пор применяется со скрипом.