BDD and Behat for a php script

Question

I'm creating a php script, which should process the POST data it receives (from AJAX or else) and send it further (to another script). I'm wondering how to develop it in a "BDD way".

So far I've done the "processing part" by writting features with Behat and created the required blocks (classes) using phpspec .

But then I'm blocked when it comes to testing those following features:

• the script only processes / accepts POST data,
• the script sends only valid data further after processing,
• the script sends back errors in case of invalid data.

It seems to me that I could write the tests against the script itself, but then I'm wondering:

• if it's a good idea (it does seem simple enough but a bit messy though because there is not much isolation)
• how to do this elegantly in behat (it seems messy for me to have to manually run my local server and have its url hardcoded in my tests / contexts, but maybe it's just the way to do it)

Any ideas or suggestions?

Answer 1

BDD:

Let's try to change your mindset a bit. The BDD is about a collaboration and the automation part (tests) are only the last part of it.

Your acceptance tests, this is what you do via Behat, should only cover a specification of your feature via examples. It means, don't focus on testing of all possible scenarios like you would do via unit/integration tests but specify only the minimum which describes your feature enough to be revealing the intention of that feature.

In most cases, the examples cover only positive scenarios and 1-5 are enough.

Little help here. Ask yourself, what would you mention if these examples would be a part of a documentation for customers? The specification by examples is no more no less than the documentation of an application which has an ability to be automatically tested.

Testing level:

Unfortunately, I don't know the technical background of your script so the answer will be more a theory.

There are more levels of acceptance tests and the higher you test the more you cover but the more expensive is their creation and maintenance:

1. UI
2. HTTP request via infrastructure
3. Initiate the application and inject a fake request
4. Call a controller directly
5. Call an application service which is processing the domain logic

There is my personal practice. Because BDD is the best with TDD, I always start with the point 5), and sometimes, I also add the higher level 3) to be sure that the application works correctly as the whole. I use levels 2) and 1) very rarely as I don't need to test my infrastructure via acceptance tests, it's not their purpose.

Answer 2

This is more of a comment rather than a proper answer, but it would not fit well in a comment either...

So first thing, good that you're trying to test all the things . But in order to do BDD (hence using Behat), there has to be some sort of benefit for a stakeholder or part of the business with who you should have a conversation about the feature at hand.

The fact that you're just describing a script that receives a particular input and transforms it into a particular output, sounds pretty much what you'd expect from a Unit test, right?

On the other hand, if this particular script is solving a stakeholder's need and there's a story or scenario that this script is helping to satisfy, I assume that there would be some sort of change in the state of the system which you can test for. If so, then go ahead and describe it using Behat, having a conversation with the appropriate stakeholders. I guess that you'd need to set up an environment for your system in which you'd then run your script and then check that the state of it has been changed appropriately.