I’m a huge fan of PHPSpec, and its close cousin, Behat. I find when writing code in conjunction with PHPSpec, I am able to enter a rhythm that I have never found with any other tool.
I particularly enjoy the code generation functionality – describe some action, do a
bin/phpspec run and have your methods created for you as you go. It really is quite a joy to use.
However, as with any tool, there is a learning curve.
I found the basics – the stuff described in the manual – to be straightforward enough that even when stuck, I could relatively quickly find my way through and get back on track.
Then, recently, I decided to build an application involving third party / social media providers for authentication using HWIOAuthBundle.
Along the way, I added the concept of a
User object having a Collection (
Account objects. Fairly common stuff, particularly if you have ever used Symfony at all.
This is absolutely a work in progress. I even left in the last test, yet to be started.
As a quick side note, for the first time I have decided to declare commonly required objects by way of the
let() method. I am not absolutely sure whether or not this is good practice, but it does seem to work as I intended it too. If you know differently, do let me know by way of leaving a comment – thanks !
Currently the tests are passing – with the exception of the pending example still to write.
What may be less obvious is how much effort I went through to get the
it_can_connect_one_account_to_a_social_media_service() example to play ball.
I’ve spent a good few hours these past few evenings trying to figure out this error:
51-it can connect one account toasocial media service
warning:array_key_exists():The first argument should be eitherastringoran integerin
When I think about it now, it does make sense. This is similar to what I was trying to do, only this way conforms with the way PHPSpec expects me to behave 🙂
Profile objects are properly mocked, but as per Everzet’s comment, we are returning a real ArrayCollection, which by way of
$profile->getWrappedObject() will return the underlying
Profile objects, rather than the PHPSpec wrapped objects / Object Prophecies.
This is exactly the sort of problem that my brother – an aspiring coder – would think I “just knew” how to fix. And that he should also be expected to know how to solve instinctively also.
Of course, the next time this comes up, I will know exactly how to solve it. It’s just if you were sat watching over my shoulder, you wouldn’t imagine the hours of my life that lesson took to learn 😉
Behaviour Driven Development (BDD) with Behat 3 is a thing of beauty. When combined with PHPSpec you get something I am hugely excited about.
However, there are many ways in which BDD can be daunting not just for the new-comer, but for a new project in general.
Once you have a feature or two written up, copy / pasting and doing a little editing can yield quick results but writing the code that lives in the underlying Feature Context can be a little harder. For me, this was most evident when dealing with Scenarios that contained tabular data.
I made myself a little Behat TableNode cheat sheet to help – at a glance, and whilst in my IDE (PHPStorm btw) – figure out just what might be in my TableNode objects for the specific methods available on that class.
This is an example of the scenario I was working with:
Behat 3 TableNode var_dump
Given the product with id:3has the following values:
Hopefully this is as useful a reference to you as it has become for me. Being able to quickly ‘guess’ what is going to be in my TableNode objects and where has helped save me a good deal of time already.