Previous Entry Share Next Entry
2016-01

про test-driven development

я вот люблю гнать на TDD. много лишней работы, false feeling of reliability, fragile tests, то-се.

но вот мне внезапно дошло, что гоню-то я далеко не на весь TDD.

гоню я конкретно на initial test suite creation и maintenance.

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

Век живи, век учись, блин. К вопросу о том, зачем нужно разделение труда.

This entry was originally posted at http://wizzard.dreamwidth.org/477974.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
justy_tylor November 13th, 2016
Если тесты приходят со спекой, то это не TDD, т.к. ты не создаёшь тесты до кода, они просто приходят извне.

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

insanegigolo November 13th, 2016
Раз мы всё-таки софтвар инжинигринг, надо у любой медали две стороны смотреть. Даже если это старинное дерьмо или новомодный хайпшит.

osdm November 13th, 2016
Весь вопрос в уровне тестов. Писать тесты на каждый метод - в большинстве случаев маразм. Писать тесты на функциональность, видимую снаружи (не обязательно на UI) - это очень гуд. Тогда лишней работы не так много (все равно ведь свой код на чем-то и как-то тестировать надо, и написать по этому поводу тесты не так сложно), и feeling of reliability вполне себе true.

vit_r November 13th, 2016
Пардон, это acceptance test и ничего общего с "сначала сделай тест, а потом думай" нету.

nponeccop November 13th, 2016
Тут надо с терминами сначала договориться. Не любое использование тестов является TDD. В частности, acceptance, integration и regression testing - это не TDD, мы кажется это даже обсуждали.

TDD - это "технология выращивания" программ. Если есть актуальная спецификация в принципе - это уже "технологии проектирования" программ.

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

wizzard0 November 14th, 2016
> если б сеньоры не брали в руки в этих случаях вайтборд и салфетки
Сеньоры и ситуации бывают разные.

См. http://sim0nsays.livejournal.com/3986.html :)

nponeccop November 14th, 2016
Пусть расцветают сто цветов, я не возражаю (а потом - расстрелять).

netch80 November 30th, 2016
> и вот, если смотреть на это с другой стороны (тест сюиты пишет разработчик протокола/спеки, а не реализации, а поддерживают их тестеры), а я делаю реализацию - тогда да, внезапно становится круто, удобно и все такое.

Это не TDD. Это BDD - behavior-driven development, к которому даже есть специальные DSL писания тестов.
И я тоже против него (в отличие от TDD) не протестую.

  • 1
?

Log in

No account? Create an account