http://habrahabr.ru/rss/post/52929/ ru editor@habrahabr.ru habrahabr.ru Sat, 11 Feb 2012 16:26:25 GMT http://habrahabr.ru/ http://habrahabr.ru/i/logo.gif http://habrahabr.ru/blogs/testing/52929/#comment_1413132 http://habrahabr.ru/blogs/testing/52929/#comment_1413132 Еще про test-driven на ruby on rails.]]> Sat, 28 Feb 2009 20:44:59 GMT NaTTs http://habrahabr.ru/blogs/testing/52929/#comment_1407531 http://habrahabr.ru/blogs/testing/52929/#comment_1407531 Thu, 26 Feb 2009 15:44:26 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1407369 http://habrahabr.ru/blogs/testing/52929/#comment_1407369 Thu, 26 Feb 2009 15:14:04 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1407288 http://habrahabr.ru/blogs/testing/52929/#comment_1407288 Thu, 26 Feb 2009 15:01:24 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1407259 http://habrahabr.ru/blogs/testing/52929/#comment_1407259
phpspec я привел лишь как пример уже работающего фреймворка для тех кто хочет пробнуть свои силы.]]> Thu, 26 Feb 2009 14:56:12 GMT DYPA http://habrahabr.ru/blogs/testing/52929/#comment_1407232 http://habrahabr.ru/blogs/testing/52929/#comment_1407232
«Согласен, что любую системную фичу можно вытащить на уровень бизнеса, не знаю будут ли они только вам благодарны, скорее скажут: это ваше дело какие там библиотеки используются.»

Речь вовсе не идет о том, что что-то куда-то вытаскивать. Не нужно системные фичи на уровень бизнеса вытаскивать. Я говорю о том, что системные фичи точно так же, как и бизнес-логику, можно тестировать с помощью этих спецификаций.]]> Thu, 26 Feb 2009 14:51:04 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1407230 http://habrahabr.ru/blogs/testing/52929/#comment_1407230
а спецификация все равно пишется на PHP, тестировщикам и заказчикам это явно не понравится. А как разработчику мне все равно как будет текст написан camel-ом или через пробел.]]> Thu, 26 Feb 2009 14:50:45 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1407224 http://habrahabr.ru/blogs/testing/52929/#comment_1407224
Я покопаю тему концепции BDD еще.

Отдельно об этом:

]]> Thu, 26 Feb 2009 14:49:41 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1407201 http://habrahabr.ru/blogs/testing/52929/#comment_1407201
«Тестировщики и заказчики — это уже последующий этап (если там и используется некая схожая методика — то она все равно служит другим целям, нежели BDD как метод разработки).»

Вот тут у Вас важная ошибка в суждении. Почитайте определение BDD, оно именно для всех, объединяет понимание для всех ролей на уровне общих спецификаций.]]> Thu, 26 Feb 2009 14:45:06 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1407156 http://habrahabr.ru/blogs/testing/52929/#comment_1407156
— мы используем Agile!
— а кто у вас Product Owner?
— ну как же, менеджер проекта…

Если уж и писать о методике и бросаться фразами «чем отличается от TDD», то нужно суть излагать.]]> Thu, 26 Feb 2009 14:38:40 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1407153 http://habrahabr.ru/blogs/testing/52929/#comment_1407153
Но сразу могу сказать про последний абзац.
«Как известно, помимо бизнеса в реальном приложении масса сугубо технических задач, которые бизнесу вообще до фонаря.»

Можете представить всю системную часть как «бизнес-логику» работы вашей же архитектуры, системы.

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

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

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

Наверное, для наглядности надо будет рассмотреть какой-нибудь пример.]]> Thu, 26 Feb 2009 14:38:13 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1407141 http://habrahabr.ru/blogs/testing/52929/#comment_1407141 Thu, 26 Feb 2009 14:35:53 GMT iv_s http://habrahabr.ru/blogs/testing/52929/#comment_1407127 http://habrahabr.ru/blogs/testing/52929/#comment_1407127 Для менеджера BDD одно, для программиста другое:)]]> Thu, 26 Feb 2009 14:34:02 GMT iv_s http://habrahabr.ru/blogs/testing/52929/#comment_1407115 http://habrahabr.ru/blogs/testing/52929/#comment_1407115 www.phpspec.org/ сразу станет ясна суть]]> Thu, 26 Feb 2009 14:31:10 GMT DYPA http://habrahabr.ru/blogs/testing/52929/#comment_1407095 http://habrahabr.ru/blogs/testing/52929/#comment_1407095 Поэтому я бы писал статью только про саму технологию и как именно она позволяет использовать те или иные приемы TDD(Предполагая, что аудитория знакома с техникой tdd). При это стараясь не вдаваться в теорию.
Или же написать цикл статьей посвященных исключительно TDD и BDD, максимум давай небольшие примеры.]]> Thu, 26 Feb 2009 14:28:21 GMT sirmakc http://habrahabr.ru/blogs/testing/52929/#comment_1407067 http://habrahabr.ru/blogs/testing/52929/#comment_1407067
По TDD мы должны иметь

