С чего начать изучение написания TDD — тестов?

Question

[bagerman]

Всем привет!

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

Что это вообще такое и каких писать?
Приведите, пожалуйста, пример этих тестов как их пишут.

Спасибо.

Answer 1

[Сергей Протько]

нужно писать TDD тесты.

Нет, нет такой вещи как "TDD тесты". TDD это одна из методик экстремального программирования (XP). Вам уже привели ссылку на книгу Кента Бэка на эту тему (к слову крайне рекомендую)

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

- Красный - перед тем как написать код, мы должны написать тест который ломается (обычно в консоли сломанные тесты подсвечиваются красным). Согласно этой методологии писать код вы должны строго тогда, когда у вас есть сломанные тесты. Если сломанных тестов нет, то и код писать не нужно.
- Зеленый - когда вы получили красные тесты, вы должны максимально быстро дописать код так. что бы тесты были зелеными. Скажем если вы написали тест который ожидает от функции, что она вернет строку "foo" то в коде у вас должно быть не больше чем сама функция и вывод строки "foo". Как только мы этого добились мы либо рефакторим, либо добавляем еще красных тестов что бы потом дописать код. Конечно настолько примитивные вещи делать по такому циклу избыточно, и у Кента Бэка описывается понятие "длины шага", то есть сколько работы мы можем делать на каждом этапе. Вы всегда должны подключать здравый смысл словом.
- Рефакторинг - на предыдущих фазах мы не загонялись о том насколько наш код красив, насколько мы соблюдали принципы DRY и т.д. так что это фаза отчистки кода. Мы можем делать ее на каждой итерации, а можем раз в пару часов, но важно делать это как можно чаще. На этом этапе мы устраняем дублирование как в коде приложения так и в тестах. Важно отметить что хорошей мыслью будет не рефакторить одновременно и код и тесты, ибо у нас должен быть источник правды. Если мы почистили тесты и при этом они начали фэйлиться, то значит мы что-то сломали пока числити. И наоборот. А если менять и то и то между запусками тестов то не понятно кто виноват.

Обычно TDD практикуют используя unit-тесты (что логично, ибо они выполняются достаточно быстро что бы выполнение тестов не заставляло нас заваривать чай), что подразумевает собой то, что мы тестируем один юнит (один класс или объект), а все его зависимости должны подменяться на моки (фэйковые объекты, которые нужны что бы проверить как наш объект взаимодействует с другими, об этом тоже много написано). Но никто не запрещает использовать интеграционные/функциональные тесты и при этом практиковать TDD (так например делают чуваки практикующие BDD), а Кент Бэк это дело называет ATDD.

Собственно TDD дает нам следующие преимущества:
- вы не тратите время на проектирование системы в микроскопических масштабах, это эволюционный подход, архитектура приложения постоянно меняется и эволюционирует вместе с требованиями. Все требования формализуются в виде тестов.
- код всегда покрыт тестами (пусть и не на 100%, обычно хватает и 20% что бы можно было жить, все зависит от сроков жизни проекта и требуемого уровня надежности)
- если вам становится трудно писать тесты (например много зависимостей, сложно мокать) - то это должно навести вас на мысль о не правильной архитектуре и инициировать более глубокий рефакторинг. А при наличии тестов это не так уж и страшно.
- необходимость покрывать тесты увеличивает потребность в соблюдении всяких принципов типа SOLID и т.д. так как иначе мы начинаем писать тесты очень не эффективно и опять же возвращаемся к тому что с архитектурой что-то не так.

updated

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

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

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

Comments

[Oxoron]

Сергей Протько, последние преимущества можно отнести к недостаткам.

[bagerman]

Спасибо

[Сергей Протько]

Oxoron: это как так? Можете раскрыть мысль? Как по мне это одна из самых сильных сторон TDD.

[Oxoron]

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

"Необходимость покрывать тесты увеличивает потребность в соблюдении всяких принципов типа SOLID". Вы исходите из того, что соблюдение SOLID - благо. Если предположить, что SOLID не несут значимой пользы - мы вынуждены руководствоваться лишними принципами при разработке архитектуры\программы, что зло.

