Sammy Kaye Powers has a series of posts over on his site introducing you to testing the PHP language with .phpt tests. So far he's introduced the topic, shown how to run the tests and debugging failing tests.

If you've ever wanted to get involved with PHP internals, writing tests is a great way to get your foot into the door. The tests are written in PHP so you don't even need to know C to get started.

Each of the posts also comes with a screencast, narrated by Sammy, showing the information presented in the tutorial:

On the TopTal site they've posted a tutorial from author André Castelo showing you how to create a Laravel-based RESTful API with functionality that already exists in the framework.

With the rise of mobile development and JavaScript frameworks, using a RESTful API is the best option to build a single interface between your data and your client.

Laravel is a PHP framework developed with developer productivity in mind. [...] In this article, we’ll explore the ways you can build—and test—a robust API using Laravel with authentication. We’ll be using Laravel 5.4, and all of the code is available for reference on GitHub.

He starts off by talking about RESTful APIs, what actions the HTTP verbs represent and a note about consistency in URLs. He then starts in on the project setup, creating a new Laravel application and configuring the database for a Homestead environment. Next he creates the models and data seeders for articles and users for the API. Routes and controllers come next showing how to work with route model binding and response codes to correctly relay the status of the request back to the user. Following this he covers authentication on the API (using a token) and building out the endpoints for login, registration and logging out.

Finally he shows how to test the endpoints using some simple Laravel-enabled testing and PHPUnit. His tests check things like login error handling, missing data on registration and the correct flow on the logout process.

On the Hackernoon site today Sebastian De Deyne has written up a tutorial showing you how to use Watchman to automatically run PHPUnit tests for your application when things change. Watchman is a tool from Facebook that watches files and directories for updates and execute actions based on the changes.

Watchman watches files and triggers actions when they change. The reasoning behing choosing Watchman: it’s easy to install, simple to configure, and reliable.

The watchman-make command - which ships with Watchman - is a specialised interface for Watchman to invoke build tools in response to file changes - exactly what we need!

In the setup he creates, Watchman is used to look for changes on files in either the project's src/ or tests/ directories and execute a bash script (code provided) that runs the tests and outputs the results. He walks through each line of the script and Watchman command, explaining how it works and what the option points to. You can see the results here of an edit to a test and the output in a Terminal window once it's saved.

Fabien Potencier continues his look at what's coming in the next major release of the Symfony framework (v4) in this new post to his site. In it he talks about changes to the default directory structure that Symfony 4-based applications will use.

Symfony 3 came with a slightly different directory structure than Symfony 2. Symfony 4 will also come with a reworked directory structure. Mostly incremental adjustments to support new features and best practices.

The Symfony 3 directory structure introduced a more standard Unix-like directory structure, with less sub-directories. Symfony 4 keeps going in that direction.

There's six changes he mentions specifically, each with a brief summary of what they'll contain:

Tests under tests/

Templates under templates/

Configuration under etc/

Source Code under src/

Temporary files under var/

Web files under web/

He ends the post with a quick note that, while these will be defaults, all of it is optional and these directories will be created automatically if they don't exist.

Colin O'Dell, as mentioned on his blog, has put together the instructions for something he calls "PHPUnicorn" (not to be confused with the PHP Unicorn conference) - a real-time system for visualizing unit test results via a Raspberry Pi, some LEDs and a Unicorn pHAT board.

A simple PHPUnit listener collects test results and sends them to a Raspberry Pi Zero Wireless device in real-time. As the device receives the stats it lights up LEDs green, red, or orange to visualize the progress and results of your unit tests.

The full instructions are over in this article on the Hackster.io site providing you with a list of the components needed, how you'll need to extend PHPUnit with a custom listener and a simple Python script to interface with the Pi and Unicorn board. The end result is a set of LEDs on the board showing the progress (and failures) of your unit tests being run.

On the SitePoint PHP blog editor Bruno Skvorc has written up a tutorial about using the Peridot tool to do BDD style testing but on the units of code rather than the behavior of your integrated application (your business logic).

We’ve done our share of testing posts here at SitePoint, with more coming soon, but I wanted to show you a relatively new testing tool I found that caught my attention because of how unconventional it seemed.

He gives an example of the test structure and how a similar kind of test would reduce down to assertions evaluating your units of code. He also includes an example of Peridot's human-friendly output for both passing and failing tests. He goes on to talk about the concurrency the tool allows, the feature to focus on/skip certain tests, use events and plugins, and output a code coverage report. Several more features are also discussed including custom scopes and the ability to define custom DSL definitions you might find easier to work with in your testing.

On the Delicious Brains blog there's a post sharing some of their knowledge about building tests for WP-CLI packages, a set of command line tools for administering a WordPress installation. Their testing makes use of the Behat testing tool (already in use on WP-CLI's own tests).

[...] In this post we’re going to take a bit of a break from automating WordPress installs and start writing some functional tests to make sure that everything works as expected. While I’ll be writing the tests for the wp installer command, the same concepts should apply for any WP-CLI package.

They start by clarifying the difference between functional and unit tests and how to get your environment all set up and ready to use for testing. They help you get the wp_scaffold_package installed and how to confirm that everything is working as expected. From there it's all about the tests: ensuring that a package is active, creating a custom step to use in testing and an example of what the output should look like.

Sublime Text is a great editor. It’s lightweight, fast, and extremely customizable. However, one downside to it compared to a full blown IDE is it doesn’t come with support for running your PHPUnit tests directly from the test class you are working with.

To solve this problem, Adam Wathan created and released a free package named Sublime PHPUnit that allows you to run your tests from a keyboard shortcut. Let’s take a look at how to add this package to your arsenal.

The post walks you through the installation of the tool (manually cloning the repository) and how to then use it via Sublime's command palette. There's also some instruction on customizing the plugin's setup and allowing for shortcut keystrokes bound to events the plugin provides. The final tip helps you change the tool used to run the tests (the Terminal app by default) over to something like ITerm.

If you're a user of the SwiftMailer package in your application, you may have hit on issues with your unit tests with mocking the library to isolate it from the actual email sending. Joe Ferguson is here to help with some advice in his latest post on mocking the library and how he used it to solve a problem in his own code.

A few days ago an issue came across my Jira queue that mentioned odd characters showing up in the subject line of our notification system. We use SwiftMailer library which is a fantastic library for sending mail.

[...] Something was taking our twig template that we use for our email subject and changing the encoding. This is normally done when you want to convert special characters so they’re not interpreted as code blocks. The example above is showing where an apostrophe is converted to “'”, the ASCII code equivalent.

He breaks the rest of the post into 3 steps (well, really 4 but there's a 2.5 in there) that he followed to mock the library out appropriately and be able to test the message sending without actually having to send. Code examples are included of both the code doing the sending and the test doing the mocking and verifying the subject lines on their emails (the original bug reported).

The main PHP.net page has posted an announcement about the latest Release Candidate in the PHP 7.1.x series being tagged and released: PHP 7.1.0 Release Candidate 5:

The PHP development team announces the immediate availability of PHP 7.1.0 Release Candidate 5. This release is the fifth release candidate for 7.1.0. All users of PHP are encouraged to test this version carefully, and report any bugs and incompatibilities in the bug tracking system.

For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive.

As a reminder, this is a release candidate and is not to be used in production. You can download and test out this latest release from the PHP.net source QA site or the Windows QA site for the binaries. The next release candidate for this version will be released on November 10th with a goal of a final release following that.