а) спецификацию на модуль
б) потом делать модуль и разрабатывать модульные тесты вперед
в) потом проводить функциональное тестирование QA
г) потом проводить приемочное тестирование заказчиком

все эти активности базируются на исходных требованиях

По BDD мы должны иметь:

а) спецификации в смысле BDD, не требования, а именно бизнес-описание поведения системы

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

Разница очевидна.

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

Пока остаюсь при своем мнении:

TDD и BDD можно и даже наверно нужно использовать совместно, поскольку TDD ориентирована на техническую составляющую: проверить DAO, проверить согласованность всяких XML-файлов, проверить работоспособность сугубо технических аспектов (логирование, как пример). BDD ориентировано на бизне-логику. Как известно, помимо бизнеса в реальном приложении масса сугубо технических задач, которые бизнесу вообще до фонаря.]]> Thu, 26 Feb 2009 14:23:35 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1407026 http://habrahabr.ru/blogs/testing/52929/#comment_1407026
TDD — это подход к разработке кода, основанный на *модульном* тестировании, то есть на создании тестов невидимых и недоступных QA или закачзику.

Из описания BDD в википедии прямым текстом следует (encourages collaboration between developers, QA and non-technical or business participants), что эта методика нацелена на разработку единых тестов для всех ролей, именно функциональных, описанных на языке бизнеса.

И противопоставление к TDD основывается как раз на том, что в TDD готовятся тесты понятные только разработчикам, а в BDD тесты понятные всем.

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

Посмотрите на FITPro, например, это в чистом виде BDD методика: тесты пишутся на бизнес-языке, они являются требованиями для разработки, несколько тестов можно объединить и получится спецификация на бизнес-правило.

]]> Thu, 26 Feb 2009 14:12:24 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1406974 http://habrahabr.ru/blogs/testing/52929/#comment_1406974 Thu, 26 Feb 2009 13:58:29 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1406968 http://habrahabr.ru/blogs/testing/52929/#comment_1406968
По поводу бизнес-правил — разумеется, разработчик ими оперирует, он же не просто так код пишет, а для чего-то. Ключевой момент в том, что он тестирует именно код (а не систему с точки зрения пользователя и сценариев использования, «не заглядывая в код» — для этого есть тестировщики).

Еще один нюанс в том, что _технически_ часть функциональных тестов можно сделать в виде юнит-тестов (точто так же, как, например, интеграционные тесты). Просто для кого-то это может быть запутано, но BDD не привносит ничего нового в тестирование как таковое (все и так тестируется полностью и BDD, скажем, не увеличит процент покрытия кода тестами), а только дает новый метод делать то, что мы уже делали с помощью TDD. Можно называть это не юнит-тестами, а «спецификациями» — суть проверки конкретного бизнес-правила от этого не поменяется.]]> Thu, 26 Feb 2009 13:57:18 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1406919 http://habrahabr.ru/blogs/testing/52929/#comment_1406919 Еще нужно добавить, для точности, что вообще то юнит тестирование не тоже самое что и TDD.
Юнит тестирование — это метод тестирования, а TDD — это подход к разработке кода, основанный на юнит тестировании.
Точно также и с BDD. В общем случае можно сказать что тестирование поведения это и есть функциональное тестирование, когда тестируется черный ящик. Но BDD — это подход к написанию кода, используя тесты поведения по спецификации. Что нам и демонстрирует фреймворк RSpec. ]]> Thu, 26 Feb 2009 13:49:12 GMT iv_s http://habrahabr.ru/blogs/testing/52929/#comment_1406914 http://habrahabr.ru/blogs/testing/52929/#comment_1406914
Да, конечно, "… Behavior Driven Development и чем данная техника отличается от Test-Driven Development"

