BDD is an established practice which goes beyond test-driven development, assuming we are working on a agile-prone environment and our requirements are expressed as user stories or something similar: although this requirement is not mandatory, BDD’s power is leveraged by using stories.
It basically assumes that instead of focusing on tests, we should start our development process writing down a story that a parser can translate into a test (a customer cares about features, not tests) a programmer can implement in order to verify that our software respects that story.
It’s a pretty unconvenient question :)
Do you know why TDD is extremely powerful? If not, go check it on the web; if so, add to TDD the ability of writing tests in a ubiquitous language, letting the team share tests, user-stories and acceptance criteria without the pain of translating an actual story in a functional test that, for example, a customer could never understand.
Although you can use Cucumber in your PHP projects (the implementation of the tests, however, should be written in Ruby), Behat is an excellent project which brings native BDD in PHP.
You can – and I recommend it – install it via PEAR: just make sure you have all the required dependencies by running a simple
after the installation: we had our daily WTF last week because Mink, a browser-emulator abstraction layer required by Behat, wasn’t properly installed.
The integration with symfony 1.4
1 2 3 4 5 6 7
and then you can run
from the root of your symfony project: no tests, so let’s write something!
In symfony, behat’s tests are located under
/test/features, and are a
.feature file, looking like:
1 2 3 4 5 6 7 8 9
So, let’s examine it:
- this “code” should be located in the
Featureelement defines the story you are working on (write it as it appears in your backlog)
Scenarioblock identifies possible declinations for your story (user logs in with good credentials, user tries to log in with incorrect credentials and so on)
- the sentences inside every scenario are the actual testers which are parsed by behat and translated in actual PHP code
Translated in actual PHP code?
Yes, because you have a
FeatureContext class in which you define some methods that are your tests’ implementations: BDD frameworks usually parse your scenarios’ lines generating the code you need to implement.
Behat, for example, stores all its testers in the
FeatureContext class, and when you write a new scenario, if Behat doesn’t know its syntax, it outputs something like:
so you only need to copy&paste the method in your
FeatureContext and implement the method with your logic.
Obviously, BDD frameworks have a set of predefined testers: you can see Behat’s ones with
you will see testers like
I should see [...] which tests if the given text lies in the response.
Producing ubiquitous documentation
The cool thing is that, when you run your BDD test suite, you can export it in a fancy way, making it readable for every project’s stakeholder:
obtaining something like:
I won’t be exhaustive, so what’s next?
No focus on how to use (deeply use) Behat here: it will be a matter of another post.
Then we will see how to use capifony to automatically deploy your symfony applications and produce acceptance criteria tests that will be used by your QA guys in order to test your brand new deployment.