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

_>Если вы не представляете, что должно быть на выходе конкретного метода при подаче на вход конкретных значений — как вы можете быть уверены, что ваш код делает то, что должен?
Наверное мы работаем на разных уровнях.
Лично мне никто и никогда не ставит задание:
Написать класс байда с методами инь, янь, хрень. Каждый из которых должен делать то-то и то-то.

Мне ставят задачи както так:
Придумать объектную систему в которой объект владелец может добавлять свойства тем объектам которыми он владеет (как придумай сам).
Все это должно описыватчся декларотивно (как придумай сам)
система должна сама сериализовать эту объектную систему (как придумай сам) в формат (придумай сам)
...
И главное все это должно быть расшаряемо.

Ну и к чему тут можно написать тесты? Мне особенно интересно как протестировать расшаряемость.

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

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