Согласен с тем, что BDD полностью укладывается в методику TDD, и поэтому ничем не может отличаться. Комментом выше уже предположил, что автор путает unit-тесты (assertTrue, assertFalse) и TDD.

Если отталкиваться от сравнения Unit-тестов и BDD, то конечно BDD иногда может быть удобнее, но поскольку BDD закрывает пробел между unit-тестами и функциональными тестами, то в этом и проявляется сложность вопроса: относится ли BDD к функциональным тестам или нет, поскольку можно написать такой тест, что он будет полностью повторять функциональный, поскольку оперируем бизнес-понятиями (то чем оперирует QA и закачзик), а не объектами и элементами архитектуры (то чем оперирует разработчик)

То есть в итоге получается какая-то каша. С одной стороны тесты делает разработчик, а с другой он оперирует бизнес-правилами, то есть выполняет работу тестировщика.]]> Thu, 26 Feb 2009 13:47:09 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1406910 http://habrahabr.ru/blogs/testing/52929/#comment_1406910 BDD1
BDD2
А у вас реально можно было ограничится ссылками ;)
]]> Thu, 26 Feb 2009 13:46:55 GMT dirdor http://habrahabr.ru/blogs/testing/52929/#comment_1406870 http://habrahabr.ru/blogs/testing/52929/#comment_1406870
Я кажется понял откуда ноги растут: вы действительно сравниваете unit-тестирование с TDD?

В моем понимании TDD — это совсем не фреймворк для unit-тестов, это методика разработки, использовать там assertEquals или test.CheckLogicIsCorrectlyImplemented() не регламентируется TDD, это всего лишь подход к разработке: сначала тест, потом логика.

«А то что касаеться FIT, вы просто путаете функциональные тесты с BDD»

Мне почему-то все же верится, что я ничего не путаю, поскольку BDD и есть фукнциональное тестирование, опять же основываясь на Вашей статье: «Мышление в терминах функциональности (того, что код должен делать)...»

В моем понимании необходимо два типа тестирования функционала (не считая нагрузки, совместимости, масштабируемости горизонтальной и вертикальной и т.п.):

1. unit-тестирование, когда разработчик проверяет и фиксирует спецификацию к некоторому алгоритму, участку кода

2. функциональное тестирование, когда QA или заказчик смотрит на систему не со стороны кода и конкретных алгоритмов, а с наружи, со стороны пользователя и пытается получить от системы ответы согласно функциональности системы.

Хочу заметить, что TDD как таковое может покрывать как первый, так и второй тип тестирования, то есть написание тестов может начаться:

а) до разработки логики (пишется программистом)
б) до поставки продукта QA или заказчику на приемку (пишется QA или закачзиком)

В этом смысле Ваше BDD есть некоторое расширение классического unit-тестирования и не более того.

]]> Thu, 26 Feb 2009 13:35:30 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1406823 http://habrahabr.ru/blogs/testing/52929/#comment_1406823
Вот так и появилось BDD:) И это уже более высокий уровень чем assertEquals и т.п.

«В данном ключе BDD — это тот же TDD, просто чуть более высокоуровневый.»
По сути, так и есть, я и написал выше что его можно рассматривать как слой абстрации над TDD.

А то что касаеться FIT, вы просто путаете функциональные тесты с BDD. Функциональное тестирование, которое может проводить не только программист но и тестер и пользователь, прежде всего подразумавает «черный ящик», т.е. тестирующий не имеет представления как это работает, и тестирует некие функиональные куски и их интеграцию. В BDD пользователь конечно может прогнать тесты, но вот написать — врядли.]]> Thu, 26 Feb 2009 13:21:18 GMT iv_s http://habrahabr.ru/blogs/testing/52929/#comment_1406814 http://habrahabr.ru/blogs/testing/52929/#comment_1406814
Вообще, BDD ни на грамм не выходит за рамки TDD, его все также пишут программисты (функциональное тестирование здесь вообще ни при чем). Однако, любой код так или иначе привязан к задаче и ее бизнес-логике. Я думаю, автор имел в виду, что BDD, возможно, более подходит для того, чтобы применять бизнес-правила к коду. В BDD они просто более «человекопонятны». Разумеется, при этом это все тот же код, который пишется разработчиками.

