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

[Ragazzo]

Можно устроить небольшой холивар конечно, но меня интересует следующее - по сути в идеале specBDD должно заменять TDD, т.к. основывается изначально на поведение объекта, но что-то во многих примерах для spec все слишком гладко и просто, может я конечно не дорос, но все же, пример простой ситуации (пусть будет удаление пользователя)

//TDD
public function testDelete()
{
    //load fixtures
    $this->assertInstanceOf('Users',$user);
    $this->assertTrue($user->delete());

    //check that user is deleted
    $this->assertNull(Users::model()->findByPk($user->id));
}

//specBDD
public function it_can_be_deleted()
{
    $user->delete()->shouldReturn(true);
}

Да, понятно что мы тестируем лишь поведение и лезть внутрь нам не стоит, но все же, надо убедиться что тот же пользователь например удален. Т.е. получатеся TDD+specBDD или все же TDD=>specBDD ? Конечно хорошо когда ты начинаешь проектировать систему именно с того как объекты должны себя вести и т п, а не с тестирования несуществующих методов, и в том и в том есть свою плюсы, но заменяет ли specBDD полностью TDD хочется поинтересоваться у тех кто использует)?

 

[AmdY]

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

 

[Ragazzo]

AmdY
ну я для себя выбрал storyBDD + TDD, т.к. все таки spec больше описывает саму реализацию грубо говоря а не взаимодейтсвие компонентов системы. Ну хрень то удобная spec, странно что ты говоришь

непонятно для кого деланная.

вон у рубистов rspec же и радуются)

 

[AmdY]

Ragazzo
собственно ребята-рубисты, пользующие кукумбер и лажали. его хорошо втюхивать. а вот польза весьма сомнительная.
кстати, вот один из авторов рельс
http://37signals.com/svn/posts/3159-testing-like-the-tsa

Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you’re there!)

 

[Ragazzo]

AmdY
ну в статье написаны капитанские выводы вида: не старайтесь покрыть 100%, не тестируйте контроллеры и т п. кукумбер хорошая вещь, кстати насколько знаю specphp именно вырос из впечатлений от rspec )
P.S. что-то как-то мало людей отписалось, неужели никому не интересно?)

 

[Gas]

мне кажется BDD мало распространено в среде php developer'ов, по этому такой интерес к теме.
я специально тему не рыл, но по статьям на хабре не совсем понял в чём его плюсы над unit/functional тестами (о том что клиенты будут писать какие-то тесты, так вообще офигел, с них 2 абзаца текста не выбьешь, а тут тесты (или кейсы для них) пусть и каком-то простом формате.

наверное я всё-таки не понял суть bdd, но не страдаю от этого )

 

[Ragazzo]

Gas
если кратко то это те же unit но с другой стороны. funcional вообще не клиенты пишут а ты) ну и смотря что различать, т.к. есть functional а есть acceptance, таким образом получается что грани уж очень тонкие, т.е. functional это не всегда selenium+phpunit.

 

[Gas]

funcional вообще не клиенты пишут а ты

Это да, я говорил о behavior тестах.
Может и ошибаюсь, но кажется в нескольких статьях читал что заказчик может сам описывать кейсы для behavior тестов, чему сильно удивился, так-как не встречал заказчиков готовых тратить своё время на такой микроменеджмент, им всё подавай на вчера и чтоб работало, а чем достигается работоспособность - тестами-шместами, святым духом или честным словом их не волновало (да, понимаю, что не всегда так).

 

[Ragazzo]

Gas
я не знаю что такое "behavior" тесты но так понимаю что это приемочные тесты, возможно в статьях имели ввиду под "case" это что сам заказчик должен и хочет видеть при переходе по каким-либо ссылкам и т п на своем сайте, впринципе все эти кейсы в ТЗ оговариваются же)

 

[AmdY]

Ragazzo
Здесь как раз проблема в том, что эти тесты должен кто-то писать. В идеале это клиент-продукт оунер, а в реале кладётся на плечи автоматизаторам, которым проще нахлабучить полноценный тест на селениуме(который и так придётся писать), чем стараться влезть в ограничения человеческого языка.

 

[Ragazzo]

AmdY
ну да, но мы ушли от specBDD темы но впринципе я не вижу проблемы в том что в "нормальной" фирме есть тестеры которые и будут писать те же приемочные/функциональные тесты.

 

[Gas]

похоже какие-то разногласие в терминологии
под "behavior тестами" я понимаю специальный формат описания тестов для Bdd-фреймворков (cucumber, behat)

например, по этой ссылке есть пример:

Feature: Addition
    In order to avoid silly mistakes 
    As a math idiot 
    I want to be told the sum of two numbers

    Scenario:
       Given I have an calculator
        When I have entered 30 as first number
         And I have entered 20 as second number
         And I press 'Add'
        Then The result should be 50

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

 

[Ragazzo]

Gas
это storyBDD, BDD = = behavior DD

 

[Gas]

ok
ладно, я в этом "плаваю", посему писать пока ничего не буду )

 

[Ragazzo]

Gas
<sarcasm>Пфф.. ну да тут же спецы прям собрались в топике</sarcasm> )

 

[AmdY]

SpecBDD and StoryBDD http://www.phpspec.net/#specbdd-and-tdd

WTF ? Я думал о BDD, а оказывается это ещё одни наркоманы, которые покурив родили идею. Судя по примерам это ниочём?

 

[Ragazzo]

AmdY
что значит наркоманы? вообще то да, почти везде в языках BDD разделяется на spec/story, в чем проблема? ссылка "на почитать" )) Да и не путай формат описания, тот же gherkin и само BDD.

 

[fixxxer]

Я вот не понимаю как этим пользоваться.

//specBDD
public function it_can_be_deleted()
{
    $user->delete()->shouldReturn(true);
}


// implementation
class User {
    public function delete() {
        return true;
    }
}

и?

TDD дает представление о том, как работает юнит, позволяет проектировать API. BDD же дает только представление о том, что "delete должен удалять" (спасибо, капитан!) - я не вижу, чем это расширяет TDD, в котором это уже и так предусмотрено вместе с остальным. А если не расширяет, а вместо - что делать с примером выше, и как понять в каком юните косяк? Если это функциональный тест - во-первых, никто не мешает их писать на обычном phpunit, во-вторых, не тестирует браузерную часть все равно, так что скорее нужен selenium.

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

 

[Ragazzo]

fixxxer
в этом и был вопрос, это новый этап эволюции

 

[fixxxer]

Я не вижу эволюции в отходе от архитектурных вопросов и подходе "пофигу какой говнокод, лишь бы работало".

Судя по тому, что ноги растут из рельсов, у меня вопрос к тем, кто на них писал - а там вообще моки реально без баттхерта писать? Может в этом все дело?