At SCL, most of the software projects we have worked on have used PHP as one of the main technologies. As time goes on, we’ve found a set of tools which we reach for every time when starting a new project.
In this article I’d like to briefly introduce these tools and why we like them.
Composer is now the de-facto package manager for PHP. PHP has a vast ecosystem of packages (libraries and frameworks) available for it now, and it’s silly not to take advantage of them.
Another bonus of using Composer, is that it provides a very convenient way to configure the autoloader for your PHP project. By simply adding some JSON like the following to your composer.json file, Composer will set up a PSR-4 autoloader for you:
At SCL, we are very much a TDD company; all our development is done using this technique. phpspec is our PHP unit testing tool of choice. The two main reason we like it so much are:
1. It has a nice BDD style for writing tests
The DSL (Domain Specific Language) for writing tests using phpspec is designed to be easily read as if they are written in English. This makes it easy to express the tests intent.
function it_fetches_a_customer_from_the_repository_by_id(CustomerRepository $customers)
$id = CustomerId::fromString(‘example-customer-id’);
2. Its restrictions encourage an opinionated style of code
phpspec has been designed to drive a specific style of code. It helps you create modular code which adheres to the SOLID principles. The reason it is opinionated is because if you try to deviate from writing this sort of Object Oriented code, it becomes very hard to use phpspec – the idea is, if things become too hard to test with phpspec, then you probably need to fix your design.
3. It automatically generates the code
phpspec will create a new class, method or function for you whenever it can. If you refer to something in a test which doesn’t exist yet it will offer to create it if it can. This is a welcome little productivity boost.
phpspec is our unit testing tool of choice, Behat is what we use for our higher level acceptance tests. Behat is PHP’s implementation of Cucumber.
Behat is a BDD (Behaviour Driven Development) tool. We are big fans of BDD but even when working on projects where we’re not specifically doing BDD with the client, we still find it to be the best way for us to express our high-level tests.
At SCL we like to write pure domain code (by this I mean that we write the domain model without using frameworks). We then utilise appropriate frameworks to build the API/User Interface. When we reach this point, we normally want to use a lightweight framework. In most of our recent projects, we have chosen Slim3. In the past, we used to use Silex more, but with Slim3’s adoption of PSR-7, we’ve been drawn to using that more so that we can take more advantage of the great PSR-7 middlewares which other developers have created.
Dependency Injection Containers (DIC)
There tends to always be a time in an Object Oriented (OO) project where you find yourself reaching for a Dependency Injection Container. There are many great ones available in PHP and given that they all have similar functionality we don’t have a strong preference of one over another. Also, with the introduction of the Container Interop package, it’s easier to swap them out with each other.
Our criteria for choosing a DIC tends to be down to which framework we will be using later on. Silex comes with Pimple (which doesn’t actually comply with the Container Interop package), Slim3 extends Pimple to create it’s own Container-Interop compliant container, and for occasions where we’re not using a framework, we have been known to reach for the Container from the League of Extraordinary packages.
This is a shameless plug for one of my own packages. This package allows you to configure various dependency injection containers using an array of config settings. This enables you to specify your project dependencies and configuration using much more readable code than the APIs provided by most DICs.
We’ve been using this tool on almost every project for quite some time. There’s a really nice level of simplicity that it adds to the codebase.
This popular little PHP library allows you to easily assert that variables contain the expected values. Often we use this to fill in the gaps that the PHP type-hinting system doesn’t cover. As new versions of PHP are released, the places we use this library are decreased, however, I believe there will always be a place for it when more complex assertions are helpful.
We feel it’s important to keep our coding style consistent as it makes it easier for any member of the team to easily comprehend and continue work on the code. PHP-CS-Fixer does a great job of automatically finding and fixing violations in the code. As the sole VIM user in the office, I think I benefit from this the most since PHPStorm tends to take care of a lot of this for the other developers.
- PHPStorm – this world’s best PHP IDE.
- Guzzle – for API testing.
- PHPUnit – phpspec is not always the right tool for the job.
I hope that you’ve found this post a fun read, and maybe learned about a new package or two. If you feel there is a tool which I haven’t mentioned and should try then let me know. Also, if you would like guidance on using any of the above tools, then please get in touch and maybe we can start a blog mini-series on it.