никакие коменты не дадут тебе уверенности в твоих изменениях

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

У меня нет особых проблем с возвращением к коду даже спустя несколько месяцев, потому что в комментариях написано, что ожидается от каждой функции, а нетривиальные и неочевидные моменты также откомментированы по месту. Вроде: «тут мы делаем так-то, потому что там-то ожидается то-то».

Переписать (отрефакторить) кусок кода, если известно, что он должен делать опять-таки плевое дело. Но если ты codemonkey, которая длину строки без тестов написать не в состоянии, то тебе остается только самовыпилиться из профессии.

Нужно исходить исключительно из целесообразности

При TDD вообще не обязательно писать тесты. Смысл TDD в том, что программист должен продумать спецификацию ф-и и особенности ее реализации _до_ начала написания кода. Написание тестов лишь вынуждает это сделать (тесты = спецификация), но никто не мешает тебе делать то же самое без тестов. Только зачем?

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

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

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

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

потому что в комментариях написано, что ожидается от каждой функции

Комментарии устаревают. Всегда. И чем больше комментарий, тем больше в нем лжи. Может быть ты очень дисциплинированный и пишешь код в одиночку, но вот в команде комментарии скорее врут, чем говорят правду. Поэтому часто советуют бить большой кусок кода, требующий объяснений, на маленькие функции с говорящими за себя наименованиями.

А разве в TDD тесты можно писать до кода?

Нужно

Так что я в TDD не вижу никаких тестов _до_кода_, скорее вместе с кодом.

пока все тесты (очевидно уже написанные) не зажглись красным - никакого тебе кода, похабник

Посмотрел твои топики — ржем всем шредером.

 Пришел новый работник
Форум - Talks

Эксперт по Ноде с многолетним стажем. С книжками по паттернам проектирования на ноде (от Packt Publishing) и ангулару (Pro AngularJS). Бумажными.

Ну сейчас он выведет наши проекты из тупика.

Да.

 node.js, история узбека
EnterpriseMobility (16.02.2015 12:37:17) 

------------

 Визуализация асинхронного кода
Форум - Talks

 async, node.js, uml, диаграммы, история узбека
EnterpriseMobility (27.02.2015 16:18:26) 

--------------

 Реализация upload в Rest сервисе
Форум - Development


 http, node.js, история болезни
EnterpriseMobility (23.03.2015 22:52:21) 

-------------

 почему протокол FTP так плохо документирован?
Форум - Talks


 история узбека
EnterpriseMobility (26.03.2015 12:36:49) 

---------------

 JavaScript - язык бомжей?
Форум - Talks

я так и думал
....
Ну и куда нам переходить после этого? Erlang? LISP?

 javascript, вещества, история узбека
EnterpriseMobility (11.04.2015 11:14:43) 


------------

 Сегодня мне приснился страшный сон
Форум - Talks

Что я всю оставшуюся жизнь буду программировать на JavaScript.

 вещества, история болезни
EnterpriseMobility (14.04.2015 12:05:56) 

-------------


 Вопрос на знание архитектуры Node.js
Форум - Talks

 node.js, вещества, история узбека
EnterpriseMobility (14.04.2015 23:02:00) 

-------------

В топик призываются специалисты по sinon.js

node.js, история узбека, паттерны, стабильность, тестирование
EnterpriseMobility (17.04.2015 17:11:45) 

------------

 Производительность for в Node.js/io.js
Форум - Web-development

сегодня подрались с сеньором по поводу использования циклов по элементам массива.


 node.js, истеричка, история узбека
EnterpriseMobility (23.04.2015 12:42:48) 

------------

 чем тестировать XPath?
Форум - Development


 xml, xpath, истеричка, история узбека
EnterpriseMobility (28.04.2015 10:02:19) 

------------

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

 tdd, истеричка, история узбека
EnterpriseMobility (29.04.2015 16:54:14) 

может он не в курсе про
Всё программное обеспечение было написано на языке ассемблера.

