Mark Baker has returned with a new part of his series looking at the use of anonymous classes and closures as an alternative to the typical test mocking functionality. In this latest part (part four) he talks more about the "SpyMaster" class created in the previous article and how it can be refactored to provide the spies with a "mission".

In a prior article in this series, I described the use of a SpyMaster Class to create proxy spies as anonymous classes, that allow external visibility (and potentially update) of protected and private properties within an object. The same basic principle of a spy can also be used to create a proxy that gives us access to execute the private and protected methods of an object.

[...] Unlike the original SpyMaster that I wrote about last July, we’re going to take a slightly different approach here, providing our spies with a “mission”.

He first shares the code for the old class and covers why it was useful. He then moves on to the refactor, showing how it defines the "mission" (what to mock) and an "invoker" that helps with the actual execution. He gives an example of this new class in use, performing an "infiltration" on a sample object and calling previously protected methods directly.

Mark Baker has posted the third part of his series looking at an alternative way to handle mocking in the tests for your PHP application. In this latest part of the series he shows how to modify one of PHPUnit's own mocking examples to use an anonymous class.

I have heard people say that you shouldn’t test abstract classes or traits, only the concrete classes that implement or use them. I don’t follow that approach: unit testing is all about testing in isolation from anything that might affect those tests. Testing a concrete class that implements an abstract one, or uses a trait, means that the abstract class or trait is no longer fully isolated, but is being tested within the scope of the whole of that concrete class. We should still always test concrete classes as well; but we should also test the abstract classes and traits as individual units.

So just how do we test something that cannot be instantiated on its own?

He shares one tactic that some developers use - a class designed only for testing - but suggests that this "pollutes" the codebase. Instead he shows how to replace mocking for traits and abstract classes with an anonymous class that's more "disposable". He also shows how to modify this approach to handle calling protected methods in the class the anonymous class extends.

On the Delicious Brains blog they've posted the second part of their series sharing some self-hosted alternatives to WordPress for your CMS needs. In this new article they focus on Grav.

When I started the Self-Hosted WordPress Alternatives series in July with a review of Craft CMS, there were several comments asking what I thought of Grav – an open source flat-file CMS that also has a really cool looking website.

I had never heard of Grav before, but was immediately drawn to it for a few reasons. It’s open source, which is one of the things that I really love about WordPress since it enables a much larger community to work on the project. And since it’s a file-only CMS, there is no database to mess around with which in theory could make development and migrations easier in the long run.

The tutorial then walks you through the installation process and some examples of it in use (including screenshots of the UI). He also covers the core architecture of the tool, theme usage, SEO integration and eCommerce solutions that play well with Grav. He finishes the post looking at the quality of the current documentation and what kind of pricing and licensing Grav comes with.

Mark Baker has posted the second part of his series covering the use of closures and anonymous classes as an alternative approach to mocking in your unit tests. In part one he introduced some of the basic concepts behind their use and in this latest post he focuses on "different approach to using an Anonymous Class to verify the values of object properties".

The last time I posted here, I was writing about Anonymous Functions and how they can be bound to any object (or class) to execute as though they are a method within the scope of that class (Closure Binding as an alternative to “use” variables); and in the first article in this series, I looked at using a Closure to access private and protected properties of an object.

I was going to write this particular article about using simple Anonymous Classes to create test doubles for Unit Testing – and may well return to that topic in a future article in the series – but Matt Brunt has written a good post on that topic already, so instead I’m going to focus on a different approach to using an Anonymous Class to verify the values of object properties that we otherwise couldn’t see directly when testing a class.

He goes on to talk about some ideas from the Java ecosystem around nested classes and scoping. He then shows how, with closure binding, the same kind of effect can be created in PHP testing. He includes the code for an example of a class that coverts distance measurements. He then introduces his "SpyMaster" utility class that "infiltrates" the class under test and attaches the closure providing the needed point for testing. He finishes up the post talking about this functionality and how the technique can be used in many places, not just testing class constructors.

The Delicious Brains site has kicked off a new series of posts looking at other options besides WordPress for self-hosted content management systems. In this initial article they cover the Craft CMS that's built on top of the Yii framework.

To kick this off, I’ll be taking a look at Craft CMS by Pixel & Tonic, a software development team that was behind some of the best add-ons for ExpressionEngine. They have since moved on from ExpressionEngine to create their own CMS that is built on the popular Yii framework.

Craft bills itself as “a content-first CMS that aims to make life enjoyable for developers and content managers alike”. This is a change in stride from WordPress which appeals to a much wider variety of people, so it should be interesting to see how that change affects Craft CMS as a whole.

The tutorial then walks you through the installation process for Craft and what the interface will look like when everything is set up correctly. He talks about the functionality that's immediately available and some places where he feels Craft "shines" in its features. He then goes through some of the core architecture of the tool, templating, plugins, custom fields, SEO, eCommerce support and the documentation/pricing the project offers.

