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

Ну или снова передумать, прочитав «Эффективную работу с унаследованным кодом» (то есть самого Физерса).

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

Читай тред.

Что дже ты утверждал?

Т.е. ты даже не потрудился посмотреть на то, с чем ты споришь? Ну показательно.

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

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

Fail.

Глотай, глотай.

после таких как ты, выкидывающих тесты после написания кода

Пруф?

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

напомнить автора? ты сам пишешь о том, что если тебя по стечению обстоятельств возьмут в команду, практикующую TDD - ты начнешь профанировать саму идею TDD

Т.е. ты даже не потрудился посмотреть на то, с чем ты споришь?

Конечно потрудился. Просто сейчас оказывается, что ты имел ввиду совсем не то. Вот я и спрашиваю - а что же ты конкретно имел ввиду. Чтобы ты четко и ясно ответил.

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

Так пишутся тесты до кода или во время написания кода? Ты выбери уже.

напомнить автора?

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

Тест-Код-Тест-Код. Здесь в моем понимании нет _тестов_ до кода, тесты пишутся в процессе разработки. Тест перед кодом - да. Один маленький тест, на одно маленькое изменение в коде.

Там нет тестов до кода, там пусто, под конец у тебя куча тестов

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

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

Методология от этого не меняется. Просто кому-то удобно сперва все тесты записать, а потом приступать к написанию кода, а кому-то (кто ценит свое время) - наоборот.

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

Писать кучу тестов перед кодом никто не запрещает, но это не TDD, это другая независимая от TDD методология тестирования

это именно TDD. а когда у тебя изменения в концепции во время написания кода вызывают новые тесты или удаление старых - это какая-то херня, к TDD отношения не имеющая

это именно TDD

Нет.

а когда у тебя изменения в концепции

В дизайне кода. Бек пишет, что TDD - это и средство формирования дизайна. Формирования.

Бек пишет, что TDD - это и средство формирования дизайна. Формирования.

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

Объясни это Беку. Или напиши свою книгу/статью/комментарии по TDD, в которой опишешь иной процесс разработки.

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

Объясни это Беку

Зачем? Он это прекрасно понимает и сам.

Или напиши свою книгу/статью/комментарии по TDD, в которой опишешь иной процесс разработки.

Бек уже написал, как видно.

Обрати внимание - у тебя одного единственного есть какое-то СВОЕ ОСОБОЕ ПОНИМАНИЕ. Какова вероятность, что это это мы все не правы, а не ты дебил?

Я тоже считаю, что спор бесполезный.

Бек уже написал, как видно.

И ты приведешь сейчас список тестов, которые он написал до кода.

Обрати внимание - у тебя одного единственного есть какое-то СВОЕ ОСОБОЕ ПОНИМАНИЕ.

Спор больше терминологический.

Какова вероятность, что это это мы все не правы, а не ты дебил?

С такой постановкой вопроса дебил - ты.

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

Чтобы понимать цитату, нужно понимать контекст, а для этого нужно прочитать книгу. Я нигде не говорил, что тесты нужно писать после кода. Это вы сами придумали и доказываете обратное, но это не ко мне, а к психиатру.
И да, где список тестов, которые Бек написал до кода? Почему ты не можешь отвечать за свои слова, а только ссылаешься на чужие цитаты, выдранные из контекста?

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

Ты говоришь что тесты нужно писать во время, а не до. Бек говорит, что тесты надо писать до. При чем говорит четко и однозначно. Вопрос закрыт.

Убей его и напиши его кровью на стене: «Он не понимал ценность тестирования».

Не очень понял. Сеньор стоит у тебя за плечом и смотрит, как ты работаешь?

И что ты подразумеваешь под _во_время_?

Тест-Код-Тест-Код.

Вот это я называю «во время». Бек это называет «до». Вы это «до» свели к тому, что _все_ тесты предлагаете писать до кода. Это ошибка, поэтому я называю «во время», чтобы обозначить, что до кода пишется только тот тест, который покрывает небольшой кусок функциональности, которую ты хочешь реализовать в данный момент. Затем все повторяется. Так что список твоих долгов пополнился:
1. Список тестов из книги, которые написал Бек до кода. Это ведь несложно, да?
2. Объясни смысл цепочки красный-зеленый-рефакторинг.

Я пишу тесты пока очень медленно. Вот он и думает, что а давайте сначала код напишем.

Бек это называет «до».

Нет, Бек «до» называет «до», а не во время.

Вы это «до» свели к тому, что _все_ тесты предлагаете писать до кода.

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

1. Список тестов из книги, которые написал Бек до кода. Это ведь несложно, да?
2. Объясни смысл цепочки красный-зеленый-рефакторинг.

Еще раз, для особо одаренных. Не важно когда именно ты тесты запишешь именно в виде тестов, их программного кода. От этого ничего не меняется. Можешь записывать как хочешь - до, после, во время.

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

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

Так кто мешает просто не говорить ему, что ты пишешь тесты?

Что делать?

Понять, что твои тесты/твой_код никому нах не нужны и не интересны. Нужна решённая задача, которую оценили в х рублей. Если ты сможешь обосновать написание тестов на данной конкретной задаче за конкретное время, то пиши на здоровье, иначе «в свободное от работы время».

Нет

Перечитай еще раз в том мете, где написано про красный-зеленый-рефакторинг.

И ведь именно об этом говорит Бек. Четко, однозначно.

