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

[Ragazzo]

fixxxer
я же выше описал что поэтому я и использую TDD + storyBDD , т.к. первый больше для unit, а второй если можно так сказать уже больше для тестирования взаимодействия всех компонентов системы, без стабов и моков. Хотя может я и привел не правильный пример для specBDD, т.к. все таки можно думаю также делать ассерты, но основная мысль насколько я понял это уйти от того чтобы слишком смотреть "внутрь". Никто чтоли не использует BDD тут? WTF?

 

[fixxxer]

а чем это лучше написания функциональных тестов на старом добром phpunit?

у меня вот две папочки tests/Unit и tests/Func, не вижу причины менять шило на мыло и вводить еще одну сущность.

 

[Ragazzo]

fixxxer
функциональных на phpunit? ты под функциональными подразумеваешь те же unit только соединив в 1 тесте кучу компонентов? Ну а одним из плюсов является то что читать сценарий гораздо понятнее чем testSuperDuperSomethingWhenItComesToSomething. ну и к тому же ведь все сначала думают как объект будет работать - разрабатывают поведение, потом уже реализацию каждого отдельного действия (тут phpunit), и в обратную сторону все собирается через story. Но мы опять ушли от spec к story.

 

[Ragazzo]

У нас вроде на форуме были рубисты, которые используют rspec, интересно еще их мнение. Absinthe например

 

[fixxxer]

ну да, инициализацию всей хрени в setup (ну точнее во многом в базовом абстрактном functest-е), и дальше testUserCanBeDeleted, какая разница?

 

[Ragazzo]

fixxxer
мы сравниваем tdd и spec или ты про историю? я изначально сравнивал tdd и spec и спросил, как лучше и есть ли разница, т.к. tdd дает чуть больше контроля))

 

[fixxxer]

Не, со спеками я вообще не понимаю, как это использовать в ситуациях когда нужны моки.

Стори хз что там, стори я вообще не знаю, как тестировать не селениумом, на клиенте ж половина. Я про тестирование сложных связок, можно назвать техническими story если угодно. (В теории они не нужны т.к. все должно покрываться юнит тестами, но фактически зачастую проще так, чем добиваться 100% покрытия например тесты на некое паблик апи)

 

[Ragazzo]

fixxxer
да, давай селениум в сторону. Story - обычные сценарные тесты для проверки взаимодействия компонентов системы (не самих методов) а именно поведения. Spec используются так же (это к вопросу как их использовать с unit), т.е. там тоже можно делать моки.

 

[fixxxer]

У меня уже мозги кипят с этих терминов =)
Ну например тестирование базового класса модели в связке с конкретным шардером, конкретной ORM, конкретным кэшером и в заданной конфигурации приложения - это что?

 

[Ragazzo]

я не знаю что такое шардер
а так story, правда пример немного не корректен, т.к. я не знаю что ты подразумеваешь под конкретной ORM, если бы ты сказал "тестирование взаимодействия пользователя с сервисами приложения (абстрагируемся от ORM и т п, всего лишь надо проверить корректность взаимодействия и вообще поведения объектов)" то ok, а то ты описал слишком технически, т.е. у тебя даже истории в данном случае нет, чистый spec получается для того чтобы протестировать отдельно модель и что ты там еще хочешь.
P.S. ну ведь все же смотрели тот пример про боулинг?

 

[fixxxer]

в данном случае пользователь - это программист, которому дали мануал, он пишет по нему компоненты и не смотрит, что там внутри

с пользователем веб-приложения я опять же не очень понимаю - он взаимодействует с системой из браузера, где куча клиент сайд кода. что мы таким образом тестируем то?

 

[Ragazzo]

в данном случае пользователь - это программист, которому дали мануал, он пишет по нему компоненты и не смотрит, что там внутри

ну писать он может и через spec, а вот если

это программист, которому дали мануал, он должен протестировать взаимодействие компонентов по нему и не смотрит, что там внутри

то story.

с пользователем веб-приложения я опять же не очень понимаю - он взаимодействует с системой из браузера, где куча клиент сайд кода. что мы таким образом тестируем то?

дак тестируем веб приложение через тот же selenium, т.е. behat+mink.

 

[Ragazzo]

Чтобы закрыть холивар закончим на том что story/spec + tdd = хорошо

 

[fixxxer]

То есть получается штука для тестирования (по сути) контроллеров (точнее говоря типового кода контроллеров - ведь story по сути это и есть, так)? Я продолжаю это считать извращением. Только если совсем делать уже нечего (или когда не осилен TDD ввиду отсутствия вменяемой архитектуры).

Я вот когда энцать лет назад только знакомился с тестированием, у меня вот что-то такое сначала получалось, быстро понял, что это какую-то я ерунду делаю - а оказывается это я методику тестирования stories изобрел, my ass!!

Ну или я нихрена не понял опять =)

 

[Ragazzo]

fixxxer
Ты опять не понял
никто не говорит что только контроллеры можно тестировать через BDD, даже наоборот ты их не сможешь тестировать, только грубо говоря респонзы от них через behat+mink, если говорить совсем просто то получается как-то так:
Gherkin(описание сценариев)// это уровень совсем для непрограммистов ==>
Behat(+Mink если надо)//это уровень для того кто не особо вдается в компоненты, считай тот пример с боулингом ==>
phpSpec2 (почти замена TDD, хотя говорят как подвид)) )

 

[fixxxer]

Вот смотрю на это я все щас, и в голове только слово "буллшит" =)))

Наверное надо какие-то реальные кейсы увидеть.

 

[Вурдалак]

Да, пусть Ragazzo покажет свои реальные тесты, раз он уже это использует.

 

[AmdY]

Ragazzo
Как я писал выше. вовсе непонятная терминология. если по SpecBDD ещё инфа гуглится, то StoryBDD вообще не находит.

 

[Ragazzo]

AmdY
Да инфы почти нет.

 

[grigori]

этот топик мне напомнил лекцию в институте в середине семестра по сложному, но непрофильному предмету: преподаватель бубнит, уткнувшись в книгу, никому ничего непонятно, всем пофиг и просто ждут следующую пару