Комментарии 43
Разработчик не пишет тесты не потому, что чего то там боится, а потому что время очень ограничено. Бизнес торопит со сроками. Все ваши доводы не разработчикам нужны, а бизнесу.
В итоге тратит х10 времени на отладку и проверку функционала на стейдже и проде. QA не смогут проверить всё, так как e2e и интеграционные физически не смогут покрыть все аспекты, поэтому unit тесты их дополняют.
Если бизнес готов тратить деньги на баги и время на их исправление - пожалуйста.
Я как профессионал буду отстаивать время на написание тестов. В случае проблем и потери денег придут в первую очередь ко мне.
Вы правильно пишите про отстаивание времени на написание тестов, но не во всех компаниях к этому прислушиваются. Тут есть еще такой момент, что иногда бизнесу нужно что-то решать здесь и сейчас, и наличие багов в будущем не особо интересует. Ну будет баг, откроют тикет, кто-нибудь над ним поработает и выполнит, вот и деятельность видна для бизнеса - программисты закрывают задачи.
Если бизнес готов тратить деньги на баги и время на их исправление - пожалуйста.
Я еще ни разу не видел бизнес, который бы с радостью потратил деньги на тестирование, а не на новые функции. По крайней мере до тех пор, пока качество его устраивает.
В итоге тратит х10 времени на отладку и проверку
Возможно. Но и функциональность написана раньше, проверена, мы понимаем, что бизнес хотел именно этого, и двигаемся дальше. Ну и не в 10 раз конечно - если вы не можете написать код приемлемого качества без тестов, за сравнимое время - что-то у вас не так с проектом, возможно квалификация в среднем недостаточно высока (ну т.е. часть команды джуны, и без них не справляетесь), или проект слишком новый и незнакомый.
Вот просто для примера - у меня большая часть багов вызвана неопределенностями в интеграциях с другими системами. И снять эти неопределенности путем написания скажем моков - невозможно. И даже интеграционные тесты не на проме проблем зачастую не выявляют.
В общем, ваша позиция имеет право на жизнь, в определенных условиях наверное совершенно правильная - но не универсальная.
А кто говорит что unit тесты замедляют разработку?
Благодаря им происходит более быстрое внедрение новых фич. В моменте да, написание отнимает 50% времени, а то и больше, но нейросети сильно облегчили их написание. Главное накидать рабочий пример, а дальше они докидают кейсов.
А кто говорит что unit тесты замедляют разработку?
Ну вот я и говорю. Вы еще скажите, что юнит тесты каким-то образом сами создаются, и вы на их создание (и поддержку) не тратите время :)
Даже если их делают нейросети - это все равно ваше время.
Но опять же - я готов согласиться, что ваши проекты не такие как мои, и у вас могут быть другие пропорции, которые делают их более полезными. Я просто приведу пример: вот вы выполняете SQL запрос, SELECT для ясности. Это настолько типовая функция приложения, что типичнее некуда. И при этом она практически не тестируется юнит тестами - только интеграционные, и полноценно покрыть все исходы можно только в фантазиях.
накидать рабочий пример, а дальше они докидают кейсов.
Ну вот давайте, покажите мне как нейросеть накидает мне тестов на интеграцию с керберосом? Я реально с удовольствием на это посмотрю. Ну т.е. я пишу клиента для работы с REST сервисом, который одновременно HTTPS, т.е. нужно настроить сертификаты, и в тоже время - SPNEGO, т.е. нужно керберос тикеты и заголовки.
SQL запрос, SELECT для ясности. Это настолько типовая функция приложения, что типичнее некуда.
Если рассматривать именно в контексте юнит-тестирования, то ваш запрос должен генерироваться в какой-то функции, и вот именно ее вам и нужно тестировать. Или если есть возможность замокать функции модуля\коннекшна базы данных, то можно протестировать запрос в составе более "крупной" функции. Но вы должны тестировать именно подготовку запроса, так как юнитом в данном случае будет запрос.
Что этот тест даст вам? Ну как минимум проверку что параметры запроса мапятся нормально. И вы можете быть спокойны в будущем, никто не поменяет ваш код так, что в реальную базу уйдет sql-иньекция.Ну и по тесту можно понять, например что в 3-й параметр вашего запроса нельзя вставлять строки, и т.п.
И затраты на написание кода юнит-тестов иногда меньше, чем затраты времени на разделение\изоляцию рабочего кода на отдельные части, которые можно протестировать.
Тут я согласен в целом. И даже больше скажу - в моей практике как правило просто попытка разобраться в баге/странности, и лучше понять код, как правило требует проведения именно изоляции (по сути - это изоляция побочных эффектов в самом общем виде, как в парадигме ФП это называется), тогда то что осталось, чистые функции в идеале, либо легко тестируется, либо мы баг просто вычисляем путем обдумывания.
генерироваться в какой-то функции, и вот именно ее вам и нужно тестировать
Ваш ответ валидный, но он про другое. Вы не уловили сути, я ее плохо описал. Нужно протестировать именно сам запрос и его выполнение. Он может быть вообще не генерируется, и статический.
Но при выполнении у вас даже в простейшем случае два варианта - успешно и нет. Идем дальше - успешно это 0 строк ответа, 1 или много? Оно соответствует ожиданиям? Если неуспешно - то какой код ошибки вернула нам СУБД? Ну и на этом примерно все - как только нам это становится интересно, и мы пытаемся вот это протестировать, мы быстро понимаем, что API или контракт, как ни назовите, СУБД, настолько сложен, что писать под него юнит тесты ну очень муторно. Ну в принципе, потому, что СУБД как правило сильно сложнее нашего типичного прикладного продукта. Т.е. тестировать интеграцию с продуктом, который сложнее нашего, и пытаться это делать юнит тестами - по моему опыту довольно бессмысленно.
замокать функции модуля\коннекшна базы данных
А вы попробуйте как-нибудь на досуге :) Этот модуль в моем случае называется JDBC. И он, скажем прямо, уже как правило сложнее того кода, что пишет большинство миддлов по работе. Я пробовал его мокать/наследоваться. Эта овчинка не стоит выделки.
Вы предлагаете разработчику не запускать и не дебажить свой код после реализации? Вы написали класс с методами. И сразу пушите? Без запуска и контроля, что он вообще делает? Поздравляю, у проекта проблемы. Тогда да, юнит тесты (если они продвигаются руководством) решат проблему забагованного кода. А если разработчик, написав метод, запускает его на подготовленных кейсах и контролирует его выполнение - зачем юнит тесты?
Вопрос с юнит тестами состоит в очень простой формулировке: время на разработку (и в особенности, на изменения и подгонку тестов при рефакторингах) юнит тестов больше, чем время на дебаг у ответственного разработчика? Если больше, они не нужны и вредны. Если в команде разработчики ВООБЩЕ не прогоняют свой код и не дебажат перед пушем - вопросов нет, юнит тесты нужны.
И кстати, про QA.
1. Задачей QA не является нахождение ошибок в коде разработчика. Задачей QA является недопущение проникновения дряни в прод и обеспечение соответствия кода функциональным требованиям (причин множество, и первейшая причина - неправильное понимание требований разработчиком).
2. QA реально проверяют код на соответствие функциональным требованиям, поскольку действуют по проекту. А юнит-тесты, написанные разработчиком, проверяют код только на то, что находится в голове у разработчика. Если разработчик неправильно понял требования, или просто что-то упустил, какой-то пункт, то юнит-тесты не обнаружат эту ошибку, хоть на двести процентов покрой свой код.
3. Если нет службы качества в конторе, то никакое юнит-тестирование и Бек вам не поможет.
4. QA с девочками-тестерами должны проверять ВСЁ! Absolutly. Именно на них лежит ответственность за непрохождение брака клиенту.
Что-то я о пользе TDD в статье так и не увидел информации. 95% статьи о том что нужно писать тесты. Но вот зачем их писать перед кодом из статьи неясно.
А причина банальна. После того, как класс написан и ПРОДЕБАЖЕН, юнит-тесты нахрен не нужны.
Удивительно, что как противники, так и адепты TDD - и автор статьи - не исключение, в своих рассуждениях о предмете исходят из ложной предпосылки, что основным продуктом TDD является тестовое покрытие.
Между тем, с пониманием того, что реальная цель TDD - разработка функционала, соответствующего спецификации, все становится на свои места. Цель - корректно реализованный функционал, средство - "материализация" спецификации в виде тестов. Вопросов, почему спецификацию надо писать до написания кода, а не после, я почему-то особо не наблюдаю.
А тестовое покрытие является хоть и полезным, но всё же побочным продуктом этого подхода.
Соглашусь с высказыванием выше, что дело тут не в программистах, а в вечном и жестком лимите времени. Да, в каком-нибудь петпроекте хоть оппишись тестов, никто ведь не стоит над тобой злой тенью. А в реальных проектах тебя на каждом дейлике подгоняют. Ладно тесты... В долгоживущих проектах в какой-то момент наступает момент, когда просто жизненно необходимо уже уделать время на его рефакторинг. Оптимально хотя бы 20% от общей разработки. Так вот чтобы их выбить, каждый раз при планировании нужна грубая лесть и угрозы суицида. Устаешь от этого гораздо больше, чем от всего остального. Менеджмент живет в иных сферах и нифига он разработку не слушает. У него KPI на другое завязан. А что будет через несколько лет? А через несколько лет он уйдет на другой место с зелененькой галочкой в послужном списке о достигнутой эффективности на участке.
Я с одной стороны обеими руками за тесты (причем, за автоматические тесты) - но с другой стороны, религиозное рвение сторонников TDD только отвращает людей от здравой идеи.
Не вдаваясь в дискуссию - давайте просто посмотрим на другие отрасли, и с удивлением обнаружим, что НИКТО (ни в авиации, ни в медицине, ни где либо еще) - не пытается делать тестовые стенды под еще не готовое изделие!
С моей точки зрения, сторонники TDD путают написание теста до (или в процессе) разработки с понятием "testability" - то есть со способностью системы быть легко протестированной. Понятно, что если вы уже написали тест до создания системы, то она вынуждена оказаться testable - но какой ценой ?!
В более зрелых отраслях промышленности уже давно найдены пути обеспечения тестируемости системы БЕЗ создания тестовых стендов наперед! Да, на этапе проектирования и создания системы - обязательно надо думать о том, как мы будем это тестировать. Что подразумевает и разумное разделение интерфейсов, и IoC, и следование принципам SOLID, и много чего еще.
Однако, тест (тестовый стенд) создается только тогда, когда какая-то часть системы (или вся система) уже создана. Если очень надо сэкономить время с риском потерять часть денег и вложенного труда - проектирование и создание стенда ведется параллельно созданию основной системы. Но никто и никогда в здравом уме не делает тестовый стенд наперед, и не говорит что соответствие системы этому стенду является частью технического задания!
Если вы спроектировали и построили testable system - не имеет значения, будете ли вы писать тесты до, в процессе, или после ее создания. Из экономических соображений - я являюсь сторонником создания тестов по мере создания системы (особенно для компонентов, которые дальше будут переиспользоваться другими частями создаваемой системы). То есть, для переиспользуемых компонентов - их поведение должно быть приколочено к столу тестом до того как начнут писаться зависимые компоненты. Если же компонент не переиспользуется - его можно тестировать с любой момент когда есть на это время...
не то чтобы я защищал TDD но как будто вот это заявление
Не вдаваясь в дискуссию - давайте просто посмотрим на другие отрасли, и с удивлением обнаружим, что НИКТО (ни в авиации, ни в медицине, ни где либо еще) - не пытается делать тестовые стенды под еще не готовое изделие!
не может являться валидным аргументом
почему же в авиации не делают тестовые стенды до самолета? Ну во первых аэродинамическая труба это не тестовый стенд который у вас есть до наличия самолета? Или даже 3д модели которые тестируют на компьютере даже до стадии прототипирования?
ну давайте все это отбросим и задумаемся - а может быть причина, например, в цене такового стенда? Unit тест пишется как заявляет автор 5 минут, можете высчитать стоимость от своей ЗП за эти 5 минут. Аэродинамическая труба стоит куда дороже даже за 5 минут тестирования в ней, не то что её постройка. TDD как раз и существует лишь по тому что стоимость создания тестового стенда до создания тестируемого объекта нулевая, в отличии от любой другой отрасли.
Аэродинамическая труба - это фреймворк типа JUnit, который потенциально может покрыть целое семейство летатльных аппаратов (или режимов полета). А конкретный стенд на этой аэродинамической трубе создают уже под конретную тему (куда капилляры подключать, как к динамометру подвешивать, итд). Понятно что интерфейс (точки подвеса) заранее известны - так же как интерфейс JUnit всем известен еще до старта проекта. Но вот конкретное крепление делать или капилляры резать ДО момента предъявления тестового образца никто в здравом уме не будет...
Другое дело, что конструктор в свою очередь тоже обязан обеспечить testability. Понятное дело, никто не пытается сначала сделать целый самолет, а потом уже пихать его в трубу для продувки. Сначала делается аэродинамический макет (целый в масштабе, или отдельных частей или сопряжений в натуральную величину), и его в трубе дуют, получая фактические характеристики. Но никто и никогда не приходит ни к конструктору, ни на опытное производство с предложением: ребята, вот мы вам заранее сделали крепление и нарезали трубок - будьте добры подгоните свою модель под эти заготовки. Задача тестирования подчинена общей задаче конструирования, а не наоборот.
С другой стороны, если дурак-конструктор сделает такую модель, что там физически нельзя сделать интерфейс со стендом, то конструктора сначала обсмеют в курилках, а потом он пойдет переделывать свое изделие. Потому что когда ты что-то проектируешь НАДО думать о том, как ты это будешь тестировать.
В общем, еще раз - не надо путать обеспечение testability на этапе проектирования и изготовления, и фактического изготовления стенда вперед изделия...
ладно, пожалуй стоит сформулировать мою мысль по другому
"аналогия не является аргументом" - вот так наверное лучше. Нельзя сравнивать разработку самолета и разработку ПО и говорить - вот они так не делают и нам не нужно по этому. На стройке скрам не используют, сварщики не пользуются DDD, водителям такси не навязывают SOLID принципы управления автомобилем. В IT есть своя специфика и критиковать использование конкретного инструмента, ровно как и оправдывать таковое использование, нужно находясь в рамках IT и аргументы приводить соответствующие. "Представьте если бы ваша мама перед тем как варить борщ делала бы тестовый стенд для борща" это не аргумент, это эмоции
надеюсь, в таком виде, моя точка зрения более доступна
Я согласен, что у ИТ есть своя специфика. Но с другой стороны - ИТ всего-лишь направление инженерии! Инструменты у нас из-за этого своеобразные, да... Но общие инженерные подходы не могут быть радикально другими - инженерия опирается на математику, логику и законы физики. И что на конструктора металлических конструкций, что на радиотехника, что на программиста - все это должно действовать одинаково. Я бы сказал, что у нас в программировании можно дольше без последствий упарываться в вещи на границе религии типа того же TDD. В реальной жизни - это немедленно привело бы к таким последствиям, что рьяному последователю дали тихонько в ухо работяги опытного производства (если до того не успел уволить начальник). А в программировании - биты в памяти много чего стерпят... Однако, я бы предпочел видеть в программировании адаптации лучших инженерных практик, а не ересь типа: "тесты являются частью вашего технического задания"..
ещё раз повторюсь, что я не защищаю TDD, но все ещё не могу согласиться с тем что
Инструменты у нас из-за этого своеобразные, да... Но общие инженерные подходы не могут быть радикально другими
а почему не могут то? Они и есть радикально другие, так как работа идет с информацией - буквально абстрактным понятием, имеющем лишь некоторое физическое воплощение, от того не становящееся менее абстрактным. Следовательно и подходы к работе с этим абстрактным понятием могут отличаться от всех остальных инженерных дисциплин. Достаточно того, что в ИТ, в отличии от вышеназванных дисциплин буквально по каждому подходу/стандарту/практике есть горячий спор, сторонники и противники и доводы из разряда религии. Один КлинКод чего стоит - с одной стороны фанатичные клинкодеры которые готовы тратить лишнее время на эфемерную чистоту кода которую и измерить то нельзя, с другой стороны оптимизаторы с бенчмарками которые на деле могут показать как без клин кода то же самое работает в 20 раз быстрее. Ну и назовите мне хотя бы одну отрасль инженерии, где бы такое существовало. Да, локальны срачи есть много где, но так чтобы ПО КАЖДОМУ ВОПРОСУ - такое есть только в IT как мне кажется, и обсуловленно это именно абстрактностью информации и невозможности выработать один универсальный подход.
Надо ли ультимативно всех заставлять TDDить? Пожалуй нет. Стоит ли отговаривать апологетов? А зачем? Продукты пишутся, результаты есть, бизнес доволен - так пущай пишут свои тесты хоть целыми днями
Ну не знаю. Можно, конечно, пойти по принципу китайской компартии: "...пусть расцветают все цветы"... Я в этом смысле сторонник не давать котлу беспорядочно вариться в надежде что из холиваров выйдет рано или поздно каменный цветок - а заимствовать в нашу (относительно молодую) инженерную дисциплину лучшие практики из других отраслей. И уж только там, где мы такие особенные что лучших практик нет - начинать изобретать велосипед...
И да, наверное у меня более "железячное" отношение к ИТ, просто в силу того, что я его застал на более ранних стадиях. Одну и ту же задачу принципиально можно решить жестко соединив логические элементы паяльником, или прожигая перемычки физически в микросхеме, или делая это во флэш-памяти (ПЛИС), или записать программу в RAM для ЦП общего назначения... Поэтому я не вижу прямо вот принципиальных отличий нас от инженеров-электронщиков...
И я бы поспорил о нулевой стоимости тестов в TDD. Если вы работаете по жесткому ТЗ, и у вас не меняются требования к системе - наверное да. В противном случае - тесты это тот же код, который имеет стоимость поддержки. В этом смысле, избыточное тестирование для бизнеса так же плохо, как и недостаточное.
Не вдаваясь в дискуссию - давайте просто посмотрим на другие отрасли, и с удивлением обнаружим, что НИКТО (ни в авиации, ни в медицине, ни где либо еще) - не пытается делать тестовые стенды под еще не готовое изделие!
Простите, но нет. Более того, я слышал например мнение, что советская ракета Н-1 не полетела (в отличие от Аполлона) в частности и потому, что не было денег на тестовые стенды например для двигателей, и их не удалось достаточно отработать до полета.
То есть, их не просто строят, но они зачастую являются решающим фактором успеха или неудачи проекта.
Первые серии двигателей Кузнецова для Н-1 - это как раз пример non-testable системы: двигатель одноразовый, после прожига выбрасывается. В "Ракетах и людях" Б.Чертока описывается процедура - прожигают из партии половину двигателей на стенде, и если они отрабатывают штатно, то остаток партии идет на сборку ракеты (в предположении что оставшиеся изготовлены из одних и тех же материалов по одному технологическому циклу - и, следовательно, тоже не откажут). По факту, не взлетело... Вторая серия двигателей была уже многоразовая и позволяла ставить на ракету двигатель прошедший стенд и переборку. Но было поздно...
Но при этом - никто в здавом уме и твердой памяти не сказал ни Королеву/Мишину, ни Кузнецову, что еще до создания двигателя надо сделать стенд для его прожига, и двигатель делать исключительно с условием совместимости с данным стендом. Конструкция и режимы работы двигателя определялись исключительно носителем, под который его делали. А потом уже под получившийся двигатель делали стенд (геометрию, крепления, систему подачи топлива/окислителя, гашения пожара, и т.д.).
Я историей Н-1 на самом деле несколько раз дожимал людей от бизнеса выделять ресурсы на тестирование. Уж больно показательная! Но еще раз - это не про то, что надо тест писать вперед кода, а что при написании кода надо предусматривать что он должет быть testable (ну и иметь ресурс реализовать эту testability - то есть время и деньги на тестирование).
Но при этом - никто в здавом уме и твердой памяти не сказал ни Королеву/Мишину, ни Кузнецову, что еще до создания двигателя надо сделать стенд для его прожига
Знаете что самое смешное? Что мнение о том, что не хватило ресурсов на стенды было когда-то высказано именно Мишиным. Сильно позже, но такой вывод он сделал.
Ну, задним числом это в принципе все признали. Что отрабатывать пусками ракету класса Н-1 оказалось и запредельно дорого, и скорее всего по деньгам оказалось бы дороже чем если бы работать со стендами. Но перечитайте мой пост - я целиком за то, чтобы тестировать юнит-тестами, интеграционными, и компонентными. Ручное тестирование, с моей точки зрения, это как раз попытка отработать ракету запусками с площадки...
Но в любом случае, нигде кроме программирования никто не пытается сделать сначала тестовый стенд, а потом изделие под него. Возьмем более близкую нам область - электронику. Да, разработчик обязан предусмотреть тестовые пятаки на плате, чтобы можно было к ним добраться через pogo-pins на стенде. Да, разработчик обязан предусмотреть JTAG. Да, разработчик обязан предусмотреть чтобы можно было отдельно проверить блок питания, а потом поставить перемычку и запитать всю схему (а не жечь ее при первом включении). Но сам тестовый JIG делается только после того, как утряслось расположение компонентов и рабочих разъемов, и сделали первый экземпляр. В ином случае - это же абсурд! У нас на плату компонент не встает, или надо дорожку переложить потому что выявилась проблема с электромагнитной совместимостью - а мы уже тестовый jig сделали, и теперь у нас не одна, а целых две проблемы... Я не спорю, что если есть время и деньги, можно хоть с первого дня проектирования написать все тесты - а потом по ходу разработки их переделывать. Но блин, никто в других инженерных дисциплинах так не делает! Не может быть чтобы все вокруг - дураки, а мы - самые умные...
Но в любом случае, нигде кроме программирования никто не пытается сделать сначала тестовый стенд, а потом изделие под него.
Если вы это все в смысле полезности TDD - то и вопросов нет. Меня слегка изначальная формулировка смутила, что стенды мол не делают. Делают же. Позже (в крайнем случае одновременно) с самим изделием. Раньше - вряд ли. Я бы сказал, что реальные стенды делают тогда, когда это осмысленно. Помнится, когда была широко известная авария Протона в прямом эфире, кто-то позже задавал вопросы, а почему это не проверили на стенде (это - в смысле перевернутый вверх ногами датчик). Ну так потому и не проверили, что стенд, способный покрутить туда-сюда ступень Протона слегка так дорого обходится.
Именно так! Нормальные люди стенды делают со сдвигом вправо относительно разработки изделия. А TDD в ее "чистом" понимании религиозными фанатиками - запрещает разработку изделия ДО того как вы сделали стенд для его тестирования. Что есть инженерный абсурд...
Я пытался понять, что именно заставляет их упарываться в тестирование таким образом - и пришел к выводу, что отсутствие культуры тестирования (а я еще пару лет назад видел выходящих из технического вуза программистов, которые были уверены что тестирование - это "...запустить программу и повводить в нее разные данные") - приводит к тому, что программа проектируется и кодируется способом, который исключает модульное тестирование - то есть программируется каша. Соответственно, если мы начинаем требовать сначала написать тест, а потом писать код - то такую кашу уже не напишешь - потому что иначе не будет теста, а ты обязан его написать до того как напишешь сам код... Я допускаю, что этот подход может быть применен во время обучения, чтобы через руки до студентов дошло, как надо писать программы. Но требовать TDD в нормальной производственной среде - oh, my!..
Я допускаю, что этот подход может быть применен во время обучения, чтобы через руки до студентов дошло, как надо писать программы.
Ну я где-то выше об этом же говорил. В принципе, попытка написать тест обычно приводит к лучшему пониманию того, что тестируемому компоненту нужно, есть ли у него состояние, как его создавать и инициализировать. Я ничего против такой активности на этапе проектирования не имею, она как правило полезна, студентам - так в особенности. А фанатизм - скорее вреден.
НИКТО (ни в авиации, ни в медицине, ни где либо еще) - не пытается делать тестовые стенды под еще не готовое изделие!
А разве там изделие считается готовым до прохождения тестов? По-моему, именно успешное прохождение тестов позволяет считать изделие готовым.
Кажется, вы неверно понимаете TDD. В TDD написание тестов это способ детальней формализовать требования.
Вы серьезно ?! Требования к ПО описывают внешние по отношению к системе требования. А поклонники TDD требуют писать тесты ДО написания любого производственного кода. И это уже никак не требования к системе - потому что никто извне не заставляет вас членить систему именно таким образом или выбирать именно такие алгоритмы для реализации. Это вы прибиваете намертво гвоздями к столу артефакты реализации своей системы. И если вам не повезло, и вы не угадали сразу с тем как надо было делать - то любой рефакторинг в этой прибитой к столу реализации - выливается в пот, кровь, время и деньги...
Мне кажется, или вы считаете, что TDD требует сперва написать все тесты к программе? В TDD просто перед реализацией какой-либо функциональности (например, добавление комментария) пишется тест. Он не требует писать горы сложных тестов до реализации.
По-моему, вы что-то другое оспариваете, а не TDD или судите о нём исключительно в рамках своей специфики. Вполне возможно, что в каких-то областях этот метод совсем неприменим, но в каких-то он полезен.
Но ведь TDD - это тест Driven (!) разработка, не ? По канонам этой религии, нельзя садиться и писать метод внутри класса, не написав предварительно тест. И если вы будете писать тесты ad-hoc, то у вас будет тест на метод a(), потом тест на метод b() который вызывает "a", потом на c() который вызывает "a" и "b", и так далее... Если же вы хотите избежать дублирования тестового функционала - то, извините, вам придется хотя бы в голове написать тесты, чтобы решить какие из них и в какой части следует сократить...
Собственно, тесты здорового человека тем и отличаются от тестов курильщика, что пишутся ПОСЛЕ того как функционал (или его часть) уже разработаны. И вы, имея перед глазами уже существующую структуру - решаете, что именно в рамках имеющегося бюджета и денег вы закроете тестами. То есть, соблюдается четкая иерархия ценностей как во всех нормальных инженерных дисциплинах: разработка драйвится требованиями, тесты драйвятся техническими решениями разработки.
единственный способ формализовать требования - это (внезапно!) формальная спецификация
по определению, тест это поиск контрпримера к конкретному юзкейсу в конкретном контексте. фаззинг и property-based будут чуть-чуть, на полшишечки лучше, чем полностью врукопашную написанный тест, но глобально тесты даже с покрытием 100% ничего не гарантируют
Если бы тесты писались постановщикам - да, это аргумент того, что это формализация требований. Но тесты пишутся разработчиками. Как они поймут проект- это одному богу известно, а они пишут тесты именно на основании того, как ОНИ поняли проект, как поняли проект РАЗРАБОТЧИКИ, а не проектанты.
С точки зрения фронтенда мне не нравится, что тестирование не встроено в платформу. Все возможные jest/vitest/mochat cypress/playwright и т.п..
Каждый проект нужно настраивать по своему, что-то по дороге может сломаться, или не запуститься как надо на windows/macbock.
Потом в один момент тесты становятся гигантскими, занимают на ci/cd больше времени, чем сборка самого проекта.
Локально без плагинов в режиме watch не запустишь. А если запустишь, то оно сожрёт половину процессорных мощностей.
И получается, что тестировать tdd имеет смысл только очень маленькую часть (логики). Самое важное - не тестировать то, что не надо. Всякие render функции и т.п.
удивительно с каким упорством автор избегает тему Хрупкости тестов
вы наверно в курсе что любой рефакторинг потенциально может поломать вообще все тесты
вот про что нужно писать статьи.
а пока вы пели оды Мартинам и Бекам они уже давно открестились от ТДД и сами признали ТДД несостоятельным
Test-Driven Development: как полюбить модульное тестирование