The basic idea behind a Page Object is that you get an object oriented representation of your website. The Page Objects maps the HTML (or JSON) to an object oriented structure you can interact with and assert on. This is more initial work then than writing tests with PHPUnit and Mink directly, but it can be worth the effort.

They use the Mnk testing tool to simulate a browser and some previously shared functionality to lay the foundation. From there they write up a first test using a "Login" page object and processing the username/password handling of the page. They show how to implement a custom page object with a bit of additional logic and put it to use in processing the request. They also include an update when, for example, a site is switched from Twig templates to a React.js component and how the Page object would need to be refactored for the update.

Vic Cherubini has written up a tutorial on his site showing you how to write functional tests for Symfony services in your application. He provides a practical example of testing a basic Symfony service and the configuration/code to go with it.

The dependency injector is an amazingly simple and flexible addition to Symfony, and one you should be using to properly structure your application. But what happens when you want to write a functional (or integration) test for a service that depends on another service? This article will show you an easy way to test complex services.

He sets up a simple InvoiceGenerator service that takes in a Doctrine entity manager and a "payment processor" instance. He stubs out a simple PaymentProcessor class and shows the configuration needed to set it all up for correct injection. He then gets into the testing of this setup, creating a simple test case that requests the invoice generator from the service container. In this call the services_test definition overrides the default and injects the test payment processor instead of the actual one.

The Toptal.com blog has posted a new tutorial that wants to help you make the most of your application via testing. They show you how to use Codeception to create a set of tests to ensure your application is working as expected.

Before moving on to Codeception and PHP, we should cover the basics and start by explaining why we need testing in applications in the first place. Perhaps we could complete a project without wasting time on tests, at least this time?

Sure, you don’t need tests for everything; for example, when you want to build yet another homepage. [...] However, you definitely do need testing when: your team uses BDD/TDD, your Git repo contains more than a couple commits, [and] you are a proper professional, working on a serious project.

They start with a look at the kinds of things testing solves in your development process and the different kinds of tests you can create. From there they introduce Codeception, an alternative testing tool to the widely used PHPUnit. The tutorial helps you get it installed and shows you how to make a simple, first test. It helps you execute the test, debug issues that might pop up and the different assertions you can use. With the fundamentals in place, they move on to more details on using it for functional and unit testing.

On the SitePoint PHP blog they've posted a tutorial showing you how to work with transducers in PHP. Transducers are pieces of functionality that allow you to transform data in a reusable way.

Have you heard of functional programming, high order functions, etc. before? Probably, right? However, when you hear “transducers”, do you know what those are? [...] A reducing function is just the kind of function you’d pass to reduce – it takes a result so far and a new input and returns the next result-so-far. A transducer is a function that takes one reducing function and returns another.

Transducers were first introduced into Clojure by Rich Hickey, and ported to PHP by Michael Dowling. Transducers are a powerful way to build algorithmic transformations that you can reuse in many contexts. In this article, we’re going to take a look at how they could be useful through a set of practical examples.

They help you get the mtdowling/transducers library installed via Composer and include a simple example using a User instance and uppercasing the first letter of the user's name. Other examples of the transducer functionality are also included such as: converting values to strings, filtering and composing sets of multiple transformations. The tutorial also shows you how to extend the current functionality and create your own transducer class (their example drops null values).

[...] However, these functions only work with standard PHP arrays; so if we are using Generators as a data source instead of an array, then we can’t take advantage of the functionality that they provide. Fortunately, it’s very easy to emulate that functionality and apply it to Generators (and also to other Traversable objects like SPL Iterators), giving us access to all of the flexibility and power that mapping, filtering and reducing can offer.

He starts with a more "real world" example of using a generator in a handler for GPX files, XML files storing GPS data. He gives an example of the typical file contents and shows a simple generator script (class) that he uses to grab chunks of the file at a time instead of reading it all in and parsing it from there. He then uses this generator along with a bit of extra handling to mimic array filtering, transformation and reducing the data being returned.

The PHP Roundtable podcast has posted their latest episode, recorded live with host Sammy Kaye Powers and guests Larry Garfield, Matthew Weier O'Phinney and Glen Hickle talking about immutability in PHP.

Immutability plays a huge role in functional programming and many languages support immutability directly; like the readonly keyword in C#. It is possible to create immutable objects in PHP, but the language lacks inherent immutable features for scalar variables and class properties. We discuss how to bring functional programming concepts to PHP and brainstorm some features that could possibly be added to future versions of PHP to offer better immutability support.

The problem here is that you almost cannot guarantee that you can replicate the production environment down to a single detail, it might have a slightly different underlying system, a slightly different network setup, even a different updates applied might mean it works for you, but not on production.

He starts the post by talking about the testing support already built into Symfony and the different parts tested by unit versus functional tests. He gets into some actual (functional) test examples, showing how to evaluate the response from an API request and where the major part of the overhead is - the database interaction. He takes the next step and looks at how to avoid "impure" functional testing and only then starts talking about switching between database types (SQLite vs MySQL) for better performance measurements. Finally, he gets to the topic of the article, running tests in production, and includes a "gotcha" to look out for (hint: don't hard-code IDs).

Hafiz Waheeduddin Ahmad has a new post to his site, part three of a series he's posted on API testing, looking at the use of Codeception for testing API output and functionality.

In this post, we will have a look on how we can use Codeception for API testing.

He starts by helping you get Codeception installed through Composer through a "require" command line call. He then walks you through the setup of the project and how to use the "codecept" command line tool. He covers the generated directory structure the bootstrapping created and how to set up a sample configuration for your API. He then gets into writing an example test, showing how to check things like authentication, HTTP header information, response codes and response contents. Finally he shows how to run the tests in both a normal and more verbose way.

The Laracasts site has a new screencast posted showing you how to integrate Behat with Laravel for functional testing of your application. Behat is an automated testing tool, written in PHP, that's made for frontend functional tests rather than backend, unit tests

It has always been a little tricky to hook Behat into Laravel. But, luckily, that's no longer the case. In this lesson, from scratch, we'll install both Laravel 5 and Behat 3, and then learn about using a special extension to make working with the two that much easier. In a follow-up lesson, we'll move on to discussing general BDD, and best practices for constructing your feature files.

On the Liip blog today there's a tutorial from Gilles Crettenand giving you an overview of functional programming in PHP. While PHP is not normally used as a functional language, it is possible to simulate the same effect.

Functional programming has gained a lot of traction those 3 to 5 last years. [...] Those [frameworks and languages] are all cool and shiny new toys, but we can benefit from some techniques without having to learn a new tool, just by applying some principles to our everyday PHP! But first of all, what exactly is functional programing?

He starts off with some of the basics of functional programming, some of the difficulties that can come with it and, of course, the advantages it can provide. From here he starts in with code examples. He shows how functions become "first-class citizens" and how they can be applied to various elements. He illustrates this with a few array manipulation examples. Next up are "utility functions" for evaluating the data given (like "any" or "all"). He ends the post looking at the idea of "memoization", or the caching of the results of function calls against data. He shows how to accomplish this with static local variables in PHP and includes a wrapper you can pass any callable function into and have the results cache automatically.