Комментарии 65
Имея (прим. given — данное) какой-то контекст,
В голову приходит пара выражений из школьно-институтского описания вводной ситуации в задаче/теореме — «Дано» и «Положим».
FDD это вообще не разработка, это привод гибких дисков!
(/сарказм)
Но тогда таким программистам и тесты не нужны, и все прочие методологии, они сразу пишут готовое приложение, а архитектура у них рождается «на кончике пера».
На картинке тем временем некий TTD вместо TDD
BDD — это очередной велосипедный язык программирования, читать код на котором точно так же никто хочет. Большинство языков программиорвания используют ключевые слова естественного языка и мимикрирует под него грамматически. Но чем более язык формален, тем меньше с ним хотят сталкиваться не программисты.
Не могу согласиться с вами, поскольку BDD вовсе не язык программирования. Это методология. Поэтому ваш аргумент не уместен.
Это методология создания и поддержки языка программирования.
Нет. Это методология, т. е. подход к разработке. Так же как и TDD не является подходом к созданию языка программирования, так и ваше определение BDD неверно.
Вы вероятно имеете в виду Gherkin. Но это частный случай, и ваша критика, таким образом относится к конкретной реализации, и не стоит её эстраполировать на всю концепцию, ведь теоретически реализации могут быть любыми, более или менее формальным, с разной долей эвристики, и какие угодно.
Ваш изначальный аргумент, я признаться до конца не понял, могли бы его развернуть в примерах?
BDD неудобен хотя бы тем, что требует привлечения специалистов тестирования уже на этапе проработки требований, а это удлиняет цикл разработки.Привлечение тестировщиков на стадии проработки требований удлиняет цикл разработки только в одном случае — когда этапа тестирования нет. В любом другом варианте чем раньше вы привлечете специалистов по тестированию, тем проще и быстрее будет проходить разработка и последующее тестирование проекта.
BDD дорог и неудобен исключительно тем, что его нужно поддерживать — переводить тесты с естественного языка в код. Это очень не слабый оверхед и выгодно это только в случае когда сценарии пишет заметное количество менеджеров. BDD — это инструмент кооперации который позволяет добавить в цикл разработки менеджеров и аналитиков если им больше нечем заняться. Обычно же после первого восхищения у всех этих людей находится уйма дел которые нужно делать еще вчера и никаких тестов вы от них не дождетесь.
Вы правда думаете, что значительно количество менеджером смогут написать непротиворечивые сценарии? С этим и программисты-то не всегда справляются даже водиночку.
Нет, на самом деле есть еще один кейс когда BDD может пригодиться: он может упрощать задачу отдела продаж добавляя еще одно умное слово к заклинанию которым продажники будут зачаровывать клиентов. Но в таком варианте BDD совершенно необязательно поддерживать и развивать, его достаточно просто иметь где-то в уголке и сдувать с него пыль раз в месяц.
BDD дорог и неудобен исключительно тем, что его нужно поддерживать — переводить тесты с естественного языка в код.
Мне всегда казалось, что BDD удобен как-раз тем, что заставляет сначала более-менее человеческим языком описать сценарий, а код теста получается уже как следствие редактирования сценария программистом. И что важно — до программирования кода реализации.
Вот в более-менее основной затык. Слишком менее, чтобы бизнес его писал, и слишком более, чтобы его писали программисты.
По поводу первого — соглашусь полностью. Ключевое, кстати — отсутствие слова "должен" и наличие слова "удобен".
По второму пункту — я, видимо, не верю в методики как в единственно правильные алгоритмы поведения, дающие гарантированный результат. Я, даже в инструктаже компьютера не верю в единственный универсальный алгоритм, что уж говорить о сообществах.
Для меня BDD — одна из удобных эвристик, ценность которой не самодостаточна, но может быть очень высокой в каком-то конкретном случае.
Т.е. если прописанный программистом по такой схеме сценарий (или несколько) поможет бизнесу увидеть свои же требования в более чистом и понятном виде — уже хорошо. Есть шанс найти общий язык.
Если получится договориться и пере(на)писать большую часть важных моментов в таком виде — отлично! Тем более, что, как бонус, программист, отредактировав и вернув требования на согласование взаимного понимания с заказчиком, фактически уже написал и код для проверки этих требований.
Так что и со вторым пунктом соглашусь, но замечу, что "договоренности" для людей, а не люди для договоренностей.
Я год работал в компании, которая за 5 лет своего существования по технологии PDD выпустила несколько неплохих, но к сожалению, локальных продуктов. Реальность правда взяла своё и после ухода самого крупного заказчика, компания не смогла остаться на плаву и пару лет назад закрылась. Отчасти и потому, что PDD привело в какой-то момент к срыву сроков на полгода.
Основные постулаты:
Инкостыляция — сокрытие смысла костылей путем неоставления комментариев. Если любой разработчик может изменить твой костыль — это небезопасно и вы должны всеми способами этого избегать.
Наследование костылей — здесь всё ясно. Если вы до сих пор не выделили костыли в иерархию и не написали своей библиотеки костылей — вы ничего не знаете про CDD.
Поликостылизм — принцип написания костылей, которые выглядят одинаково, но решают разные проблемы. Идеальный костыль, который можно скопировать в другое место и он исправит другую проблему.
А как же SDD StackOverflow-Driver-Development?
TDD — Type Driven Development
Можно TypeDD. Т.е. все, кто пишет на языках со строгой статической типизацией, уже ее используют?
Нет. Если начинаете писать исполняемый код, пока не опишите все типы, то не используете.
На качестве продукта отражается наличие сеттеров в принципе. :) Шутка с долей шутки :(
потому что все равно нужно покрывать юнит-тестами то, что обычно не надо покрывать, например сеттеры.
Мне кажется из TDD этого не следует. Т.е. сеттеры обычно покрываются в любом случае но не специально предназначенными для этого тестами. Что с TDD что без него.
Если у вас обычный сеттер без логики — вы пишете сеттер безо всяких тестов.
В моем предcтавлении в классическом TDD не пишут код, пока не упал тест. То есть сеттер я не могу написать без упавшего теста.
Но обычно сеттер нужен не для того, чтобы установить какое-то значение и радоваться этому. А чтобы это как-то повлияло на поведение.
Т.е. я пишу тест "если превышена максимальная глубина стека то выдается эксепшн" а не "если я задаю максимальную глубину стека, то она задана"
С моей точки зрения, если для чего-то не пишутся тесты, то для разработки этого не используется TDD.
На самом деле я не вижу практической пользы от ответов на эти вопросы. И я точно знаю что фанатизм до добра не доводит и нужно понимать где и как применять методики.
Если вы для 3х методов класса тесты пишете, а для 4го, который, например, всего лишь однострочная обертка библиотечной функции — нет, то используете ли вы для разработки TDD?
Да. Если я использовал для гвоздя молоток, а для шурупа отвертку, то я использую молоток.
А если вы именно по принципам TDD которые описывают его применимость определили что для этого метода тесты не нужны, то использовали ли вы его для разработки?
А вот тут я бы хотел ссылочку. Я слышал принцип "Тестировать надо то, что может сломаться". В моем представлении тестировать надо то, тестирование чего окупается (легко тестировать или выигрыш от предотвращения багов и влияния на дизайн большой).
The programmer must not write code that is beyond the functionality that the test checks.
https://en.wikipedia.org/wiki/Test-driven_development#Test-driven_development_cycle п.3
Понятно, что вам бы хотелось цитаты авторов методики, но под рукой нет
Я если и тестирую геттеры/сеттеры то косвенно, при тестировании других фич. Ну типа в тесте на глубину стека пишу сначал $obj->setStackSize(0); $obj->doSomething(); и т.д. ТО есть без сететра код теста просто не запустится, а без нормальной реализации остальные тесты буду падать
хотя это похоже на PDD.
Кент Бек в своей книге «скромно» хвалится, что может построить чистую архитектуру на тестах с лёгкостью и достаточно быстро.
В какой из них?
TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development