Об этом и речь: если есть спецификация для тестирования системной фичи, то по определению, она должна быть написана на языке бизнеса, и скорее всего писать ее заказчику или аналитику.
по мне так там сильно все притянуто за уши. Отличие лишь в том, что framework позволяет название метода разложить в текст (расставить пробелы).
а спецификация все равно пишется на PHP, тестировщикам и заказчикам это явно не понравится. А как разработчику мне все равно как будет текст написан camel-ом или через пробел.
Согласен, что любую системную фичу можно вытащить на уровень бизнеса, не знаю будут ли они только вам благодарны, скорее скажут: это ваше дело какие там библиотеки используются.
«Тестировщики и заказчики — это уже последующий этап (если там и используется некая схожая методика — то она все равно служит другим целям, нежели BDD как метод разработки).»
Вот тут у Вас важная ошибка в суждении. Почитайте определение BDD, оно именно для всех, объединяет понимание для всех ролей на уровне общих спецификаций.
Как раз привносит: вопрос заключается в требованиях к тестам.
По TDD мы должны иметь
а) спецификацию на модуль
б) потом делать модуль и разрабатывать модульные тесты вперед
в) потом проводить функциональное тестирование QA
г) потом проводить приемочное тестирование заказчиком
все эти активности базируются на исходных требованиях
По BDD мы должны иметь:
а) спецификации в смысле BDD, не требования, а именно бизнес-описание поведения системы
Разработчики используют их для реализации возможности автоматической верификации кода по этим спецификациям, тестировщики и заказчики расширяют и создают их.
Разница очевидна.
Понятно, что BDD получится использовать только в продвинутых командах. Но все равно это несколько разные вещи, TDD полезно разработчикам, BDD полезно скорее тестировщикам и заказчику, для разработчиков это лишняя головная боль, поскольку каждую новую спецификацию нужно «завязать» на методы.
Пока остаюсь при своем мнении:
TDD и BDD можно и даже наверно нужно использовать совместно, поскольку TDD ориентирована на техническую составляющую: проверить DAO, проверить согласованность всяких XML-файлов, проверить работоспособность сугубо технических аспектов (логирование, как пример). BDD ориентировано на бизне-логику. Как известно, помимо бизнеса в реальном приложении масса сугубо технических задач, которые бизнесу вообще до фонаря.
В целом со всем согласен, за исключением: «TDD — это подход к разработке кода, основанный на юнит тестировании»
TDD — это подход к разработке кода, основанный на *модульном* тестировании, то есть на создании тестов невидимых и недоступных QA или закачзику.
Из описания BDD в википедии прямым текстом следует (encourages collaboration between developers, QA and non-technical or business participants), что эта методика нацелена на разработку единых тестов для всех ролей, именно функциональных, описанных на языке бизнеса.
И противопоставление к TDD основывается как раз на том, что в TDD готовятся тесты понятные только разработчикам, а в BDD тесты понятные всем.
Тесты в смысле TDD называются спецификациями, хотя по-прежнему для меня здесь слишком тонкая грань, у них просто цели разные: у тестов задать входные данные и ожидаемый результат, у спецификации описать некоторое бизнес-правило и определить контрольные точки (опять же сверку входных данных и ожидаемого результата), то есть спецификация — это набор связанных тестов, описанных на языке бизнеса, как-то так.
Посмотрите на FITPro, например, это в чистом виде BDD методика: тесты пишутся на бизнес-языке, они являются требованиями для разработки, несколько тестов можно объединить и получится спецификация на бизнес-правило.
«Можете указать, где именно спорный момент у автора?»
Да, конечно, "… Behavior Driven Development и чем данная техника отличается от Test-Driven Development"
Согласен с тем, что BDD полностью укладывается в методику TDD, и поэтому ничем не может отличаться. Комментом выше уже предположил, что автор путает unit-тесты (assertTrue, assertFalse) и TDD.
Если отталкиваться от сравнения Unit-тестов и BDD, то конечно BDD иногда может быть удобнее, но поскольку BDD закрывает пробел между unit-тестами и функциональными тестами, то в этом и проявляется сложность вопроса: относится ли BDD к функциональным тестам или нет, поскольку можно написать такой тест, что он будет полностью повторять функциональный, поскольку оперируем бизнес-понятиями (то чем оперирует QA и закачзик), а не объектами и элементами архитектуры (то чем оперирует разработчик)
То есть в итоге получается какая-то каша. С одной стороны тесты делает разработчик, а с другой он оперирует бизнес-правилами, то есть выполняет работу тестировщика.
«Вот так и появилось BDD:) И это уже более высокий уровень чем assertEquals и т.п.»
Я кажется понял откуда ноги растут: вы действительно сравниваете unit-тестирование с TDD?
В моем понимании TDD — это совсем не фреймворк для unit-тестов, это методика разработки, использовать там assertEquals или test.CheckLogicIsCorrectlyImplemented() не регламентируется TDD, это всего лишь подход к разработке: сначала тест, потом логика.
«А то что касаеться FIT, вы просто путаете функциональные тесты с BDD»
Мне почему-то все же верится, что я ничего не путаю, поскольку BDD и есть фукнциональное тестирование, опять же основываясь на Вашей статье: «Мышление в терминах функциональности (того, что код должен делать)...»
В моем понимании необходимо два типа тестирования функционала (не считая нагрузки, совместимости, масштабируемости горизонтальной и вертикальной и т.п.):
1. unit-тестирование, когда разработчик проверяет и фиксирует спецификацию к некоторому алгоритму, участку кода
2. функциональное тестирование, когда QA или заказчик смотрит на систему не со стороны кода и конкретных алгоритмов, а с наружи, со стороны пользователя и пытается получить от системы ответы согласно функциональности системы.
Хочу заметить, что TDD как таковое может покрывать как первый, так и второй тип тестирования, то есть написание тестов может начаться:
а) до разработки логики (пишется программистом)
б) до поставки продукта QA или заказчику на приемку (пишется QA или закачзиком)
В этом смысле Ваше BDD есть некоторое расширение классического unit-тестирования и не более того.
Вот я не понимаю, почему Вы различаете тесты и спецификации? Спецификация — это такой же тест, только описываемый декларативно (на языке бизнеса чаще всего).
Класс, метод, его аргументы и возвращаемый результат есть ничто иное как спецификация.
Более того, TDD не обязательно следует применять для проверки равенства. Применяйте методику для тестирования логики по спецификациям. То есть будет у вас тест, который делает ровно тоже самое, что сейчас Вы называете BDD.
Единественное отличие, которое я вижу, то в BDD просто используется более высокоуровневое тестирование, обычно именуемое как автоматическое функциональное тестирование.
А что касается написания BDD тестов разработчиками, то на мой взгляд это отнюдь не преимущество по сравнению с идеями FIT. В данном ключе BDD — это тот же TDD, просто чуть более высокоуровневый.
Настоящее преимущество методика получает при использовании ее пользователем (заказчиком), который точно знает как ему нужно, а не как написано в спецификации.
Честно говоря, статья так и не раскрыла разницу между понятиями «тест» и «должен», функциональное тестирование и unit-тестирование понятия иногда расходящиеся, иногда сходящиеся.
Почему бы «должен» не отнести к «метод А должен возвращать 1, если передали 0», реализация проверки есть самый настоящий «тест».
Тест всегда характеризуется входными данными, ожидаемым и фактическим результатом, после выполнения операции над некоторым черным ящиком.
Тест может быть определен на уровне метода, а может на уровне функции системы, а может на уровне функционала — это конечно свобода выбора, но TDD тем и хороша, что эту свободу ограничивает и требует покрыть тестами все методы, а не какой-то по желанию выбранный разработчиком функционал.
Более, того, на мой взгляд необосновано замолчено грандиозное требование TDD к использованию: код, который вы разрабатываете, должен предполагать автоматическое тестирование (!) Данный принцип позволяет проектировать архитектуру приложения исходя из возможности его тестирования автоматическими unit-тестами.
Аббревиатура BDD мне не очень известна, но известен инструмент FIT (и его аналоги), есть некоторые обзоры тут: lobasev.ru/search/label/FIT
Основная цель: привлечение к тестированию пользователей продукта, где они могут создавать тесты на бизнес-языке и проверять работу приложения в автоматическом режиме. Насколько я понял из Вашего примера — это есть одно и то же.
Подчеркну, что TDD и BDD это не соперники, а скорее совершенно разные методики, которые совместно необходимо применять в проектах.
Да, согласен, тут скорее вопрос к автору поста по поводу того на какой он стадии находится, то есть для кого преобретается сервер.
Кстати, сервер за 10k покупать не обязательно, можно и самому собрать из ширпотребовских компонентов, выйдет дешевле, чем год по $100 у.е. (стоимость трафика и подключения не учитываются).
Переход с одной железки на другую — это время, а при желании быстро выйти из дела будет только мешать.
Интересен другой момент. Если вы действительно говорите о стартапе, то в случае успешного начала вам потребуется организовывать юр. лицо для привлечения инвесторов и возможно последующей продажи.
Иметь свой собственный сервер (не арендуемый) удобно тем, что вы его стоимость можете включить в базовый капитал, тем самым перенести расходы на инвесторов в будущем (размыть по ним).
А если арендуется сервер в другой стране, у вас какие-то документы будут, кроме чеков на оплату услуг провайдера? Скорее всего нет.
В описанном случае регистрировать можно все, что описано в моем первом комменте, если конечно ваши исходные коды, название продукта не были заимствованы (сворованы) у рапиды, в этом случае регистратор завернет вашу заявку, однако, если рапида не регистрировала свой программный продукт, то вы будете первыми, но доказать авторство рапида сможет через суд.
Вам нужно понять самое главное и единственное: идея в России ничего не стоит и зарегистрировать ее нельзя, можно регистрировать готовый программный продукт (базу данных) или патентовать изобретение (кажется еще модели можно).
тут даже вопрос не в этом, а в том, что если человек хочет официально сопоставить себя в роли автора с некоторым программным продуктом, то причины могут быть только такие: чтобы части исходного кода не могли быть использованы в других продуктах, чтобы все вопросы использования (продажи) продукта решались только автором.
как он будет проверять соблюдение требований авторского свидетельства — это его личная проблема. Но, если, каким-то образом он узнает, что его бывший партнер стырил коды и написал подобное приложение и зарабатывает на этом деньги, то наличие свидетельства — веское основание для обращение в суд.
в суд можно обратиться и без свидетельства, но тут исход заренее не очевиден, поскольку суду придется выяснять авторство.
а спецификация все равно пишется на PHP, тестировщикам и заказчикам это явно не понравится. А как разработчику мне все равно как будет текст написан camel-ом или через пробел.
«Тестировщики и заказчики — это уже последующий этап (если там и используется некая схожая методика — то она все равно служит другим целям, нежели BDD как метод разработки).»
Вот тут у Вас важная ошибка в суждении. Почитайте определение BDD, оно именно для всех, объединяет понимание для всех ролей на уровне общих спецификаций.
— мы используем Agile!
— а кто у вас Product Owner?
— ну как же, менеджер проекта…
Если уж и писать о методике и бросаться фразами «чем отличается от TDD», то нужно суть излагать.
По TDD мы должны иметь
а) спецификацию на модуль
б) потом делать модуль и разрабатывать модульные тесты вперед
в) потом проводить функциональное тестирование QA
г) потом проводить приемочное тестирование заказчиком
все эти активности базируются на исходных требованиях
По BDD мы должны иметь:
а) спецификации в смысле BDD, не требования, а именно бизнес-описание поведения системы
Разработчики используют их для реализации возможности автоматической верификации кода по этим спецификациям, тестировщики и заказчики расширяют и создают их.
Разница очевидна.
Понятно, что BDD получится использовать только в продвинутых командах. Но все равно это несколько разные вещи, TDD полезно разработчикам, BDD полезно скорее тестировщикам и заказчику, для разработчиков это лишняя головная боль, поскольку каждую новую спецификацию нужно «завязать» на методы.
Пока остаюсь при своем мнении:
TDD и BDD можно и даже наверно нужно использовать совместно, поскольку TDD ориентирована на техническую составляющую: проверить DAO, проверить согласованность всяких XML-файлов, проверить работоспособность сугубо технических аспектов (логирование, как пример). BDD ориентировано на бизне-логику. Как известно, помимо бизнеса в реальном приложении масса сугубо технических задач, которые бизнесу вообще до фонаря.
TDD — это подход к разработке кода, основанный на *модульном* тестировании, то есть на создании тестов невидимых и недоступных QA или закачзику.
Из описания BDD в википедии прямым текстом следует (encourages collaboration between developers, QA and non-technical or business participants), что эта методика нацелена на разработку единых тестов для всех ролей, именно функциональных, описанных на языке бизнеса.
И противопоставление к TDD основывается как раз на том, что в TDD готовятся тесты понятные только разработчикам, а в BDD тесты понятные всем.
Тесты в смысле TDD называются спецификациями, хотя по-прежнему для меня здесь слишком тонкая грань, у них просто цели разные: у тестов задать входные данные и ожидаемый результат, у спецификации описать некоторое бизнес-правило и определить контрольные точки (опять же сверку входных данных и ожидаемого результата), то есть спецификация — это набор связанных тестов, описанных на языке бизнеса, как-то так.
Посмотрите на FITPro, например, это в чистом виде BDD методика: тесты пишутся на бизнес-языке, они являются требованиями для разработки, несколько тестов можно объединить и получится спецификация на бизнес-правило.
Да, конечно, "… Behavior Driven Development и чем данная техника отличается от Test-Driven Development"
Согласен с тем, что BDD полностью укладывается в методику TDD, и поэтому ничем не может отличаться. Комментом выше уже предположил, что автор путает unit-тесты (assertTrue, assertFalse) и TDD.
Если отталкиваться от сравнения Unit-тестов и BDD, то конечно BDD иногда может быть удобнее, но поскольку BDD закрывает пробел между unit-тестами и функциональными тестами, то в этом и проявляется сложность вопроса: относится ли BDD к функциональным тестам или нет, поскольку можно написать такой тест, что он будет полностью повторять функциональный, поскольку оперируем бизнес-понятиями (то чем оперирует QA и закачзик), а не объектами и элементами архитектуры (то чем оперирует разработчик)
То есть в итоге получается какая-то каша. С одной стороны тесты делает разработчик, а с другой он оперирует бизнес-правилами, то есть выполняет работу тестировщика.
Я кажется понял откуда ноги растут: вы действительно сравниваете unit-тестирование с TDD?
В моем понимании TDD — это совсем не фреймворк для unit-тестов, это методика разработки, использовать там assertEquals или test.CheckLogicIsCorrectlyImplemented() не регламентируется TDD, это всего лишь подход к разработке: сначала тест, потом логика.
«А то что касаеться FIT, вы просто путаете функциональные тесты с BDD»
Мне почему-то все же верится, что я ничего не путаю, поскольку BDD и есть фукнциональное тестирование, опять же основываясь на Вашей статье: «Мышление в терминах функциональности (того, что код должен делать)...»
В моем понимании необходимо два типа тестирования функционала (не считая нагрузки, совместимости, масштабируемости горизонтальной и вертикальной и т.п.):
1. unit-тестирование, когда разработчик проверяет и фиксирует спецификацию к некоторому алгоритму, участку кода
2. функциональное тестирование, когда QA или заказчик смотрит на систему не со стороны кода и конкретных алгоритмов, а с наружи, со стороны пользователя и пытается получить от системы ответы согласно функциональности системы.
Хочу заметить, что TDD как таковое может покрывать как первый, так и второй тип тестирования, то есть написание тестов может начаться:
а) до разработки логики (пишется программистом)
б) до поставки продукта QA или заказчику на приемку (пишется QA или закачзиком)
В этом смысле Ваше BDD есть некоторое расширение классического unit-тестирования и не более того.
Причем функциональные тесты пишут разработчики, хотя всем известно, что такие вещи должны делать QA или заказчик (в случае Agile).
Класс, метод, его аргументы и возвращаемый результат есть ничто иное как спецификация.
Более того, TDD не обязательно следует применять для проверки равенства. Применяйте методику для тестирования логики по спецификациям. То есть будет у вас тест, который делает ровно тоже самое, что сейчас Вы называете BDD.
Единественное отличие, которое я вижу, то в BDD просто используется более высокоуровневое тестирование, обычно именуемое как автоматическое функциональное тестирование.
А что касается написания BDD тестов разработчиками, то на мой взгляд это отнюдь не преимущество по сравнению с идеями FIT. В данном ключе BDD — это тот же TDD, просто чуть более высокоуровневый.
Настоящее преимущество методика получает при использовании ее пользователем (заказчиком), который точно знает как ему нужно, а не как написано в спецификации.
Почему бы «должен» не отнести к «метод А должен возвращать 1, если передали 0», реализация проверки есть самый настоящий «тест».
Тест всегда характеризуется входными данными, ожидаемым и фактическим результатом, после выполнения операции над некоторым черным ящиком.
Тест может быть определен на уровне метода, а может на уровне функции системы, а может на уровне функционала — это конечно свобода выбора, но TDD тем и хороша, что эту свободу ограничивает и требует покрыть тестами все методы, а не какой-то по желанию выбранный разработчиком функционал.
Более, того, на мой взгляд необосновано замолчено грандиозное требование TDD к использованию: код, который вы разрабатываете, должен предполагать автоматическое тестирование (!) Данный принцип позволяет проектировать архитектуру приложения исходя из возможности его тестирования автоматическими unit-тестами.
Аббревиатура BDD мне не очень известна, но известен инструмент FIT (и его аналоги), есть некоторые обзоры тут: lobasev.ru/search/label/FIT
Основная цель: привлечение к тестированию пользователей продукта, где они могут создавать тесты на бизнес-языке и проверять работу приложения в автоматическом режиме. Насколько я понял из Вашего примера — это есть одно и то же.
Подчеркну, что TDD и BDD это не соперники, а скорее совершенно разные методики, которые совместно необходимо применять в проектах.
Кстати, сервер за 10k покупать не обязательно, можно и самому собрать из ширпотребовских компонентов, выйдет дешевле, чем год по $100 у.е. (стоимость трафика и подключения не учитываются).
Переход с одной железки на другую — это время, а при желании быстро выйти из дела будет только мешать.
Иметь свой собственный сервер (не арендуемый) удобно тем, что вы его стоимость можете включить в базовый капитал, тем самым перенести расходы на инвесторов в будущем (размыть по ним).
А если арендуется сервер в другой стране, у вас какие-то документы будут, кроме чеков на оплату услуг провайдера? Скорее всего нет.
Вам нужно понять самое главное и единственное: идея в России ничего не стоит и зарегистрировать ее нельзя, можно регистрировать готовый программный продукт (базу данных) или патентовать изобретение (кажется еще модели можно).
как он будет проверять соблюдение требований авторского свидетельства — это его личная проблема. Но, если, каким-то образом он узнает, что его бывший партнер стырил коды и написал подобное приложение и зарабатывает на этом деньги, то наличие свидетельства — веское основание для обращение в суд.
в суд можно обратиться и без свидетельства, но тут исход заренее не очевиден, поскольку суду придется выяснять авторство.