В целом, Ваш ответ достаточно точный. Не хватает лишь двух моментов: недостатков TDD и области применения методики. За фразу "(пусть и не на 100%, обычно хватает и 20% что бы можно было жить, все зависит от сроков жизни проекта и требуемого уровня надежности)" отдельный респект. Неофитам стоит высекать её в камне, чтоб запомнили.

[Сергей Протько]

Oxoron:

Тратим время на изменение системы. Поскольку рефакторить без тестов ненадежно и страшно - тратим много времени.

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

Если же мы работаем с кодом, состоящим из спагетти

Вы видимо описываете ситуацию, когда у нас уже есть готовая система и мы хотим перейти на TDD. Ибо спагетти и TDD сложно сочитаются. Опять же у Кента Бэка в книжке описываются мысли как быть в такой ситуации. Решение - тесты уровня приложения, то есть функциональные или интеграционные тесты. Если у вас задача отрефакторить код, то да, TDD тут не сильно поможет если код изначально небыл написан с применением TDD (ну или хотя бы без нормальных юнит тестов, которые опять же исключают вероятность совсем уж плохого кода). А если у вас задача добавить функционал - то тут можно просто покрыть сначала часть системы тестами уровня приложения и затем дописывать юнит тесты по неоходимости. Со временем наша система станет преображаться и все станет хорошо.

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

недостатков TDD и области применения методики.

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

А вот по поводу области применения - соглсен. Следовало написать.

Answer 2

[Виталий Витренко]

Экстремальное программирование: разработка через т....

Comments

[Сергей Протько]

Еще есть лекции Дяди Боба на эту тему, но у него более радикальные взгляды.

Answer 3

[ТыжСисАдмин]

habrahabr.ru/hub/tdd

Comments

[Максим]

Блеснул умом

Answer 4

[Oxoron]

Тут рецензия хорошей книги "Art of Unit Testing", плюс, несколько ссылок на доп-материалы. Книга не только расписывает плюсы-минусы тестов, но и объясняет, как лучше внедрять TDD в команды\проекты.

Answer 5

[abcd0x00]

TDD на первый взгляд выглядит хорошо, но потом начинается свистопляска.

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

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

Это выглядит так:
Однажды ты хочешь написать классную программу, которая делает это, это и это. Ты, находясь под впечатлением от её возможностей (в воображении), продумываешь все её компомненты в голове до мельчайших подробностей и готов броситься в бой. Уже видишь эти данные, полученные из неё в результате, и уже лазишь по ним, применяя там-то и там-то.

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

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

Но это ещё не всё. Однажды наступает момент, когда программу надо не отрефакторить, а кардинально изменить. (А это самое важное - вовремя убрать какой-нибудь тупик, к которому всё идёт. Если этого не делать, программа будет представлять из себя конгломерат из затычек - и пример уже есть, десятой версии.) И становится просто жалко стирать тесты, которые к новой версии вообще не подходят.

Comments

[Сергей Протько]

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

Как это понимать? Вы месяц тупо писали тесты? Это как бы идет в разрез с TDD если что.

продумываешь все её компомненты в голове до мельчайших подробностей

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

Уже видишь эти данные

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

Но надо соблюсти правила TDD

Один мой коллега не так давно сетовал на то что kanban это весьма неудобная и не дает никакого профита. В разговоре с ним оказалось что из 3-х правил kanban-а ребята выполнили только одно, и два других просто проигнорировали, зато добавили десяток своих правил (вроде как долго таск может быть в in progress). Словом... сетовали на то что правила канбана отстой и при этом ни разу не выполняли этих правил и даже не подозревали об этом.

Я это к чему, можете сформулировать эти самые правила TDD?

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

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

И становится просто жалко стирать тесты, которые к новой версии вообще не подходят.

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

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

[abcd0x00]

Сергей Протько:

Как это понимать? Вы месяц тупо писали тесты? Это как бы идет в разрез с TDD если что.

Не идёт оно вразрез. Просто вместо одного теста ты пишешь сто.

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

