Nikola Posa has a quick post to his site showing how to use a mocked up HTTP request handler - in this case Guzzle - for testing web API clients. These scripts make live HTTP requests to remote APIs as a part of their functionality but this presents a dilemma for testers. Unit tests should not reach out to external sources...and that's where the mock comes in.

Whether you're writing a client for your own web API to offer it to users or you're simply implementing integration for a 3rd-party API in your system, it is important to test it to make sure your client is capable of handling actual API responses correctly.

Testing web API clients is mostly about checking how they deal with responses received after sending requests to API endpoints, and for your unit tests, you introduce test doubles to simulate API calls instead of executing real HTTP requests.

He starts with a quick note about the usual way he's seen this issue worked around, creating a separate mocked class instead of using the actual tool. Fortunately, if you're a Guzzle user, there's a tool that comes with the HTTP client that can be used in your unit tests in much the same way as a normal Guzzle instance: the Guzzle MockHandler. He includes some example code showing how to use this class and inject it into your client and use it in much the same way as a normal client instance.

The Yappa.be blog has a tutorial posted sharing the method they used to implement queued and scheduled execution of Symfony commands. This is made possible by the Enqueue package.

At Yappa, we have always used Johannes' JMSJobQueueBundle to run and schedule Symfony console commands for background jobs.

However, we've stumbled upon a much more elegant solution called Enqueue. [...] It's packed with features, supports major brokers such as RabbitMQ, Kafka, Amazon SQS, Google PubSub, Redis etc. and has a bundle ready to be used with Symfony.

[...] One downside is that the Enqueue Symfony bundle doesn't provide an out of the box solution to queue Symfony console commands and there's no 100% straight forward way to implement this. In this post I'll cover the basics in setting up the Enqueue Symfony bundle so we can easily queue Symfony console commands!

The tutorial then walks you through the installation of the Symfony bundle, adding it to the list of installed bundles and configuring it with basic parameters and queue connection details. Next they've included the code to create the processor used when a command is pushed to the queue. To handle the other side (execution of the command when the queue is handled) they create a "QueuedCommand" value object and a command handler class. With this structure in place they show the addition of test commands to the queue and the result when the queue is consumed.

On the Zend Framework blog today project lead Matthew Weier O'Phinney has posted an announcement about the latest (alpha) release of the Zend Expressive framework: Zend Expressive 3 Alpha 3.

Today, we pushed the final changes and fixes that culminated in the Expressive Installer and Skeleton 3.0.0alpha3 release!

The alpha releases have a ton of great features; keep reading to find out more!

