Why Behaviour Driven ? Why Behat for APIs ?

I was asked today why did I choose Behat for REST APIs behavioural testing over other online tools. Here are few points.

1. Monitoring Tools:

Any tool that have no requirement to write code are more likely to be monitoring tools. They will show the status of repsponse (200 for example) and will test some content in it. (Json mostly, don’t know about XML)

For that any of the tool can be used example: postman



1. Can run them in prod env for monitoring.


1. Doesn’t really give developer a confidence to merge and realease the code. Starting ‘Pray Driven Development’ culture is no good just because it doesn’t always work.

Why To Automate:
1. Build up confidence to merge and release.

2. Regression Testing. In every sprint, manually testing everything is not possible. We have to rely on automation for regretion.

3. There is always a chance, fixing one thing breaks up another. Without Automated Tests, developers wouldn’t be able to re-factor the code, introducing duplicate spaggetti.

Why Behaviour Driven?

1. It’s NOT a testing tool. It’s communication tool. Specially for APIs, where there is no UI involved, it’s even more suitable.

What? Not testing Tool? Communication Tool?

Yes. Before we start coding, on the planning Phase, Product Owner, QAs and Developers should sit down together and write the BEHAVIOUR of the application together. Like in code review, we discuss on each line of behaviour, refine them and try to capture all the scenarios possible.

We ask question, what if ?, why? and provide examples (eg: Examples of request, data, user behaviour, different type of input tools) and make sure every thing is captured.

We don’t have automate them? – YES, TRUE.

We don’t have to automate those scenarios. We can follow manually all those steps to test. If software is too small or has short life, this is actually recommended, not to automate tests.
But it makes sense to automate those scenario to save the time for future when software grows big. And that automation becomes then behaviour testing.

It’s same as many years ago, computer was developed to calculate population. When there were 200 people around country they didn’t need it. Then they became 20 million, they needed something. Then they wanted to know, how many men and how many women, educated/not educated, age group… ah…. wasn’t possible manually. Computer automation was a need.  :)
Why Behat for Behaviour Testing?

Behat is written in PHP, it’s mature and have awesome community behind it. They have meet up every 2 months and the people behind it are accessible. And it’s free. More importantly, it works great with symfony.


So, this is enough for a developer to be confident that software does what it is intended to do, and I, as a developer, have not broken existing working functionality, it’s one of the best tool available.

What this doesn’t do is:
1. Test UI/Styles (depend on how we write it. You can write it to do that too using Selenium driver for UIs)
2. Magically test everything without writing right features/scenarios/examples

Communication tool will not comminute to people. People need to communicate using the tool. :) Having a telephone doesn’t mean, I’m connected to people. I need to be able use telephone to connect to right people.

So Why Not monitoring Tools then? Why Other tools:

We need to be able to run the test before we push and merge the code. if 3 devs commit something, and failure appears once we push things to Live/UAT, thats not fun. We will have no idea, when and who and why something is broken.

Monitoring tools are used when multiple webserver under load balancer are serving and to make sure all the servers has same output and all are working well.

Test tools are to test the software.

This entry was posted in BDD and TDD. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>