Ахаха, а если они ломают всю программу? Ты пишешь тест, пишешь код, а потом оказывается, что это всё не нужно, потому что вообще не подоходит ко всему остальному. Сначала программу всю надо в голове представить, иначе что-нибудь вылезет в процессе, а потом придётся выбирать, либо писать всё заново, либо оставлять халтуру и делать вид, что так и должно было быть.

Используя TDD вы все это видите еще на этапе написания тестов

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

проблемы открываются раньше

Проблемы могут появляться из пустоты. Собираешься, например, добавить новую фичу (необходимую), а она не подходит к тем фичам, которые уже есть. Значит, тебе надо их перестроить, чтобы её включить. А они обложены тестами, которых по количеству кода больше, чем этих фич, раз в десять.

Скажем покрывать тестами код, который должен только заменить данные (по сути сеттеры, хотя я сеттеры аля setSomething не пишу).

Да никто не пишет покрытие для элементарных методов.

Я это к чему, можете сформулировать эти самые правила TDD?

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

Этого не может быть, если вы практикуете TDD.

Не, я понимаю, что в твоих правилах писать по одному тесту, потом писать его прохождение, потом делать рефакторинг, а программы ты не меняешь, потому что пишешь не для себя, а чисто продал и забыл, а там хоть трава не расти.
У меня по-другому. Я сначала пишу тесты (причём только самые необходимые), обкладывая всю функциональность компонента, потом один раз пишу отрефакторенный код, писать говнокод я как-то не люблю, потому что для меня важна чистота кода, так как это не даёт в нём спрятаться ошибке. А потом начинаю другой компомнент по той же схеме. Компоненты друг про друга не знают.

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

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

[Сергей Протько]

abcd0x00:

Не идёт оно вразрез. Просто вместо одного теста ты пишешь сто.

Ну и зачем так делать? Можно например написать не 1 тест а 10, я так иногда делаю когда более-менее уверен в том что как должно быть. Но 100 тест кейсов... это явно перебор. Less is more, как говорится.
Ты пишешь тест, пишешь код, а потом оказывается, что это всё не нужно, потому что вообще не подоходит ко всему остальному. Вопрос мативации и скуки к слову у Кента Бэка хорошо раскрывается.
На высоком уровне представление в голове должно быть, это да, но на уровне интерфейсов - не обязательно. Для этого мы и пишем тесты, что бы оформить требования. Тут еще все зависит от того как писать код. Скажем есть концепция "единого языка", когда ты просто берешь требования и переписываешь их в виде теста максимально близко к исходной формулировке. В этом случае написание теста не требует сильно много времени, так как мы берем требования клиента и просто их записываем в тестах, а интерфейс формируется из терминов клиента, которые определяются в требованиях. В голове такие штуки довольно сложно держать, особенно если предметная область не привычна для разработчика.

Речь идёт про реальные данные, которые нужны, а не про составленные.

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

а она не подходит к тем фичам, которые уже есть.

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

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

У Дяди Боба скажем довольно жесткие правила:

- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

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

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

Требования к моим проектам меняются по паре раз в неделю. Это обычное дело. А еще есть суппорт приложений, новые версии, новые итерации... Я совру если скажу что всегда придерживаюсь этих правил, или там... всегда практикую TDD, но все же стараюсь придерживаться этого. Скажем мой тестовый фреймворк который я использую для юнит тестирования имеет средства кодогенерации (добавление несуществующих методов например), удобный сахар для моков и тд. И практиковать при таком раскладе TDD становится довольно удобно. Да и юнит тестами у меня покрывается только слой бизнес логики и ооочень редко инфраструктурный слой. Так что я так же пишу только самые необходимые тесты, негативные сценарии и прочее, что подкидывают QA, добавляются и хэндлятся уже позже.

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

Так программа или UI? У интерфейса добавился еще один аргумент? Ну... я вообще стараюсь избегать интерфейсов методов с более чем двумя аргументами, все дробится на VO и объекты-конфигурации и т.д. Так же я люблю для каких-то сложностей пихать через дабл диспатч сервисы в методы моих бизнес-объектов.

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

[abcd0x00]

Сергей Протько:

