Небольшой холивар TDD /specBDD

[Absinthe]

Я вот не могу понять, зачем на таком уродливом огурце описывать тесты.
Лучше я обычные функциональные тесты на привычном мощном языке поделаю.

ты сначала обдумываешь поведение компонентов системы, и только потом посредством анализа их поведения и т п углубляешься в тесты (tdd)

А зачем для этого какой-то формальный язык?

 

[Ragazzo]

Absinthe
еще на 4 странички?не... чето не хочется
P.S. кстати опять все не туда ушли ну ладно, я то про спек изначально говорил, а в итоге все к стори скатилось...

 

[davert]

Коль ты мне дал сюда ссылку, я тоже возьму и отпишусь

Самое базовое и фундаментальное отличие это то "что мы тестируем".

По TDD наша задача - протестировать метод. Всё. Мы не углубляемся в детали того что он делает. Мы просто стараемся прогнать его по всем возможным путям прохождения и тем самым достичь 100% покрытия.

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

Пример: протестировать систему аутентификации:
По TDD мы будем тестировать функцию: "grantPermission"
По BDD мы будем тестировать "admin can access article", "user can access it's own article", "user cant access other users article".

В этом как бы основное различие. Такие элементы BDD можно юзать где угодно. Тот же everzet говорил, что вполне доволен возможностями PHPUnit для написания спеков. Какая разница как выглядят методы ассертов или описания. Главное - какие тесты пишутся.

----

Тут проскакивала ссылка на замечательную статью DHH Testiing Like TSA. Суть в том, что тестирование в рельсах построено скорее по BDD схеме. Девид не любит синтаксис RSpec, Cucumber, считая их избыточным. По сути правильно делает ведь отличия RSpec от того же Test::Unit приницпиально не очень значительное. И там и там используются схожие описания, и там и там тестирование идет через SpecBDD. То что отличия чисто синтаксического характера, и как такового спора в Руби тусовке нет, как по мне подтверждено выходом MiniTest.

----

В PHP SpecBDD отлично реализуется на PHPUnit. Хотелось бы конечно иметь более вкусный и читабельный синтаксис. Проблема скорее в том, что PHP не предоставляет возможность описывать некоторые спеки столь лаконично и там где обычно в руби идет одна строчка в PHP нужно писать 4 (это я про PHPSpec). Потому любые попытки портировать RSpec на PHP выглядят корявенько и не дают особых преимуществ над классическими юнит-тест фреймворками.

 

[Вурдалак]

Тема TDD/BDD очень хороша для разного рода срача, потому что происходит размытие понятий и их пересечение.

Как я себе все это вижу: TDD как процесс разработки вообще не ограничивает нас тестировать только методы, как это сказано выше. Мне ничего не мешает написать

class AclTest extends TestCase {
    public function setUp() {
        $this->acl = ...
        $this->secretObject = ...
    }

    public function testAdminHasAccess() {
        $admin = ...
        $this->assertTrue($this->acl->hasAccess($admin, $this->secretObject));
    }

    public function testUserHasNoAccess() {
        $user = ...
        $this->assertFalse($this->acl->hasAccess($user, $this->secretObject));
    }
}

Что, это уже внезапно BDD? Изменился процесс разработки?

Далее появляются ребята, которые начинают активно форсировать новые понятия, по сути создавая обертку над голым кодом, которая будет «понятна» не только программистам, что и еще хрен знает кому.

Насколько я пытаюсь понять, тут просто происходит по сути расширение: мы пишем не только unit-тесты, то и тесты для смежных случаев. То есть по-хорошему в AclTest стоит оперировать только понятиями «объект», «роль», «субъект» без привязки к админам и юзерам. И можно ввести AclAdminUserTest, где оперировать конкретными объектами.

 

[davert]

Да, может я и чуть перегнал палку про "один метод", но по сути оно сведется к одному методу или одной фиче.

Возьмем, допустим, ваш пример. Я не заметил тут процесса разработки. Вы написали сразу 2 теста, хотя по TDD должны были написать один, проверить, чтобы он упал, затем отрефакторить, затем чтобы он прошел, писать второй, и т.д. Возникает вопрос. Если вы заранее знаете спецификацию: "пускать админа, не пускать юзера", то зачем вам сначала реализовывать одну часть функционала, а затем вторую?

Намного логичнее описать все текущие спецификации ACL в одном тесте и затем написать к ним код.
Это по TDD если.

По BDD тест описывает не конкретно одну фичу, а её взаимодействие с системой. Как у вас: userHasNoAccess, adminHasAccess. Может только обычно спецификации звучат чуть длиннее и конкретнее: userHasNoAccessToPosts, userHasNoAccessToComments, etc.

 

[Ragazzo]

Ну и чтобы не быть голословным, то вот еще так можно сказать:
1. противопоставление идет specBDD / TDD (unit-tests), вся фишка в том что с BDD именно разрабатывают/создают класс/компонент таким образом как он должен себя вести, т.е. с точки зрения его поведения, по сути просто не надо думать будет много над тем какой метод нужен или не нужен в том классе или ином. Для понимания этого (BDD) нужно немного перестроить свое "мышеление", да.

2. storyBDD очень хорош помимо функц./интеграц. тестов где надо протестить несколько компонетов, хорош для взаимодействия с DDD, когда domain-experts, software architects и "обычные" программисты могут говорить на одном языке ("ubiquitous language"), в таком случае storyBDD очень хорошо вписывается в эту ситуацию и помогает сделать продукт который как говорят "fit the domain", т.к. все тесты пишуться на понятном (общем - "ubiquitous language") языке для всей команде, что является важным моментом, т.к. все в команде должны понимать над чем они работают и как это должно отражаться в самой предметной области той задачи которую они решают.
Но потенциал у BDD очень большой поэтому применять его можно конечно по-разному, возможно это даже очень хорошо. То же было и с обычным TDD (unit-tests) когда его не принимали.

BDD в общем случае, если не говорить о холиварах вида specBDD/TDD нельзя рассматривать отдельно от TDD, оно не отрицает всех методик TDD, лишь дополняет, также как и DDD дополняет TDD вцелом, чтобы на выходе получить действительно качественный продукт.

P.S. тема очень холиварная для многих, поэтому думаю не стоит тут разводить срач еще на 5 страниц

 

[keltanas]

PhpStorm 8 EAP 138.184 Initial support for Behat

http://blog.jetbrains.com/phpstorm/2014/05/phpstorm-8-eap-138-184/