The post then walks you through the installation process (slightly different since it's an alpha) and shows the creation of a sample middleware via the command line tooling. The tutorial then shows the creation of a request handler and how to configure it in the router. The post ends with a look ahead it what's next for the framework on its roadmap including several features that need completion before v3 of Zend Expressive can be called complete.

In a new post to his site Matthew Weier O'Phinney, lead developer on Zend Framework and representative in the PHP-FIG, covers the acceptance of PSR-15 by the group. PSR-15 relates to the creation of server request handlers and middleware that can use PSR-7 formatted messages.

Yesterday, following a unanimous vote from its Core Committee, PHP-FIG formally accepted the proposed PSR-15, HTTP Server Handlers standard.

This new standard defines interfaces for request handlers and middleware. These have enormous potential impact on the PHP ecosystem, as they provide standard mechanisms for writing HTTP-facing, server-side applications. Essentially, they pave the way for developers to create re-usable web components that will work in any application that works with PSR-15 middleware or request handlers!

He starts with a bit of background around the initial idea of the standard and some of the discussions that came up around it. The initial draft of the standard was modified to more correctly handle issues around response modification and the use of "handlers" for request/response manipulation. He then covers the final version of the standard, defined in the standard's documentation and enforceable via the psr/server-handler interface. Finally he covers how to use this to create re-usable middleware and an example using Expressive.

In a post to his site Robert Basic continues his series looking at the Phrooph package, this time focusing on the query bus. This functionality allows you to dispatch an event to a single "finder" in the CQRS/event souring framework.

Continuing on with the The query bus allows the handler to do whatever it needs to do to return the result, synchronously or asynchronously.

He starts by talking about the return value of the bus - a ReactPHP promise for the async handling - and the plugin system that allows for more advanced handling. He then starts on the example, showing how to create a simple bus object and define the routing to a specific query handler. This is then dispatched and a closure is defined as the "done" operation. From this basic example he then moves to something a bit more useful - an example query to determine how may Calls for Papers are currently open on the Joind.in service (fetched via the API).

Rob Allen has a new post to his site showing how you can customize the Whoops output in a Zend Expressive application. Whoops is a package that provides more well-structured and more attractive error output when an issue comes up.

I find the Whoops error handler page in Expressive quite hard to read and particularly dislike that the error message displayed in the top left is hidden if it's more than a few words long.

To fix this, I discovered that you can provide a custom CSS file to the PrettyPrintHandler and then override to your heart's content! One way to do this is to add a delegator factory to add the additional functionality, so let's do that.

He then includes the configuration changes you'll need to make in the Expressive setup to have it recognize the factory and be able to use it as a dependency. He then includes the code to create the factory itself, adding a path to the local CSS files and pushing the custom whoops.css file into the page handler. Example CSS is included showing an update to the display of the main message, removing the need for a mouseover to view it.

In a post to his site Jen Segers says "goodby to controllers" in favor of request handlers. Request handlers are a concept similar to the ideas in the ADR pattern but are defined a bit differently.

If you have worked on large applications before, you might have noticed that you end up with bloated controllers sooner or later. Even if you use repositories or service classes to extract logic from the controller, the amount of dependencies, methods and lines of code will grow over time.

Let me introduce you to request handlers. The concept is very simple, yet very unknown to a lot of PHP developers. A request handler is basically a controller, but limited to one single action.

He suggests using invokable classes to build out request handlers in your PHP code, making use if the magic __invoke method to make them callable. He gives a "hello world" kind of example and talks about how Laravel and Slim already implement this idea in their routing. He then looks at how these responders help you adhere to the Single Responsibility Principle (part of SOLID) and how they make the code easier to test and simpler to refactor.

On the Laravel News site there's a quick tutorial posted showing you how to send an email when an exception is thrown in your Laravel-based application using the "mailable" functionality.

You’ve created a new Laravel app for your client and deployed it on the production server. Everything was working fine till a customer has a problem with the app because of some buggy code. He immediately leaves the app, and the same thing happens with multiple customers before you know about the bug. You fix the bug, and then everything is on track.

But what if you were notified immediately through e-mail (or another service) about the bug and you fix it ASAP. In Laravel, this can be done easily and in this post, we’re going to learn how.

The post talks about how errors and exceptions are handled in Laravel applications and how, with a bit of custom code, you can create you own handler and a "mailable" class it can use (an ExceptionOccured mailer) to send a full stack trace when an error is thrown. There's also a link to a package that can be installed that helps to make setup even easier.

The Master Zend Framework site has posted a new tutorial for those out there looking for a bit more from their error handler than just some basic text. In this tutorial Matthew Setter introduces you to the Whoops error handler and how to use it in your Zend Expression application.

Ever experienced HTTP 500’s, but found that your error logs are empty. Ever had no clue why or how this could be happening? Perhaps you forgot to enable the Whoops error handler.

That’s right, perhaps, when you were setting up a Zend Expressive application, you made the mistake which I made recently when you used the Zend Expressive Skeleton Installer. [...] If you chose n, and used a templating engine, then TemplatedErrorHandler, would have been used as PHP's default exception handler.

As a result, no exceptions will be written in your logs. Sure, you’ll see that a 500 error has occurred somewhere in your application. But, the only information you’ll have is [a simple 500 error message].

He notes that the next step for most developers is the log files, trying to find a hint there of what might have broken. If you chose the default logger, nothing will be there as it captures those issues and pushes them to the basic error template (but doesn't output them). He points to where in the configuration you can check to see if you enabled the Whoops error handler and how to test it after you've made the switch. The reason the default is the basic message is that, in production, you don't want information exposed and log messages/code shown to just anyone - that's a big security risk.

Loïc Faugeron continues his "Mars Rover" series of posts today with the latest in the series covering the "Locating" handler, the functionality responsible for handling requests for the rover's location.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD)

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location

He makes use of the command bus pattern to create the handling for the module, doing validation in the Command object and a Bus to handle the command and perform its task. He starts, as usual, with the phpspec tests defining a class that can use a "find latest location" type instance and a "find" method to abstract out the location repsonse.