LINUX.ORG.RU

регулярно вижу как программисты двинутые на tdd вместо полезного кода пишут тонны тестов, а работа стоит на месте. так что, не хватает тега «все правильно сделал».

waker ★★★★★ ()

Объяснить, что тебе удобнее иначе, что продуктивность будет выше, не получается?

Какие аргументы приводятся с обеих сторон?

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

я в общем я того же мнения (что тесты не являются продуктивным кодом)

но как блджад иначе разобраться в тонне легаси кода, который сделал 2 года назад уволенный быдлокодер?

EnterpriseMobility ()

Что делать?

Пиши заявление на уход с лора.

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

Как, как.. Сиди потихоньку да разбирайся. Я вот тем самым щас и занимаюсь. Потихоньку все причесываю. Правда бывают моменты, что начнешь одно причесывать, а там за ниточки тянется куча всего-всего, ну ничего — и не такое разгребали.

deep-purple ★★★★★ ()

А ты попробуй. Зачем запариваться? Деньги тебе платят, дают задание - выполняй. Может начальник потом поймет, что сказал фигню, а может ты поймешь, что был не прав.

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

потому что у тебя при TDD при окончании прожекта уже будут тесты.

А при не-TDD они будут «когда-то потом», которое быстро превращается в «никогда не будут». ОК?

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

программисты двинутые на tdd вместо полезного кода пишут тонны тестов, а работа стоит на месте

Два билда этому товарищу вне очереди. TDD только мешает, создавая иллюзию защищенности.

ТС, пиши комментарии, чтобы код можно было прочитать и понять. А то свалят две кучи говна (код и тесты) рядом, оно лежит, воняет дерьмом на всю округу, зато автор доволен: все правильно сделал. И пофигу, что эти тесты могут порождать костыли (mock'и), добавляют головной боли при изменении API (это в js-параше хорошо, потому что там нет компилятора, который скажет: «вот тут этого метода нема, а вон там сигнатуры не совпадают»). Словом, от TDD вреда в разы больше, чем пользы.

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

ради справедливости должен сказать что ты путаешь test first и TDD, хотя в этом примере это и не так важно

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

А при не-TDD они будут «когда-то потом», которое быстро превращается в «никогда не будут». ОК?

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

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

я в общем я того же мнения (что тесты не являются продуктивным кодом)

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

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

тоже до написания кода. отличие в том, что в test-first тестами покрывается спека или требования, и этот набор тестов не меняется до конца разработки. в TDD - у тебя бардак полная свобода в добавлении и изменении тестов

vostrik ★★★☆ ()

программистом не работаю,но имею на этот счёт такие фантазии: 1)Всё что надо посмотреть выводится в консоль. если надо конкретному сообщению присваивается ID 2)Ну раз нет програмных тестов,то в качестве теста будет выступать потребитель,молчит хорошо,не молчит исправляем и требуем повышения зарплаты за возню.

anonymous ()

А разве в TDD тесты можно писать до кода? Да, они пишутся перед вносимым изменением, но только в масштабе вносимых изменений, и так же переписываются вместе с кодом. Так что я в TDD не вижу никаких тестов _до_кода_, скорее вместе с кодом. Для себя заметил в TDD положительный эффект от того, что это похоже на контроль двух рук: я в двух местах пишу почти один и тот же код, что защищает меня от ошибок, допускаемых по невнимательности. Время разработки, к сожалению, дико распухает, поэтому боюсь пока предлагать работодателю такую методику и балуюсь TDD дома, пока никто не видит.

winlook38 ★★ ()

Это значит, что твоему синьёру не нужно качество.

Что делать?

Do the Govnocode. Когда тебе скажут, что качество упало говори, мол, поменяли стратегию разработки, вот и результат.

anonymous ()

Тесты не нужны.

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

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

Особенно прикольно для медицинского оборудования - там столько молчунов будет 8)

Deleted ()

я должен сначала написать код (весь, целиком), а уж потом писать тесты.

сеньор требует «пиши код блеать!» ??

он в общем-то прав. То есть совсем вообще прав. То есть я-бы на его месте делал то-же самое

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

это инвестиция в будущее, когда приложение станет большим, тесты будут тебе экономить ох как много времени,

Это инвестиции в /dev/null Когда код растет он еще и меняется. Поэтому либо тесты переписываются вместе с кодом, либо о них забывается.

anonymous ()

Англицизмы... Бить за них нужно. С вертушки и в пустую голову.

fero ★★★★ ()

Хватит ныть на ЛОРе. Я твой сеньор. Пиши код, как сказано, а то эту плошку риса будет кушать кто-нибудь другой!

anonymous ()

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

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

anonymous ()

Там все такие дебилы, или только твой сеньор? Я б с такого быдлокодерятника давно свалил на другую работу.

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

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

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

Проблема с Therac-25 была в том, что какой-то чудак сказал выпилить всю аппаратную защиту. А её там должно было быть уровня 2.

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

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

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

vostrik ★★★☆ ()
Последнее исправление: vostrik (всего исправлений: 1)
Ответ на: комментарий от EnterpriseMobility

При не TDD есть тестеры. Они вообще должны быть всегда. Пусть всегда будет солнце Пусть всегда будет небо Пусть всегда будет тестер Пусть всегда буду я. Желательно не оранжевый.

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

должны быть. но тестеры в основном не пишут юнит-тестов, и вообще (пушшо выросли они из ручных манки-тестеров) обычно любят автоматизировать черный ящик интеграционными тестами. что дорого, долго и неудобно. прослойка в виде юнит-тестов, особенно если их наличие гарантировано методикой - хорошая практика. написать код и потом может быть покрыть его юнит-тестами - плохая, негодная практика

vostrik ★★★☆ ()

А чего, среднего варианта нет? Пишу тесты для PoC (proof of concept). Далее из PoC рождается новый, нужный код.

Да, таки то не спец сам.

gh0stwizard ★★★★★ ()

не знаю, что тут обсуждать. тесты нужны. кто этого не понимает - школьник.

никакие коменты не дадут тебе уверенности в твоих изменениях, когда ты возвращаешься к проекту через пару недель. QA тоже не гарантия.

когда их писать - дело привычки. главное писать.

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

когда ты возвращаешься к проекту через пару недель.

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

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

пруфы в студию. Завтра распечатаю и положу на стол сеньору.

Зы. Кстати, на след неделе консультант приходит. По тестам. Да.

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

тут не пруфы, тут книжками надо будет размахивать. о том, что такое QA, что такое юнит-тесты и вот это вот всё. могу завтра накидать, но там книжки такие, что ими проще по голове настучать, чем их кратко пересказать. ну разве что брать за краткий пересказ книжек два твоих последних треда вместе с комментариями.

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

Это инвестиции в /dev/null Когда код растет он еще и меняется

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

И еще когда код растет он еще и усложняется и при этом сложнее отследить не сломано ли чего при каких либо изменениях.

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

Нет, но можно завещать и живьем. А потом передумать.

RedPossum ★★★★★ ()

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

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