Т.е., по сути, отличие BDD от TDD только в том, в каком виде разработчику удобно писать тесты для кода (но не функциональные/UX-тесты).]]> Thu, 26 Feb 2009 13:20:17 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1406782 http://habrahabr.ru/blogs/testing/52929/#comment_1406782 Thu, 26 Feb 2009 13:10:13 GMT EugeneKudashev http://habrahabr.ru/blogs/testing/52929/#comment_1406779 http://habrahabr.ru/blogs/testing/52929/#comment_1406779
Причем функциональные тесты пишут разработчики, хотя всем известно, что такие вещи должны делать QA или заказчик (в случае Agile).]]> Thu, 26 Feb 2009 13:09:19 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1406761 http://habrahabr.ru/blogs/testing/52929/#comment_1406761
Класс, метод, его аргументы и возвращаемый результат есть ничто иное как спецификация.

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

Единественное отличие, которое я вижу, то в BDD просто используется более высокоуровневое тестирование, обычно именуемое как автоматическое функциональное тестирование.

А что касается написания BDD тестов разработчиками, то на мой взгляд это отнюдь не преимущество по сравнению с идеями FIT. В данном ключе BDD — это тот же TDD, просто чуть более высокоуровневый.

Настоящее преимущество методика получает при использовании ее пользователем (заказчиком), который точно знает как ему нужно, а не как написано в спецификации.

]]> Thu, 26 Feb 2009 13:03:39 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1406742 http://habrahabr.ru/blogs/testing/52929/#comment_1406742 Thu, 26 Feb 2009 12:59:51 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1406658 http://habrahabr.ru/blogs/testing/52929/#comment_1406658
Нет, в BDD тесты пишет сам программист, так же как и в TDD. А то что синтаксис библиотеки RSpec выглядит как BNL — это синтаксический сахар Ruby.
И все-таки BDD и TDD соперники, нет смысла писать юнит тесты если есть спецификации. BDD можно рассматривать как новый слой абстракции над юнит тестами. Если там мы просто проверяем равенства и т.п., то тут проверяем соответствия поведения реальной функции/объекта с поведением описанным в спецификации, правда используя теже методики:)(всмысле проверка на равенство и т.д.)]]> Thu, 26 Feb 2009 12:36:12 GMT iv_s #comment_1406656 #comment_1406656 Thu, 26 Feb 2009 12:34:50 GMT diggy http://habrahabr.ru/blogs/testing/52929/#comment_1406650 http://habrahabr.ru/blogs/testing/52929/#comment_1406650
Я бы лично комбинировал данные подходы к разработке ПО]]> Thu, 26 Feb 2009 12:30:46 GMT Joka http://habrahabr.ru/blogs/testing/52929/#comment_1406597 http://habrahabr.ru/blogs/testing/52929/#comment_1406597 Thu, 26 Feb 2009 12:15:52 GMT VasilioRuzanni http://habrahabr.ru/blogs/testing/52929/#comment_1406362 http://habrahabr.ru/blogs/testing/52929/#comment_1406362
Почему бы «должен» не отнести к «метод А должен возвращать 1, если передали 0», реализация проверки есть самый настоящий «тест».

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

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

Более, того, на мой взгляд необосновано замолчено грандиозное требование TDD к использованию: код, который вы разрабатываете, должен предполагать автоматическое тестирование (!) Данный принцип позволяет проектировать архитектуру приложения исходя из возможности его тестирования автоматическими unit-тестами.

Аббревиатура BDD мне не очень известна, но известен инструмент FIT (и его аналоги), есть некоторые обзоры тут: lobasev.ru/search/label/FIT

Основная цель: привлечение к тестированию пользователей продукта, где они могут создавать тесты на бизнес-языке и проверять работу приложения в автоматическом режиме. Насколько я понял из Вашего примера — это есть одно и то же.

Подчеркну, что TDD и BDD это не соперники, а скорее совершенно разные методики, которые совместно необходимо применять в проектах.]]> Thu, 26 Feb 2009 10:59:57 GMT devprom http://habrahabr.ru/blogs/testing/52929/#comment_1405873 http://habrahabr.ru/blogs/testing/52929/#comment_1405873 Thu, 26 Feb 2009 08:04:32 GMT kernel http://habrahabr.ru/blogs/testing/52929/#comment_1405835 http://habrahabr.ru/blogs/testing/52929/#comment_1405835 Thu, 26 Feb 2009 07:49:43 GMT iv_s