сеньор поставил мне ультиматум

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

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

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

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

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

А при чём тут TDD?

Что делать?

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

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

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

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

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

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

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

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

Потому что Физерс так завещал

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

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

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

ОК, при TDD подходе когда нужно писать тесты? Или там это не указывается?

Ну вот у нас как раз и JavaScript

ТС не слушай кадров типа этого

сеньор поставил мне ультиматум (комментарий)

для начала делай хотя бы какое-то базовое покрытие тестами кода который собираешься рефакторить

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

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

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

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

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

фантазии

Ага.

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

Что делать?

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

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

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

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

Физерс так завещал

Он умер?

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

Сказали разработчики Therac-25.

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

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

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

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

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

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

А за тесты заказчик платит?

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

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

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

может он не в курсе про

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

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

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

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

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

Это не отменяет положение о качестве кода.

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

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

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

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

это чувак из фильма на игле? )

ага

что-то такое

Это чудесно! Спасибо.

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

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

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

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

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

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

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

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

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

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

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

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

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