а что писать проще

Что проще есть — грецкие орехи или селёдку?

Код по тз.

Писать юниттесты для существующего кода - неблагодарная задача. Часто в таких случаях код нетестабельный.

юнит тесты по уже написанному коду?

Часто это делать просто нереально, так как код не писался под тесты.

Грецкие орехи, конечно же

код по ТЗ писать ЗНАЧИТЕЛЬНО проще

Ты бы ещё написал - что мягче, круглое или зелёное?

Одно другое не исключает.

Идеально, когда есть ТЗ и есть тесты, которые соответсвуют написанному коду по ТЗ.

ТЗ конечно пишется перед тестами однозначно.

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

Но по логике эффективнее всё же писать вначале рабочий код, а потом уже тестовый код.

юнит тесты по уже написанному коду?

код - это лишь проекция решения задачи. Т.е. часть информации о задаче в коде явно будет отсуствовать.

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

подгонять тесты под уже готовые реалиии - плохая затея

Вначале нужно ТЗ, в нем и написано, что должен делать код.

Не понял, а чем код отличается от описания задачи или всяких блок-схем? Вообще судя по твоему посту тесты надо писать по ТЗ, а не по коду, так?

Как бы да, но лучше вначале писать код, потому как демо версию бытрее можно показать, а тесты можно но после кода.

Но ТЗ вначале однозначо. ТЗ это не код и не тесты, а тот функционал за который по идее должен платить заказчик. Но я точно знаю, что в 99% заказчик хитрит и хочет, чтобы ему сделали больше чем он придумал при эфимерном описывании заказа потому как обычно заказчик нихрена не понимает и перебрасывает ответсвенность на исполнителя заплатив за идею что все просто должго быть зашибись. Ну например должен быть просто обычный блог. А потом когда ему показывают сделанную работу, он показывает десятки хреней с других сайтов притом не блогов... и вот я ожидал этого, а вы херню сделали. Потому всегда нужно либо четкое ТЗ, либо гибкая оплата и заказчик понимает что он не может придумать ТЗ.

Не, ТЗ как регулятор процесса и хотелок заказчика это мне понятно, меня больше техническая сторона интересовала. Но я тебя понял, спасибо!

0техническая сторона более сложная конечно, но ТЗ в любом случае должно присутствоват.

Второй этап - разработка архитектуры оптимальной для ТЗ. Это уже более приближенная к технической части. Так сказать вторая итерация ТЗ. Это опять же в 99% отечественных компаний не понимают. Потому нет у нас ни компов, ни операционок, ни фотиков, ни видеокамер... нихера нет. Потому что на всех этапах хотят «кинуть» перебросив ответсвенность на следующий этап разработки.

Не если уж в твоей безобразной форме, то лучше так: как оно - множество или музыка?

Гуглите: Behavior Driven Development