Ты уже обосрался привести четкий однозначный список тестов, которые написал Бек до кода.

Не оставляя никаких вариантов для разночтений.

Но ты все же умудрился.

_не менялись_

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

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

Я именно об этом и говорю.

ага. Вот кто бы знал, что stream нужно стабить в Node.js с помощью EventEmitter, посылая в тестсте с помощью emit нужное событие с нужными данными.

в ажайл их регулярно верифицируют другие люди

Из данной ситуации 3 выхода:

1. Убедить сеньора (либо вышестоящее руководство) что ты прав.

2. Согласиться, что прав всё таки он

3. Искать другое место работы

аджайл насрать на тести и на код. он сконцентрирован на взаимодействии в команде и на достижении результата. Я бы даже сказал бы что при «гибкой разработке» тесты не нужны так как «гибкость» предполагает изменение функционала (иногда частое) и разработку при отсутствии полного ТЗ при постоянном диалоге с заказчиком.

Перечитай еще раз в том мете, где написано про красный-зеленый-рефакторинг.

Везде где Бэк пишет про «тест» имеется ввиду целая совокупность тестов. Это не один тест, по факту. Например полный набор тестов, задающий спецификация функции - это у Бэка «тест».

Ты уже обосрался привести четкий однозначный список тестов, которые написал Бек до кода.

Абсолютно все, если ты еще не понял.

Я именно об этом и говорю.

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

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

Правильно - если у тебя много функций, то по мере написания может измениться представление о том, как все должно работать, например, изменится разделение логики между этими ф-ми и т.п.

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

Чего?

Везде где Бэк пишет про «тест» имеется ввиду целая совокупность тестов. Это не один тест, по факту. Например полный набор тестов, задающий спецификация функции - это у Бэка «тест».

Зачем столько много слов, когда ты можешь просто привести список тестов, которые Бек написал до кода. Вот был список тестов и не было кода - вот код, который проходит тесты. Опять обосрался?

Абсолютно все, если ты еще не понял.

Если ты еще не понял, каждый тест писался перед написанием кода, который его проходит, но после кода, который проходит написанный ранее тест.

или нет?

Нет.

Правильно - если у тебя много функций, то по мере написания может измениться представление о том, как все должно работать, например, изменится разделение логики между этими ф-ми и т.п.

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

Зачем столько много слов, когда ты можешь просто привести список тестов, которые Бек написал до кода.

Все тесты из книги написаны до кода.

Если ты еще не понял, каждый тест писался перед написанием кода, который его проходит, но после кода, который проходит написанный ранее тест.

Неверно.

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

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

Ты что-то классно придумал, это соответствует нескольким наборам. Ты написал часть из них - понял, что придумал хуево, переделал наборы. Но нет такой ситуации, что ты пишешь набор, в середине у тебя чешется левая пятка и ты переделываешь набор. Более того - это основная «фишка» ТДД. Это то, ради чего весь этот ТДД нужен. Ради чего он задумывался.

Поэтому TDD предполагает маленькие шаги в режиме тест-код-рефакторинг-тест-код-рефакторинг.

Правильно. У тебя просто неверное представление о том, каков размер шага.

Вот был список тестов и не было кода - вот код, который проходит тесты.

Все тесты

Понятно, балабол.

до кода

Я не предлагаю писать их после.

Неверно.

Тут ты должен объяснить суть цепочки тест-код-рефакторинг-тест-код-рефакторинг.

Еще раз, для совсем уж тупых, вроде тебя.

Ошибка только в слове набор. Старайся еще.

У тебя просто неверное представление о том, каков размер шага.

Ты уже объяснил это Беку?

маленькие функции с говорящими за себя наименованиями.

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

Ратовать за TDD и при этом не оформлять код комментариями — это примерно как бомжу отбеливать зубы под «голливудскую улыбку». Оформление кода и комментарии — это гораздо более базовое правило к «гигиене разработки».

Eсли ты забросишь тесты, они начнут валиться и ты это увидишь

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

Если ты забросишь комменты, то об этом никто не узнает

Что значит «забросить»? «Перестать писа́ть» — это заметит все, кто ими пользуется. «Не обновлять» — кто-то заметит несоответствие и вырежет/поправит комментарий.

Фейл - ето ты, азаза!

Нет я.

Тут ты должен объяснить суть цепочки тест-код-рефакторинг-тест-код-рефакторинг.

Я уже объяснил.

Ты уже объяснил это Беку?

Зачем объяснять ему то, про что он книжку написал?

Ошибка только в слове набор. Старайся еще.

Повторяю последний раз и заканчиваю с попытками объяснить что-то дебилу - везде у Бэка под «тестом» подразумевается целый набор тестов.

Поправиь комментарий гораздо проще и быстрее

Не править комментарий еще проще и быстрее. Достаточно попробовать, чтобы в этом убедиться.

о имена функций имеют большую склонность к отрыванию от реальности с течением времен

Если ты изменил поведение функции, не изменив ее название, ты солгал коллеге (а коллега - это в том числе и ты, вернувшийся к коду через некоторое время).

это гораздо более базовое правило к «гигиене разработки»

Которое говорит, что комментарии не нужны.

Везде у Бэка под «тестом» подразумевается целый набор тестов.

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

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

ВСЕ ТЕСТЫ В КНИГЕ удовлетворяют этому условию, дебил. Бери любой.