Ну и зачем так делать? Можно например написать не 1 тест а 10, я так иногда делаю когда более-менее уверен в том что как должно быть. Но 100 тест кейсов... это явно перебор.

Это делается затем, что если требования меняются к коду, чтобы переписать только тесты под новые требования, а код, выполняющий старые, не надо было выбрасывать. По тестам всегда видно, что "делает" этот несуществующий код, и так ты контролируешь его функции. То есть кода нет, но по тестам видно, что он делает и насколько он готов. Почему не 10, потому что 10 - мало. Ты, может быть, имеешь в виду большие десять тестов, но тесты нельзя делать большими, потому что это такой же код - просто получится каша-малаша.
10 тестов в моём понимании - это тестовый класс, в котором десять методов.

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

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

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

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

У Дяди Боба скажем довольно жесткие правила:

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

И ни слова о интерфейсах и прочего.

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

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

Значит, там ошибки. Ты просто так не перекинешь эту инфраструктуру в другие программы, потому что тестов нет. А где гарантия, что они правильно работают? Правильная работа в каком-то контексте не гарантирует правильной работы во всех контекстах.

Так программа или UI?

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

все дробится на VO и объекты-конфигурации и т.д. Так же я люблю для каких-то сложностей пихать через дабл диспатч сервисы в методы моих бизнес-объектов.

Да, главное, что-нибудь посложнее написать, чтобы потом никто в этом не разобрался. :)

[Сергей Протько]

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

Ну предположим я понимаю, но... Например в моем случае мы минимум раз в две недели, а то и чаще выкатываем билды клиенту. То есть с момента старта проекта через 2 недели он уже должен что-то увидеть, пощупать. При таком раскладе делать месяц только тесты это не продуктивно. От реализации бэкэнда могут зависить другие компоненты и т.д. Да и когда мы пишем только тесты мы не можем рефакторить их, так как нет кода, нет возможности проверить что мы случайно не поломали эти тесты. Словом... в реалиях всяких там скрамов/канбанов подход когда пишут сразу сотню тест кейсов это как-то странно. Даже QA тесткейсы/чеклисты формируют для своей работы в процессе разработки а не до нее.

В тестах-то они выдумываются.

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

А ты когда-нибудь поднимал версии программ?

Да, это бывает обидно дропать фичу над которой ты сидел 3 месяца, но от этого никуда не уйти. Вообще с учетом того что весь код в VCS хранится, удалять что-то не так страшно. Жалко только потраченного времени но это быстро проходит.

Там они (америкосы) предлагают оставлять говнокод до рефакторинга

Вот я пытался бороться с говнокодом, вводили кодревью и прочее.... и в итоге я всеравно пришел к тому что в этом нет никакого value, пусть себе будет до рефакторинга. Работает и ладно. На эту тему мне очень нравится высказывание аля "everybody poops but doing it in one place". То есть, говнокод допустим если он закрыт красивым интерфейсом, изолирующим реализацию извне. Тогда рефакторинг не будет болью и его можно отложить.

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

Ты просто так не перекинешь эту инфраструктуру в другие программы

Инфраструктура покрыта функциональными/e2e тестами. Ты же не будешь покрывать тестами реализацию репозитория для базы данных, мокать query builder-ы и т.д. Это тупо, скучно, занимает много времени и несет мало ценности. Замокать репозиторий - да, замокать зависимости репозитория - не выйдет нормально. С точки зрения оптимизации времени разработки это наиболее выгодный подход. Бизнес логика не так часто меняется на уровне интерфейсов объектов и да даже если она меняется, это никогда не приносить каких-то мегабольших изменений вроде "блин надо добавить еще аргумент в тысячу тесткейсов", обычно изменение сигнатуры одного метода затрагивает только тесты, которые этот метод юзают, а это не может быть много тестов. Обычно такие изменения разве что у репозиториев бывают.