Комментарии устаревают. Всегда. И чем больше комментарий, тем больше в нем лжи. Может быть ты очень дисциплинированный и пишешь код в одиночку, но вот в команде комментарии скорее врут, чем говорят правду.

Становится жалко тебя, видя с каким кодом ты работаешь...

Тест - нужно. Тесты - не нужно. Иначе ткни где описана методология TDD написания тестов до кода.

все тесты

Откуда вы берете все эти тесты? Речь ведь не о приемочных тестах, а о TDD. Пишешь тест - пишешь код. О каких тестах вы говорите?

Это ты Стива Макконнелла и Роберта Мартина жалкими назвал? Ну ок, тебе виднее.

You are doing it wrong

а в этом и есть фишка test-first и TDD - чтобы написать код ты сначала пишешь ВСЕ тесты на функционал. и сделано это не для удобства тестирования (приятный побочный эффект, не более) а для того, чтобы ты в условиях грёбаного Agile, где ничего не понятно с требованиями, а «спецификация» - ругательное слово, четко знал, что и зачем ты будешь писать, и чего не будешь: кода пишется ровно столько чтобы прошли тесты, ни строчкой больше

О, да у тебя ещё и дислексия. Извини, не знал.

Ты просто можешь дать ссылку на то, где описано твое видение TDD. Я ориентируюсь на книгу Кента Бека, и ни о каких тестах там нет речи. Тест-Код-Рефаторинг-Тест-Код-Рефакториг... В итоге код сам обрастает тестами пока ты его пишешь.

Личные оскорбления как всегда эффективны, я сдаюсь, ты меня убедил.

ты вообще её читал, книгу-то? Бек _везде_ в описании процесса использует понятие «список тестов»

ты вообще её читал, книгу-то?

2 раза. Теперь ты.
Кучу тестов имеет смысл писать только в том случае, если ты хочешь убедиться, что правильно понимаешь работу чужого кода. В рамках TDD тесты пишутся совместно с кодом (да, тест до кода, я с этим не спорю) и естественно у тебя получается куча тестов, которые дают тебе уверенность, что ты не сломал код.
В рамках TDD ты не можешь _сначала_ написать кучу тестов просто потому, что в процессе разработки ты формируешь дизайн кода и куча тестов не то, что никогда не заработает, ты большую часть своих тестов просто выкинешь.

Обвини его в микроменеджменте и технической отсталости. Если силенок хватит :)

ну если ты также пишешь тесты, как читал книгу - забей на TDD, не поможет оно тебе:

Часть III • Паттерны для разработки через тестирование

Что необходимо тестировать? Прежде чем начать, запишите на листке бумаги список всех тестов, которые вам потребуются. Чтобы успешно справляться с про­граммистским стрессом, вы должны постоянно соблюдать важное правило: нико­гда не делайте шага вперед до тех пор, пока не узнаете, в каком месте ваша нога должна коснуться земли. Приступая к сеансу программирования, определите, ка­кие задачи вы намерены решить в ходе этого сеанса.
---
В контексте разработки, основанной на тестировании, список задач — это спи­сок тестов, которые мы планируем реализовать. Прежде всего включите в список примеры всех операций, которые требуется реализовать. Далее, для каждой из операций, которые еще не существуют, внесите в список нуль-версию этой опера­ции.

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

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

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

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

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

Моя большая ошибка, это то, что я не сразу начал писать модульные тесты.

Еще ошибкой была попытка использования in-memory суррогатов баз данных с заливкой туда тестовых фикстур.

Это говно. Для этого есть стабы. Стабы. И еще раз стабы.

Обращение к файловой системе - тоже стабим.

Ну и так далее.