In a previous article on the SitePoint PHP site a workflow was presented for creating and releasing Laravel packages. In this new post from author Younes Rafie an alternative flow is proposed that takes a little different approach.

Every framework gives developers a way to extend the system using packages / extensions. We can generally hook in our logic at any point where we want to provide specific functionality, and Laravel is no exception! Following the article of my fellow author Francesco Malatesta about his Laravel package development workflow, I noticed that mine is a bit different and I wanted to share it with you!

To help illustrate the flow, Younes walks through the development of a two-factor authentication package (presented previously). He then walks through the following steps, giving context for each piece:

• Setting up the Repository
• [Creating a] Package Skeleton
• [Defining the] Package Structure
• [Adding] Tests
• Tagging [the release]

He ends the post with a suggestion not found in the other article: integrating the library with the TravisCI service for continuous integration and verification that all tests are passing.

Hubert Brylkowski has written up a post to his site looking at recursion in PHP and some of the limitations that can some with traditional methods.

Let’s get straight into the problem – assume we want to calculate nth Fibonacci number. Definition : F(n) = F(n-1) + F(n-2) with seed values F(1) = F(2) = 1 so the most intuitive way to do this is just from the definition (recursive). [...] Yay, everything works, so let’s play with bigger numbers. I would like to know the 35th Fibonacci number. On my machine it takes about 8 seconds. That sucks and takes definitely too long.

He talks about what some of the issues with this normal recursive method is (including how many times the function is called) and a possible way to resolve it. He updates this to use the BCMath handling as the numbers are starting to get larger but soon hits the max nesting level for PHP itself. Instead of traditional recursion, he suggests using a few functions/methods to to "jump" from one call to the next without one having to call the other. He includes some refactoring of this solution and a bit of benchmarking to show the performance gain over traditional methods.

The SitePoint PHP blog has a tutorial posted introducing you to a more recent addition to the testing tools available to PHP: atoum. The tutorial provides the basics and shows you how to use it in testing your code as an alternative to PHPUnit.

f you’ve been around PHP for more than a little while, you’ve no doubt started to test your code. And if you ask anyone in the PHP space what to use for writing unit tests, likely the first answer that they’ll give you is PHPUnit.

It’s the de facto standard in the PHP community, and with good reason. But it’s not the only choice. Whilst it does command the lion’s share, other choices abound, one of which I’m going to take you through in this tutorial; it’s called atoum.

They briefly introduce the tool (a "simple, modern, and intuitive unit testing framework for PHP") and help you get it installed. They also recommend installing the "atoum/stubs" package as well, making it easier to do autocomplete in most IDEs. From there the tutorial helps you configure your atoum installation to allow for code coverage reports to be generated. With things configured nicely, the next step is creating a first test evaluating a simple method that either works correctly or throws an exception. Code is included showing how to use the testing to set up expectations and evaluate the results of method execution. Finally they show the command to execute the test(s) and what the resulting code coverage reports look like.

On the SitePoint PHP blog paul Jones has written up some of his own perspective on the PHP-FIG and the work that's currently being done by the group on restructuring to make the group more effective, learning from past issues.

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry’s article, and offer two other possible futures for the FIG.

He starts by talking about the largest change the group is working on - the PHP-FIG 3.0 proposal. He compares the vision of this effort to some of the founding goals and principles of the group as documented in various emails and posts from current (and past) members of the group. Paul also talks about the FIG 2.0 workflow, what PSRs were before/after it was introduced and some of the overall impact that these and other PSRs from the group have had on the wider community.

He wraps up the post with a look at two alternatives he's proposing for the group's consideration as a way forward and an alternative to the PHP-FIG v3: independent interop groups and disbanding the PHP-FIG all together.

On the Symfony Finland blog they have a recent entry looking at some of the other alternative PHP implementations with a brief overview of each.

In the past there have been alternative environment for running PHP in PIPP for Parrot VM and Quercus for JVM, but none of these have had real staying power. This changed with HHVM from Facebook in the early 2010's. It's completely separate from the Zend PHP implementation and is a fully featured alternative.

[...] Many the implementations are just proof of concept implementations and are far from supporting all the language features and rendering them to be useless for running Symfony or other contemporary applications. Regardless of whether these are immediately useful for projects it's interesting to follow these efforts.

The four covered in the post allow for PHP to be run in some pretty non-traditional environments:

• HippyVM letting PHP run in Python (PyPy)
• JPHP that runs PHP in Java
• Tauga VM using Rust to let PHP run compiled via LLVM
• Peachpie for running PHP on .NET

There's a brief look at each of these projects included and, while most aren't close to what HHVM has to offer, you might take a look and see if they could be interesting to try out in some of your development.