In this post to his siteAmine Matmati shows you how to use Behat (with a bit of additional PHP) to test the contents of a rendered PDF file.

If you have a PDF generation functionality in your app, and since most of the libraries out there build the PDF content in an internal structure before outputting it to the file system (FPDF, TCPDF). A good way to write a test for it is to test the output just before the rendering process.

Recently however, and due to this process being a total pain in the ass, people switched to using tools like wkhtmltopdf or some of its PHP wrappers (phpwkhtmltopdf, snappy) that let you build your pages in html/css and use a browser engine to render the PDF for you, and while this technique is a lot more developer friendly, you loose control over the building process.

He shows how to get all of the required software installed including the smalot/pdfparser library used to read in the contents of the PDF file. He initializes a Behat test directory and writes a simple test, checking for a string of some "Lorem ipsum" text in the document's title and that it contains only one page. Some additional methods have to be created to integrate the PDF parsing and string location/page counting and code is included for each. When all the pieces are put in place, executing the test passes for both checks. You can find the code for the tutorial in this repository that also includes two sample PDFs to work with.

The ServerGrove blog has posted an introduction to the PHAR format, a built-in method to use PHP and create self-contained functional scripts as a single *.phar file making it much easier to transport.

In the last years there is a trend in the PHP community to release tools, especially command line utilities, as PHAR files, so you can package an entire PHP application into a single file for convenience. But, how PHAR files work? In this post we will try to explain it.

They cover a few of the basic topics first: what is a PHAR file and a few examples of them being provided by major PHP projects. They then get into the creation of an archive, showing how to make a super simple PHAR "Hello World" archive, created with just a bit of PHP. They then get into the structure behind the archive and get into detail on each section (stub, manifest, file contents and signature).

The PHP Town Hall podcast has released their latest episode today: Episode #43: Midnight Madness with hosts and PHP community members Phil Sturgeon and Ben Edmunds.

Your two favourite PHP developers are joined this episode by Emir Kar??yakal? off of PHPKonf and IstanbulPHP. Istanbul is not only a beautiful and awesome city, but it’s got a thriving PHP community too, who are currently hosting a whole bunch of PHP stars for their annual conference.

Davey Shafik has a post today that talks about an exceptional change to PHP 7.0 and some updates that have been made to provide more of a hierarchy (a different one) that can make them easier to work with.

With PHP 7 errors and exceptions are undergoing major changes. For the first time, the PHP engine will start to emit exceptions instead of standard PHP errors for (previously) fatal, and catchable fatal errors. This means that we can now handle them much more gracefully with try... catch. But with this change, comes a whole new exception hierarchy.

He provides a tree of the error/exception relationships, what they inherit from and who their "children" are. He also talks more in detail about the "error" type exceptions: Error, AssertionError, ParseError and TypeError. He gets into more detail about catchable fatal errors and the userland handling of the Throwable type and extension.

Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).

On the Drupalize.me site they've posted a guide to getting started with Drupal 8 based on the boilerplate code that already comes with the release.

Drupal 8 represents a lot of changes and a steep learning curve for many Drupal developers and themers. While many of these changes are exciting, there are many things to learn just to get started. One way to learn about the code involved with Drupal 8 modules and themes is to take a look at core's modules and themes for examples to follow. Another is to use a code-scaffolding tool like Drupal Console to generate boilerplate code and comments that you can learn from and then customize.

He makes the assumption that you already have a development environment set up and working then helps you install the Drupal Console for use in the rest of the tutorial. You can then use this command line tool to create a new Drupal 8 installation and generate the boilerplate code for a new theme. Finally, they show the creation of the two other related components: a new module and a block plugin instance. These are generate generic code you can use as a reference point for either updating your current Drupal projects or create new ones.

The Platform.sh blog has a post showing you how to create flamegraphs with XHProf for your application's execution and overall performance. A "flamegraph" is just a different sort of graph stacking up the execution times for the methods and functions in your application so they look more like a "flame" than just numbers.

One of the most frequent needs a web application has is a way to diagnose and evaluate performance problems. Because Platform.sh already generates a matching new environment for each Git branch, diagnosing performance problems for new and existing code has become easier than ever to do without impacting the behavior of a production site. This post will demonstrate how to use a Platform.sh environment along with the XHProf PHP extension to do performance profiling of a Drupal application and create flamegraph images that allow for easy evaluation of performance hotspots.

While they show it at work on a Platform.sh instance, the method can be altered slightly to work with your own application with the right software installed. Their example uses the brendangregg/FlameGraph library to do the majority of the graphing work. He shows how to have the code switch on XHProf during the execution and where to put the file for later evaluation. They include the resulting directories and files created from the execution and how to view the resulting (SVG-based) graphs directly in a browser.

In this tutorial posted to the SitePoint PHP blog Younes Rafie shows you how to combine Selenium with PHPUnit to do acceptance testing on your application. Where PHPUnit and unit testing is more about testing the "pieces" of your application, acceptance testing it more about checking the interface and functionality for correctness according to requirements.

Testing is a really wide subject, whether it be unit testing, functional testing, acceptance testing, etc. In this article, we’re going to see how you can do acceptance testing using Selenium. I will use a practical example to illustrate a real use case. I will assume that you already know how to do unit testing using PHPUnit, or that you at least have a grasp of what it’s all about.

He starts with a few definitions around what acceptance testing is and how Selenium can help in performing these evaluations. He uses a simple user registration page for his tests and includes commands to get PHPUnit+Selenium installed as well as an alias to start the Selenium server. He then creates a first test case, setting up the Selenium "browser" to use in later requests. He then gets to testing the page itself, setting up some data providers for the content to inject into the form both valid and invalid. He shows how to work with the DOM inside of your tests and making both a valid and invalid form submission. He also shows how to use a different browser (he defaults to Firefox) and how to check of the current document is ready for evaluation, that is if all Javascript has fired and finished.

Doctrine is currently the most used ORM in PHP. It makes it very easy to work with databases in an object oriented way. It comes with a set of built-in column types that map database types with PHP types. For example, the datetime column type, persists the value of an entity column as a datetime in the database and handles it as a DateTime object when the entity is hydrated.

Type conversions work both ways, so column types take care of casting database to PHP types and vice versa. In this article I'm going to explain how to define custom column types so that we can persist our own objects into the database and hydrate them back.

He points out that, while PHP itself lacks the "enum" data type, you can simulate it with a library like this. He uses this library to create a custom Doctrine object type that mimic enums in the getting and setting of a value to one of a few options. In this case it's values representing the CRUD methods. He shows the code to link the Type back to the Action which then gives it understanding of what the valid enum values can be. He also points out another package that he published recently that takes some of the work out of creating the boilerplate code for the enum.