Повторюсь, у меня есть 3 слоя:
- domain layer - сущности, vo, сервисы. Все это покрыто юнит тестами. Чем сложнее бизнес логика, там удобнее применять TDD для разработки. Этот слой редко подвержен изменениям на уровне интерфейсов и т.д. А если интерфейсы и меняются, то затрагивают не так много тест кейсов, так как все максимально независимо друг от друга.
- application layer - сервисы уровня приложения, задача которых принять DTO запроса, дернуть другие сервисы что бы регламентировать флоу, и сформировать DTO ответа. Этот слой можно покрыть юнит тестами но это довольно скучно, так как по сути сам по себе этот слой не выполняет логику, он лишь регламентирует последовательность действий. Этот слой часто меняется и удобнее покрывать его интеграционными/функциональными/E2E тестами
- UI layer - в моем случае это довольно тонкая прослойка, чья задача состоит только в том что бы сконвертить запрос (обычно это http запрос) в DTO в нужном формате. У нас могут быть разные версии API или еще чего, да и код там обычно довольно тупой - замэпить объект на объект. Так же покрывается функциональными/E2E тестами.
- Слой инфраструктуры, он сквозной и реализует все интерфейсы, объявленные на предыдущих слоях. Например Domain layer регламентирует интерфейс репозитория где хранятся данные, а этот слой его реализует. На 90% этот слой - это фреймворк и/или сторонние библиотеки который мы используем, он уже покрыт юнит тестами. Оставшиеся 10% того что пилем мы - функциональные тесты.

Да, главное, что-нибудь посложнее написать, чтобы потом никто в этом не разобрался. :)

Да ладно, это может звучит сложно, по факту это все очень легко и красиво поддерживать.

[bagerman]

Ребята разошлись не на шутку)

[abcd0x00]

Сергей Протько:

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

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

Повторюсь, у меня есть 3 слоя:

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

Жалко только потраченного времени но это быстро проходит.

При TDD тестового кода по количеству больше программного в десять раз. И жалко терять его, а ведь его никуда больше не пристроишь, ни в одну программу, тогда как из программного кода ещё можно взять что-то полезное.

bagerman: Ну, надо же проявить минусы TDD, про них редко пишут, а они есть.

[Сергей Протько]

То есть сами тесты фиксируются, их нельзя менять/удалять, потому что они контролируют этот непричёсанный код.

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

- чуть чуть поправили код
- прогнали тесты и убедились что ничего не сломали
- чуть чуть подправили тесты
- прогнали тесты и убедились что вы не сломали ничего в тестах, в этом случае гарантом того что все работает выступает ваш код

Ну и так до бесконечности. Разбиение процесса на маленькие итерации позволяет вам менять код и тесты чаще, чем у вас могут меняться требования. Тесты и код выступают взаимным гарантом того что все работает. При таком подходе расходы на поддержание тестов значительно сокращаются. А когда вы месяц писали тесты без кода, вы выходит этот месяц и рефакторить их не могли.

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

Я понял, что там почти ничего нет, деланного с нуля.

Ух... как все запущено...

[Сергей Протько]

abcd0x00:

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

У вас выборка не репрезентативна. Я понимаю еще в два раза, но в 10... Опять же TDD не регламентирует вам сколько у вас должно быть покрыто тестами кода, 10% или 100%. Когда у вас тестов в 10 раз больше чем кода, это повод задуматься. Либо у нас мегакритичная часть приложения которая должна учитывать все позитивные и негативные сценарии на всех пограничных случаях, либо большая часть наших тестов бесполезна для нас.

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

[abcd0x00]

Сергей Протько:

- чуть чуть поправили код
- прогнали тесты и убедились что ничего не сломали
- чуть чуть подправили тесты
- прогнали тесты и убедились что вы не сломали ничего в тестах, в этом случае гарантом того что все работает выступает ваш код

Так а где тут разработка через тестирование? Это просто покрытие кода тестами, тогда как при TDD код управляется тестами, а не просто ими покрывается и проверяется.

Ух... как все запущено...

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

У вас выборка не репрезентативна. Я понимаю еще в два раза, но в 10... Опять же TDD не регламентирует вам сколько у вас должно быть покрыто тестами кода, 10% или 100%.

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

Когда у вас тестов в 10 раз больше чем кода, это повод задуматься.

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

