Rock AmadeusЯ, может, что-то не то делаю, но когда надо весь проект в сборе под дебагом смотреть, то там все проекты должны быть включены, чтобы не было проблем с переходом к нужному коду. Со всякими символьными сборками у меня чего-то не заладилось. Есть ситуации, когда их либо нет, либо они не работают. Я не стал разбираться, а заметил, что если проекты все включены в солюшен, то проблем не возникает и под дебагом к коду другого проекта нормально переходит. А раньше тоже пытался по одному-три проекта в солюшене держать, не больше.

Терпеть :) Или переходить на юнит-тесты. Мы вообще режим дебага не поощряем в разработке. Только тормозит процесс разработки и усложняет. Хватает юнит-тестов для испытаний.

Rock AmadeusС юнит-тестами такая запарка, что на хорошие тесты надо времени потратить чуть ли не больше, чем на написание самого кода. Ну и объём их тоже, как правило, больше самого кода. У меня требования и сами алгоритмы в моих задачах постоянно меняются (т. к. идёт постоянная доработка алгоритмов и подходов, то фактически это перманентное прототипирование). Я только буквально для нескольких самых базовых и устойчивых частей несколько тестов написал и всё.

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

Хороший юнит-тест = маленький юнит-тест. Тестируются каждый класс изолированно. Тестируется только то, что делает класс, и ничего кроме этого. Большие тесты это интеграционные тесты и делаются они иначе, чем юнит-тесты, там не надо ничего мокать, надо использовать реальную инфраструктуру и смотреть результаты работы. Так что интеграционные тесты тоже не должны быть жирными.


Rock AmadeusЮнит-тесты, как я понял, это в основном для задач с устойчивым ТЗ, а не когда каждую неделю-две меняют-дорабатывают.

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

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

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

Rock Amadeusявляется каким-то замкнутым кругом - без опыта (т. е. сразу делать ПО с хорошей декомпозицией и архитектурой) лучше в юнит-тесты не соваться, а если не знаешь юнит-тесты, то и опыта для нормальной декомпозиции и архитектуры не имеешь. Да ещё такой архитектуры, которая будет устойчива при существенных изменениях ТЗ. Но, в целом, я согласен - что лучше пытаться и чего-нибудь получится, чем сидеть и ничего не делать - тогда точно будешь до конца жизни говнокодить.

Никакого замкнутого круга, просто движение :)
Печально, что абсолютно подавляющее большинство выбирают путь говнокода и безысходности. Да, для профессионального роста надо прилагать усилия. Но многие находят миллион причин и отговорок, чтобы не заниматься развитием.