Тестирование с использованием BDD

[amarao]

Относительно TDD. Под любой TDD может быть написан полностью ему соответствующий, но не являющийся осмысленным код. Исключение — если тесты покрывают 100% множества входных данных, что, мягко говоря, не есть быть возможно в реальных ситуациях. Таким образом, достаточно сделать «обратную компиляцию» тестов, чтобы получить фигню, которая всем хороша, только не работает.

[Amon_Sha]

Под любой пост может быть написан полностью ему соответствующий, но не являющийся осмысленным комментарий.

[ngreduce]

Вы вообще не пишете тесты?

[amarao]

С учётом тех программ, которые я «пишу» — нет, тестов не пишу. Наши программисты — пишут.

[ngreduce]

Тогда я не пойму почему вы критикуете данный подход.
А «подгоном» для галочки, можно много чего сделать.

[amarao]

Я его не критикую в смысле «отвергаю», я скорее ставлю под сомнение тезис agile о том, что можно творить что угодно в коде, пока он проходит тесты. До определённой степени это так, но принимать за максиму я бы не стал.

[semenodm]

Да, нельзя быть ни в чем быть на 100% уверенным. Все упирается в качество автоматизированных тестов. Заметьте не только степень покрытия, Unit тестами, кода, но и Acceptance тесты. Когда вы пишите Unit тест, вы подтверждаете правильность реализации с точки зрения разработчика, Acceptance тесты подтверждают то, что вы реализовали именно то что хотел бизнес. Иными словами Unit/Integration тесты для разработчиков, Aceeptance для всех остальных.
Поверьте, если у вас разумно написаны тесты всех уровней пирамиды тестирования, то творить с кодом все, что угодно они вам просто не позволят.

[DarthSim]

1) Сценарий — это сценрий, фича — это фича. Давайте не путать понятия
2) «Тестирование с использованием BDD» равносильно фразе «Вождение машины с помощью дороги».

[ngreduce]

2) Все относительно, например: поезд является машиной, рельсы — дорогой. А съехать поезд с рельсов не может (граничные случаи не рассматриваем)

[DarthSim]

Я не к тому. Не BDD используется в тестах, а тесты в BDD.

[EvilsInterrupt]

Материал очень полезен, но мне не понравилось оформление:
1) Примеры кода можно оформить в тегом «код», а то сейчас оно выглядит как будто автор применил тег «цитата»
2) Поясняющий текст к картинке слишком далеко расположен от картинки, которую он поясняет.

ЗЫ: Сорри за занудство! ;)

[semenodm]

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

[semenodm]

Исправил проблему с тэгами, оказывается дело в < > символах в тексте cucumber feature

[zavyrylin]

Мыша на скриншоте порадовала.

[GapCoder]

Круто, не был в курсе кукумбера для Java и C#.
Для некомпилируемых фреймворков — t/bdd крайне необходимо, без этого вы получите свой маленький ад.

[semenodm]

«некомпилируемых фреймворков», что вы имели в виду? Буду ли я прав если предположу, что вы говорите о динамических языках программирования?

[semenodm]

Для тех, кому интересно покопаться в реализации самому, милости прошу на GitHub. Все три BDD frameworks представлены в этом проекте, собственно это полигон для этой статьи. Кроме того, можно поглядеть сюда, чтобы увидеть как работает Spock в связке с Selenium2/webdriver + Geb.

[Van_Gog]

а кто в CnS копаться будет?
+1 за статью, пиши еще.

[Serj_By]

за реализации для Java прошу зайти сюда.

Nice try! :)
Ссылку вырезал, дабы не плодить.