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

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

Если вы не представляете, что должно быть на выходе конкретного метода при подаче на вход конкретных значений — как вы можете быть уверены, что ваш код делает то, что должен?
Понятно, если есть 1 огромная функция, КОТОРАЯ ДЕЛАЕТ ВСЕ — тут да, тяжеловато.
Но суть-то как раз и в том, чтоб не писать сперва такой код и потом думать, как же его проверить-то
Суть в том, что сперва написать тест для проверки конкретной небольшой части кода, читай — написать правила, по которым должна работать эта конкретная часть кода. Потом — реализовать ее именно в том виде, в каком она придумана для теста. Потом убедиться, что она работает именно так, как придумано. И все.

WH>Таким образом максимум что я могу себе позволить это после того как код написан сделать несколько дампов для того чтобы засекать изменения в работе системы.

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

WH>А бывают случаи когда даже дамп не сделать...

Бывают
Но компиляете-то вы исходники у себя на машине, так ведь?
По сути, тесты — это некая инкарнация компилятора. Компилятор вам говорит, что новонаписанный код нарушает синтаксис, тесты — где нарушена описанная в них логика.