Т.е. ты просто так взял и подтвердил мои слова.
В первой цитате речь о todo-листе, а не о пачке готовых тестов. Пачка тестов содержит вызовы функций, которые ты собираешься написать, но часть этих функций ты никогда не напишешь, а напишешь вместо них другие, для которых ты не написал в самом начале тесты. Цена твоего TDD - около нуля, т.к. ты от него сам рано или поздно откажешься.
Во второй цитате речь больше о рефакторинге. Т.е. если ты внес изменение в код, которое поломало много тестов, то тебе потребуется много времени, чтобы исправить их, что сбивает с ритма и провоцирует отказаться от тестирования. Предпочтительно вносить маленькие изменения, если и ломающие, то как можно меньшее количество тестов.

А вот и хипстота сопливая пришла, религию свою проповедует.

у тебя реально дислексия

В первой цитате речь о todo-листе

В контексте разработки, основанной на тестировании, список задач — это спи­сок тестов, которые мы планируем реализовать.

а не о пачке готовых тестов.

define «готовые». если речь идет о куске кода, готовом для xUnit'а - то да, писать их не обязательно. но вообще говоря, тест готов когда известны все входные и выходные данные. пачка тестов готова когда ты полностью проанализировал какие данные для чего применимы и какой список тестов достаточен, но не избыточен.

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

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

Цена твоего TDD - около нуля, т.к. ты от него сам рано или поздно откажешься.

профит такого TDD - возможность нормально работать в Agile-методологии, когда с требованиями у тебя все плохо и они есть только hi-level: в процессе составления списка тестов ты уже знаешь, что должно получиться в итоге, а не продумываешь архитектуру на лету и постоянно пишешь вместо одних функций другие.

у тебя реально дислексия

Опять этот мощный аргумент, против которого у меня нет контраргументов.

которые мы планируем реализовать

define «готовые»

Реализованные, а не планируемые.

нуль-версию этой опера­ции

Это и есть код, который ты написал после теста.

Ошибки по невнимательности как раз и исправляются на этапе дублирования кода

ТДД это не об ошибках по невнимательности, еще раз. Смысл ТДД в том, чтобы сперва думать о задаче, а потом решать. Это все. ТДД ортогонально тестам (несмотря на название, да).

Кент Бек

Он идиот.

ты так говоришь, как будто это плохо

Двачую этого господина. Хоть кто-то понимает, в чем смысл TDD, а не просто как макака бездумно повторяет действия.

ты большую часть своих тестов просто выкинешь.

Еще раз - ты делаешь все неправильно. Тесты в TDD фиксируют спецификацию функции. Когда тесты достаточно подробно описали спецификацию и ты понял что, собственно, от этой ф-и требуется - ты принимаешься за реализацию. Выкидываться тесты могут только в том случае, если спецификация поменялась.

Опять этот мощный аргумент, против которого у меня нет контраргументов.

ну потому что ты реально не умеешь читать. тебе Бек твой пишет

С чего следует начать разработку некоторой функциональности? С написа­ния тестов, которые должны сработать тогда, когда код будет полностью завершен.

а тебе всё божья роса. тебе пишут

Однако помимо прочего предварительное тестирова­ние является мощным инструментом формирования дизайна и средством кон­троля над объемом работы.

а ты тупишь и задаешь глупые вопросы вида «а зачем такой TDD нужен?»

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

a кто тебе сказал что эти комментарии еще актуальны? Eсли ты забросишь тесты, они начнут валиться и ты это увидишь. Если ты забросишь комменты, то об этом никто не узнает.

религию свою проповедует.

ты лучше молчи и слушай, что люди говорят. глядишь поймешь что-то.

ТДД это не об ошибках по невнимательности

Ошибки по невнимательности - это моя личная проблема. Большая. Ее нужно решать. У меня нет четких понятий о том, как прокачивать внимательность, это вопрос к психологам больше, наверное. У меня нет объективных оценок моей внимательности кроме ошибок в коде, которые ушли в прод, а это дорогие оценки. Я пробую разные подходы и TDD пока лучше всего с этой проблемой мне помогает. TDD не об ошибках по невнимательности, но кого это волнует кроме теоретиков-задротов, если оно позволяет решать конкретные фактические проблемы?