Либо у нас мегакритичная часть приложения

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

которая должна учитывать все позитивные и негативные сценарии на всех пограничных случаях

Да и без этого тестов навалом, потому нюансов бывает дофига и больше.

Вообще доводы в духе "жалко удалять" это смешно.

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

[Сергей Протько]

abcd0x00:

Так а где тут разработка через тестирование?

Это конкретно фаза рефакторинга. Разработка через тестирование в том что вы не должны писать код пока у вас нет красных тестов. Фаза рефакторинга же является одной из основной, так как именно тут мы добиваемся какой-то чистоты код. А все что до этой фазы это та самая PoC реализация.

Первый признак того, что привести нечего особо.
Про NDA слышал? К сожалению я не могу предоставлять исходники своих проектов. А что-то на гитхабах посмотреть можно.

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

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

Да и без этого тестов навалом, потому нюансов бывает дофига и больше.

Опять же у вас есть пример?

Ну, у тебя-то, походу, этим тестировщики занимаются

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

[Сергей Протько]

abcd0x00: короче почитайте Кента Бэка, либо переведем дискуссию в личку. Мне уже немного надоело цитаты расставлять)

[abcd0x00]

Сергей Протько:

Опять же у вас есть пример?

Вот функция из одной строки:
func(a, b) { return a + b }
Вот тесты:

func(1, 2) == 3
func([1], [2]) == [1, 2]
func([], []) == []
func([1], []) == [1]
func([], [2]) == [2]

Ещё можно напридумывать; главное, чтобы они покрывали случаи где это всё может выпасть.
Итого, на одну строку приходится множество тестов.

Мне уже немного надоело цитаты расставлять)

Ну да, кривовато они ставятся, потому что кое-кто не знает про предпросмотр. ;)

[Сергей Протько]

abcd0x00:

Вот тесты:

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

func add(a int, b int) int {
   return a + b; 
}

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

Но опять же, как было бы если бы вы практиковали TDD:

- написали тест
func(1, 2) == 3
- написали код, потому что тест зафэйлен, нет такой функции
func([1], [2]) == [1, 2]
- тесты зеленые, ничего не надо писать

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

А теперь представьте себе такой тест

describe('comments', () => {
    // ...
     if('allows to make abuse on comment only once for user', () => {
        commentAlreadyHasAbuses(1);
        expect(this.comment.isVisible()).to.equal(true);
        this.comment.abuse(this.createUser());
        this.comment.abuse(this.createUser());
        expect(this.comment.isVisible()).to.equal(true);
    });

    it('hides after abuse from author of the post', () => {
        this.comment.abuse(this.postAuthor);
        expect(this.comment.isVisible()).to.equal(false);
    });

    if('hides after 3 abuses from different users', () => {
        commentAlreadyHasAbuses(2);
        expect(this.comment.isVisible()).to.equal(true);
        this.comment.abuse(this.createUser());
        expect(this.comment.isVisible()).to.equal(false);
    });

    function commentAlreadyHasAbuses(amount) {
       for(let i = 0;i<amount;i++ {
           this.comment.abuse(this.createUser());
       }
    }
})

это более-менее реальный пример. Да, кода выходит раза в полтора больше чем в реализации метода abuse моей сущности, но это довольно тупой код. + я думаю его можно сократить. Но это реальные кейсы. Причем добавлялись они не сразу сходу. Скажем сначала была возможность абьюзить комментарии. Потом добавили правило что после определенного количество жалоб комменты должны прятаться. Потом правило для автора. Релизы раз в неделю и все такое. Инкрементая разработка. Ну и да, тест не копипаста, выдуманный. В оригинале он на phpspec.

потому что кое-кто не знает про предпросмотр. ;)

У комментариев есть предпросмотр? Предпросмотр есть только у ответов и вопросов. Да и почему нельзя было добавить markdown я не понимаю.

[abcd0x00]

Сергей Протько:

Далее ваши тест кейсы по сути покрывают функционал оператора + языка на котором вы пишите, в этом не особо много смысла.

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

Да и почему нельзя было добавить markdown я не понимаю.

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

[Сергей Протько]

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