LINUX.ORG.RU

Код по тз.

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

holuiitipun ()

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

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

i-rinat ★★★★★ ()

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

stevejobs ★★★★☆ ()

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

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

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

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

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

Serg_HIS ()

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

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

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

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

n_play ()
Ответ на: комментарий от n_play

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

Serg_HIS ()
Ответ на: комментарий от n_play

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

alozovskoy ★★★★★ ()
Ответ на: комментарий от alozovskoy

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

Serg_HIS ()
Ответ на: комментарий от alozovskoy

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

Serg_HIS ()
Ответ на: комментарий от Serg_HIS

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

alozovskoy ★★★★★ ()
Ответ на: комментарий от alozovskoy

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

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

Serg_HIS ()
Ответ на: комментарий от Stahl

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

Serg_HIS ()

Гуглите: Behavior Driven Development

I60R ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.