Он идиот.

А сказать это хотя бы из-под анонимного ника ты просто зассал.

Ошибки по невнимательности - это моя личная проблема.

Для решения каждой проблемы есть свой инструмент. ТДД - это не инструмент для решения проблемы ошибок по невнимательности.

А сказать это хотя бы из-под анонимного ника ты просто зассал.

Зассал чего? Того, что он меня завтра с ножом за гаражами встретит?

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

Смотри, в чем проблема. Ты берешь ТДД (который не об ошибках по невнимательности) и модифицируешь этот инструмент для своих нужд. В этом ничего плохого нет, главное чтобы этот модифицированный инструмент был эффективен для решения твоих задач. Но это уже какой-то другой инструмент, не ТДД. И если мы обсуждаем ТДД - то мы обсуждаем ТДД, а не специальную-версию-ТДД-winlook38'a-предназначенную-для-устранения-ошибок-по-невнимательности.

Если же ты хочешь обсудить специальную-версию-ТДД-winlook38'a-предназначенную-для-устранения-ошибок-по-невнимательности, то так и уточняй, что это не классическое ТДД, а твоя собственная методология на ее основе. И мы обсудим. Просто вещи надо называть своими именами, верно же?

Тесты в TDD фиксируют спецификацию функции. Когда тесты достаточно подробно описали спецификацию и ты понял что, собственно, от этой ф-и требуется - ты принимаешься за реализацию.

Только с чем ты хотел поспорить, я не понял. Наверное, ты хотел сказать всем, что ты тоже понимаешь, что такое TDD. Хорошо, мы поняли.

Выкидываться тесты могут только в том случае, если спецификация поменялась.

При работе по TDD ты меняешь дизайн кода по мере его разработки. Т.е. ты решаешь что ты хочешь получить, пишешь тест, реализуешь, рефакторишь, а затем повторяешь все заново. Снова и снова. Дизайн кода при этом меняется, на каком-то этапе ты понимаешь, что твои представления были ошибочны и продолжаешь двигаться чуть-чуть в другом направлении. Если ты написал тесты для того кода, который ты никогда не напишешь, то тесты ты просто выкинешь. Это не TDD.

Прочитав «Mифический человеко-месяц», «Coders at work» и «Пишите код б-ть!» :)

Только с чем ты хотел поспорить

С тем, что якобы в ТДД тесты не пишутся до кода.

Т.е. ты решаешь что ты хочешь получить, пишешь тест, реализуешь, рефакторишь, а затем повторяешь все заново.

Нет. ТДД предназначена для того, чтобы _избежать_ этого процесса (или хотя бы максимально сократить).

Если ты написал тесты для того кода, который ты никогда не напишешь

А зачем писать тесты для кода, который ты никогда не напишешь?

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

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

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

Разочарую тебя, ты не привел ни одной цитаты по этому поводу.

Ну да, дислексия.

ТДД - это не инструмент для решения проблемы ошибок по невнимательности.

Приведи цитату, где я утверждал что-то подобное.

Зассал чего?

Просто ты по жизни ссыкло.

и модифицируешь

Пруф или балабол.

Если же ты хочешь обсудить специальную-версию

Нет, я говорю о TDD, описанном Беком. А твое непонимание TDD - это другая тема.

Нет, я говорю о TDD, описанном Беком.

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

С тем, что якобы в ТДД тесты не пишутся до кода.

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

Нет.

У тебя свой, ни с чем не совместимый TDD.

А зачем писать тесты для кода, который ты никогда не напишешь?

Я и говорю, что не нужно.

Ну так лечись.

Я уже разжевал эти цитаты и переварил, тебе осталось проглотить.

Я и говорю, что не нужно.

А что, кто-то предлагал?

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

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

Везде

Ты только показал всем что читать не умеешь.

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

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

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