регулярно вижу как программисты двинутые на tdd вместо полезного кода пишут тонны тестов, а работа стоит на месте. так что, не хватает тега «все правильно сделал».
Как, как.. Сиди потихоньку да разбирайся. Я вот тем самым щас и занимаюсь. Потихоньку все причесываю. Правда бывают моменты, что начнешь одно причесывать, а там за ниточки тянется куча всего-всего, ну ничего — и не такое разгребали.
А ты попробуй. Зачем запариваться? Деньги тебе платят, дают задание - выполняй. Может начальник потом поймет, что сказал фигню, а может ты поймешь, что был не прав.
программисты двинутые на tdd вместо полезного кода пишут тонны тестов, а работа стоит на месте
Два билда этому товарищу вне очереди. TDD только мешает, создавая иллюзию защищенности.
ТС, пиши комментарии, чтобы код можно было прочитать и понять. А то свалят две кучи говна (код и тесты) рядом, оно лежит, воняет дерьмом на всю округу, зато автор доволен: все правильно сделал. И пофигу, что эти тесты могут порождать костыли (mock'и), добавляют головной боли при изменении API (это в js-параше хорошо, потому что там нет компилятора, который скажет: «вот тут этого метода нема, а вон там сигнатуры не совпадают»). Словом, от TDD вреда в разы больше, чем пользы.
А при не-TDD они будут «когда-то потом», которое быстро превращается в «никогда не будут». ОК?
Норкоман, тесты нужны в т.ч. для разработки - мы наколхозили что-то но чтобы это проверить надо запустить кучу вской хрени и ткнуть 500 раз в разные места, чтобы фичу проверить без вышеописанного и нужен юнит тест, это даже очевидно бе всяких тдд
я в общем я того же мнения (что тесты не являются продуктивным кодом)
это инвестиция в будущее, когда приложение станет большим, тесты будут тебе экономить ох как много времени, и вероятность того что ты задеплоишь бажный код на прод тоже значительно снизится.
тоже до написания кода. отличие в том, что в test-first тестами покрывается спека или требования, и этот набор тестов не меняется до конца разработки. в TDD - у тебя бардак полная свобода в добавлении и изменении тестов
программистом не работаю,но имею на этот счёт такие фантазии:
1)Всё что надо посмотреть выводится в консоль.
если надо конкретному сообщению присваивается ID
2)Ну раз нет програмных тестов,то в качестве теста будет выступать потребитель,молчит хорошо,не молчит исправляем и требуем повышения зарплаты за возню.
А разве в TDD тесты можно писать до кода? Да, они пишутся перед вносимым изменением, но только в масштабе вносимых изменений, и так же переписываются вместе с кодом. Так что я в TDD не вижу никаких тестов _до_кода_, скорее вместе с кодом. Для себя заметил в TDD положительный эффект от того, что это похоже на контроль двух рук: я в двух местах пишу почти один и тот же код, что защищает меня от ошибок, допускаемых по невнимательности. Время разработки, к сожалению, дико распухает, поэтому боюсь пока предлагать работодателю такую методику и балуюсь TDD дома, пока никто не видит.
шли сеньора в пень — это не его собачье дело. эскалируй тимлиду. с одной стороны, именно он отвечает за твою производительность, с другой — он же рекомендовал взять тебя на работу.
имей в виду, что возможны варианты. в том числе возможно именно тебя пошлют искать более подходящее твоему темпераменту занятие.
Скорее это вы не в курсе, что в мире есть не только черное и белое. Во первых, автор делает не софт, от которого зависит здоровье людей, а какие-то въеб-странички для дорков. Второе, самый худший проверятель - это сам разработчик, гораздо полезнее другой кодер. В третьих, если качество хоть чуточку нужно, то можно нанять инженера по автоматич. тестированию, пользы явно будет больше.
В третьих, если качество хоть чуточку нужно, то можно нанять инженера по автоматич. тестированию, пользы явно будет больше.
порядок написания тестов и наличие automation QA - вещи ортогональные. ну будет automation QA, получит он код для проверки раньше, чем будут написаны тесты, попробует что-то автоматизировать и обломится, потому что код этот даже самые примитивные тесты не проходит, а автоматизация тестирования - это в большинстве случаев полный цикл тестирования фичи + автотест, покрывающий эту функциональность как результат, штука затратная по времени и требующая работающий код. юнит-тесты, написанные до кода - это хоть какая-то гарантия того, что код вообще тестировался, если это, конечно, не что-то такое
При не TDD есть тестеры. Они вообще должны быть всегда. Пусть всегда будет солнце Пусть всегда будет небо Пусть всегда будет тестер Пусть всегда буду я. Желательно не оранжевый.
должны быть. но тестеры в основном не пишут юнит-тестов, и вообще (пушшо выросли они из ручных манки-тестеров) обычно любят автоматизировать черный ящик интеграционными тестами. что дорого, долго и неудобно. прослойка в виде юнит-тестов, особенно если их наличие гарантировано методикой - хорошая практика. написать код и потом может быть покрыть его юнит-тестами - плохая, негодная практика
тут не пруфы, тут книжками надо будет размахивать. о том, что такое QA, что такое юнит-тесты и вот это вот всё. могу завтра накидать, но там книжки такие, что ими проще по голове настучать, чем их кратко пересказать. ну разве что брать за краткий пересказ книжек два твоих последних треда вместе с комментариями.
Это инвестиции в /dev/null Когда код растет он еще и меняется
ну а как ты бля хотел, конечно в некоторых случаях если код меняется то и меняются/дополняются/удаляются тесты,но этот процесс уже происходит быстрее намного чем написание тестов с 0.
И еще когда код растет он еще и усложняется и при этом сложнее отследить не сломано ли чего при каких либо изменениях.
Никогда не понимал смысла в юнит тестах. Всегда писал сначала код, а потом, через энное количество показов и переделок, когда требования наконец устаканивались - интеграционные и нагрузочные тесты под критические куски системы.