Как я могу заставить JBehave работать с API-интерфейсами, основанными на ожиданиях?

Question

Традиционный способ написания сценария BDD является:

Given [some preconditions] 
When [My code runs] 
Then [some stuff happened] 

Но я работаю с макетом как API, который хочет ожидание (то есть, «некоторые вещи случились»), определенное перед кодом испытываемого запускается , Чтобы быть в симпатии к этому API, я должен написать свою историю следующим образом:

Given [some preconditions] 
And [the expectation that some stuff is going to happen] 
When [My code runs] 
Then [the expectations I defined above were met] 

Я не хочу этого делать. Я вижу два запутано пути вокруг него, что я на самом деле не хочу делать:

• Косвенно создать «любое» ожидание типа в некоторых «Предоставлено» шагах, с помощью «захвата» особенность насмешливый API, чтобы зачеркнуть вызовы в полях и проверить их на шагах «Далее».
• ... или сделать «Когда» шаг установить поле, говоря стадию AfterScenario запустить свой код, следовательно, откладывая его после того, как ожидания были установлены (но предотвращающий меня от проверки других постусловий)

Мне бы очень хотелось, чтобы JBehave посмотрел шаги «Затем», найдите те части, которые задают ожидания, и запускайте их до «Когда».

Спок достигает этого с его издевается (комментарии показывают порядок выполнения):

def translator = Mock(Translator) 

void "test something" { 
    given: 
     testObj = new MyThing(translator) // 1 
    when: 
     def actual = testObj.run("foo") // 3 
    then: 
     1 * translator.process("foo") << "bar" // 2 (setup) 
              // and 4 (post-check) 
     actual == "bar" // 5 
} 

Есть аккуратный шаблон, чтобы сделать JBehave это сделать?

Answer 1

Странно, JBehave 1.0, первый инструмент BDD, имел обыкновение иметь свою собственную насмешливую структуру и привык вести себя так же, как Spock. Это было противно. Действительно, действительно противный (с точки зрения BDD, с точки зрения «строгого макета» это было прекрасно).

Образец был единственным способом, который работал в то время, когда был сделан издевательский каркас, и привел к изобретению Mockito и других «хороших» издевательских фреймворков (и удаление вышеупомянутой издевательской структуры из JBehave 2.0, поскольку она больше не нужна).

Итак, «аккуратный образец» должен написать свой собственный насмешливый фреймворк, если Mockito не выполняет эту работу за вас. Неплохая модель состоит в том, чтобы написать собственную структуру BDD. Имея насмешливую структуру, которая соответствует действительности, обычно проще ИМО.

В качестве альтернативы, вы можете обнаружить, что используемая вами фальшивая фреймворк имеет «хороший» режим или позволяет объявлять окурки, а не макеты, что может помочь. Не зная, какие рамки вы используете, трудно сказать.