Over the last couple of months I have been coaching a number of PHP teams to help them improve their software engineering practices. The main goals were to improve the quality of the product, ease of delivery and the overall maintainability of the code. If there is one thing that defines maintainable code, in my opinion, it is the existence of unit tests. However, one of the things that proved more difficult than one might expect is to start writing proper unit tests in an existing PHP solution.

In this instance, the teams were using the Laravel framework. However, standard Laravel practices limited the testability of the code created by the teams. I have worked with these teams to make their code more testable to two ends:

  • Improve overall testability by introducing new class design patterns
  • Reduce the duration of tests. Prior to this approach, a lot of tests were implemented as end-to-end, interface based tests. And boy, are they slow!

After a number of weeks, we saw the first results coming in, so all of this worked out nicely.

The goal of this post is to share the issues found that were preventing the team from proper unit testing and how we got around them.

Issue 1: instantiating a class in a unit test

The first thing we ran into was the fact that it was impossible to instantiate any class from a unit test. There were two reasons for this. The first was that there was actual work done in the constructor of almost every class: calling a method on another class and/or hitting the database.

Next to this, dependencies for any class were not passed in via the constructor, but were created in the constructor using a standard Laravel pattern. The good news here is that Laravel actually provides you with a dependency container. The bad news is, that it was often used like this:

class TestSubject {
    public function __construct() {
        $this->someDependency = app()->make(SomeDependency::class);

This calls a global, static method app() to get the dependency container and then instantiates a class by type. Having this code in the constructor makes it completely impossible to new the class up from a unit test.

In short, we couldn’t instantiate classes in a unit test due to:

  • Doing work in a constructor
  • Instantiating dependencies ourselves

Solution: Let the constructor only gather dependencies

First of all, calling methods or the database was quite easy to refactoring out of the constructors. Also, this is a thing that can easily be avoided when creating new classes.

The best way to not instantiate dependencies yourselves, is to leave that to the framework. Instead of hitting the global app() method to obtain the container, we added the needed type as a parameter to the constructor, leaving it up to the Laravel container to provide an instance at runtime (constructor dependency injection.)

public function __construct(SomeDependency $someDependency) {
    $this->someDependency = $someDependency;

Now there is still one issue here and that is we are depending upon a concrete class, not an abstraction. This means, we are violation the Dependency Inversion principle. To fix this, we need to depend on an interface. However, now the Laravel dependency container no longer knows which type to provide to our class when instantiating it, since it cannot instantiate a class. Therefore, we have to configure a binding that maps the interface to the class.

app()->bind(SomeDependencyInterface::class, SomeDependency::class);

Having done this, we can now change our constructor to look as follows.

public function __construct(SomeDependency $someDependency) {
    $this->someDependency = $someDependency;

At this point we have changed the following:

  • No work in constructors
  • Getting dependencies provided instead of instantiating them ourselves.
  • Depending upon abstractions

Mission accomplished! These things combined now allows to instantiate our test subject in a unit test as follows:

$this->dependencyMock = $this->createMock(SomeDependencyInterface::class);

$this->subject = new TestSubject($this-> dependencyMock);

Issue 2: Global static helper methods

Now we can instantiate a TestSubject in a test and start testing it. The second we got to this state, we ran into another problem that was all over the code base: global, static, helper methods. These methods have different sources. They are built-in PHP methods, Laravel helper methods or convenience methods from 3rd parties. However, they all present us with the same problems when it comes to testability:

  • We cannot mock calls to global, static methods. Which means we cannot remove their behavior at runtime and thus cannot isolate our TestSubject and start pulling in real dependencies, dependencies of dependencies, etc…

From here on, I will share (roughly in order of preference) a number of approaches to get around this limitation.

Solution 1: Finding a constructor injection replacement

When starting to investigate these static methods, especially those provided by Laravel, we saw that a lot of them were just short wrapper methods around the Dependency Container. For example, the implementation of a much used view method was this:

public function view($name = null, $data = [], $mergeData = [])
    $factory = app(ViewFactory::class);

    if (func_num_args() === 0) {
        return $factory;
    return $factory->make($view, $data, $mergeData);

For all these convenience methods, it is straightforward to see that we can easily refactor the calling code from this:

public function __construct() { }

public function index() {
    // … more code
    return view(“blade.name”, $params);

To this:

public function __construct(ViewFactory $viewFactory) {
    $this->viewFactory = $viewFactory;

public function index() {
    // … more code
    return $this->viewFactory->make(“blade.name”, $params);

A quick and easy way to remove a decent portion of calls to global functions.

Solution 2: Software engineering tricks

If there is no interface readily available for constructor injection, we can create one ourselves. A common engineering trick is to move unmockable code to a new class. We then inject this to our subject at runtime. At test time however, we can then mock this wrapper and test our subject as much as possible.

As an example, let’s take the following code:

class Subject {
    function isFileChanged($fileName, $originalHash) {
        $newHash = sha1($fileName);
        return $originalHash == $newHash;

Of course we can test this class by letting it operate on a temporary file, but another approach would be to do this:

class Subject {
    private $sha1Hasher;

    public function __construct(ISha1Hasher $sha1Hasher) {
        $this->sha1Hasher = $sha1Hasher;

    function isFileChanged($fileName, $originalHash) {
        $newHash = $this->sha1Hasher->hash ($fileName);
        return $originalHash == $newHash;

Maybe not a thing you would do in this specific instance. But if you have code that is more complex and is executing a single call to a global method, this way you can move that call behind an interface and mock it out while testing:

public function testSubject() {
    $hasherMock = $this->createMock(ISha1Hasher::class);
    $subject = new Subject($hasherMock);

    $result =$subject->isFileChanged(“n/a”, “123”);


In my opinion, solution 2 is by far a better approach to take than solutions 3 and 4. However, if you are afraid that adding to much types might clutter your codebase or reduce the performance of your application, there are two more approaches available. Both have drawbacks, so I would only use them if you see no other way.

Solution 3: Leveraging PHP namespace precedence

If refactoring global static calls in you code to a new class is not an option and your code is organized into namespaces, there is another way we can mock calls to built-in PHP methods. In the file with our TestClass, we can add a new method with the same name in a namespace that is closer to the caller.

For example, the following call to file_exists() cannot be mocked out:

namespace demo;

class Subject {
    public function hasFile() {
        return file_exists("d:\bier");

As you can see, the class containing the hasFile() method is in a namespace called demo. We can create a new method, also called file_exists() in that same namespace, just before our TestClass. When executing, the methods in the namespace that is the closed to the caller will take precedence.

This means, we mock the call to file_exists() to always return true, as follows:
namespace demo;

function file_exists($fileName) {
    return true;

class TestClass {
    public function testWhenFileExists_thenReturnTrue() {
        $result = $this->subject->hasFile();



The main drawback of this approach is that it reduces the readability of your code. Also, relying on method hiding for testing purposes might make your code harder to understand for those that do not grasp all the language details.

Solution 4: Leveraging your frameworks and libraries

Finally, your framework might provide its own means for mocking certain calls. In Laravel for example, there is a construct of Facades that you can also use for mocking purposes. Another example is the Carbon datetime convenience library that provides a global static Carbon::setTestNow() method.

I for one would discourage this, as it would mean that you are writing logic that will become dependent on your framework and will not ever be able to switch to another framework without redoing everything. (However… who has done that even once?)

My other argument is one of taste: I simply do not like adding methods to production code, only to make it testable. And I have seen misuse of methods intended for tests only in production code as well…

However, if you do not share these feelings, the approach is quite nicely detailed here: https://laravel.com/docs/5.6/facades or here: http://laraveldaily.com/carbon-trick-set-now-time-to-whatever-you-want/


I hope that this blog gives you a number of approaches to make your PHP code more (unit)testable. Because we all know that only code that is continued tested in a pipeline, can quickly and easily be shipped fast and often to customers.


With thanks for proofreading: Wouter de Kort, Alex Lisenkov

March 25th, a Sunday, I got a direct message on Twitter from Christos Matskas, who I recently met at an event in the Netherlands. He asked if I could help host a meetup where his colleague Seth Juarez could come and give a presentation into deep learning and interact with developers interested in Machine Learning (what salespeople call Artificial Intelligence, according to Seth). Just one catch, it had to be either next Wednesday or Thursday.

I rarely worry about anything, so neither did I that day. Seth is pretty well known, so it felt like an honor to be able to host a meetup with him and I figured that it wouldn’t be too hard to get a great audience. So, I said yes as soon as I got a company (IBIS Software) to sponsor the location.

The next couple of days we spent on getting some PR for the just-once “pop-up meetup with Jeth Suarez.” This was actually (much) harder than expected, but we ended up with an enthusiastic crowd of over 25 people.

As requested by a number of attendees I am sharing the slides Seth used. The event was also recorded and can be viewed back here.

Again, thanks for being there Seth. IBIS, thanks for sponsoring a location, food and drinks!

Ever wished you would receive a simple heads up when an Azure deployment fails? Ever troubleshooted an issue and looked for the button: “Tell me when this happens again?” Well, I just found it.

Yesterday I stumbled across a -for me (*) – new feature that is just amazing: azure activity log alerts. A feature to notify me when something specific happens.

With the introduction of the Azure Resource Manager model, the activity log was also introduced. The activity log is an audit trail of all events that happen within your Azure subscription, either user initiated or events that originate in Azure itself. This is a tremendous powerfull feature in itself, however it has become more powerfull now. With azure activity log alerts you can create rules that automatically trigger and notify you when an event is emitted that you find interesting.

In this blog post I will detail two scenario’s where activity log alerts can help you out.

(*) It seems this feature was already launched in May this year, according to this Channel9 video

Example: Manage authorizations

Let’s say you are working with a large team on a large project or on a series of related projects. One thing that you might want to keep taps on, is people creating new authorizations. So let’s see if we can quickly set something up to send me an e-mail whenever this happens.

  1. Let’s start by spinning up the monitoring blade in the Azure portal.
  2. In the monitoring blade the activity log automatically opens up. Here we can look through past events and see what has happened and why. Since we are looking to get pro-activly informed about any creation events, lets navigate to Alerts:
  3. In the top of the blade, choose Add activity log alert and the following dialog will open:
  4. Here there are a number of things we have to fill out. As the name and description “A new authorization is created” covers what we are about to do. Select your subscription and the resourcegroup where you want to place this alert. This is not the resourcegroup that the alert concerns, it is where the alert itself lives. As event category we pick “Administrative” and as Resource Type “Role assignment.” The last resets all other dropdowns so we only have to select an Operation name. Let’s pick “Create role assignment.”
  5. After selecting what we want to be alerted about, let’s decide how we want to alerted. This is done via an Alert group, an alert group is a group of one or more actions that are grouped under one name and can be reused. Let’s name our action group “StandardActionGroup” and add an e-mailadres. Giving us a final result as follows:
  6. Now let’s authorize a new user on a resource:
  7. And hurray, we are notified by e-mail:

Example: Streaming Analytics hick-up

So you have an Azure resource that has some issues. Every now and then it gets in a faulted state or just stops working. Often you will find that this is nicely put into the activity log. For example I have a Streaming Analytics job that faults every now and then. Let’s see how we can get Azure to “tell me when this happens again.”

  1. Go to the activity log of the resource with an error
  2. Open the details of the Warning and find the link to Add activity log alert

  3. The blade to open a new alert is added, with everything prefilled to capture just that specific event. In essence allowing you to ask Azure to tell you ‘if it happens again’

Can we automate that?

Finally, as you can see in the image below, every activity log alert is a resource in itself. Which means you can see them when you list a resourcegroup and that you can create them automatically using ARM templates. For example as part of your continuous delivery practice.

E-mail sucks, I want to create automated responses

Also possible. You can also have an webhook called as part of an actiongroup. This way you can easily hook up an Azure function to immediately remedy an issue, for example.

The second day of this month, Microsoft announced two new libraries to interact with the Azure Event Hub. I was afraid we had a lot of rework coming our way, however this upgrade was one of the easiest I’ve ever done!

Removed the old NuGET packages, added the new packages. Replaced SendBatchAsync() with SendAsync() and a small change in connectionstring and I was good.

As you can see I’ve introduced a small quirk at line 45 to make this new code work with old connectionstrings that smells a bit However, it works like a charm and can easily be removed later on.

Small quirks like these allow me to ship this code to systems that are still configured with a connectionstring that contains the TransportType property. This way I do not have to time the code and configuration upgrade of systems. I can just ship the code, ship the configuration change later and finally clean up the quirk.

One of the better upgrade experiences. Thanx!

I just read that there is a new T-SQL operator in town: STRING_AGG. Finally! Having worked with MySQL prior to moving (primarily) to Azure SQL DB, I have always missed a T-SQL equivalent to GROUP_CONCAT.

I’m happy to see that STRING_AGG has the same workings as GROUP_CONCAT. Both do not only concatenate string values, but also allow for injecting a ‘glue’ in between. Use is just as expected, a query such as


SELECT STRING_AGG(DisplayName, ‘, ’) FROM Users WHERE AccountId = 45


Will produce a single row result of


Henry Been, John Doe


Simply Awesome!

Dinsdag en woensdag vier en vijf oktober, heb ik samen met een aantal collega’s weer de Microsoft TechDays bezocht. Op de TechDays zorgen tal van sprekers ervoor dat je in twee dagen weer helemaal op de hoogte raakt van de nieuwste ontwikkelingen van Microsoft. Mijn eigen aandacht ging dit jaar niet alleen uit naar de sessies die gegeven werden, ik heb er dit jaar zelf ook twee mogen geven.

Op de SnelStart blog vertel ik over mijn ervaringen en zijn de sheets te downloaden. Opnames van de sessies staan op Channel9.

Terwijl ik dit schrijf, is Microsoft hard aan het werk om de transitie van de Azure Service Management (ASM) API’s naar de Azure Resource Management (ARM) API’s af te ronden. Beide API’s bieden de mogelijkheid om je Azure resources te beheren en zijn de REST API’s achter Azure Powershell en de Azure portal.

De oudere, ASM API wordt niet voor niks vervangen. Het grote nadeel van deze API is, dat hij niet de mogelijkheid biedt tot fine-grained autorisaties. De enige manier om toegang tot resources te beheren is op het niveau van de subscription. Je kunt niet per resource bepalen wie waar bij mag. In elke organisatie met meer dan een paar resources is dit volledig onacceptabel.

De ARM API is op dit punt een grote stap vooruit. Met ARM kun je Azure Service Management (ASM) APIs to the per resource bepalen wie er bij kan en zelfs regelen wat men precies mag.

Maar dat is niet alles. Naast personen zijn er soms ook applicaties of systemen die toegang nodig hebben tot een of meer Azure resources. Via ASM kon dit door het gebruik van zogenaamde management certificates. De houder van zo’n certificaat had dan volledige controle over een subscription. Met ARM is het mogelijk om ook applicaties gericht toegang te geven tot een subset van je resources. Het is echter niet erg duidelijk hoe dit werkt. In dit blog zal ik dan ook laten zien hoe je een applicatie toegang kan geven tot Azure resources volgnes het principle of least privilege. Voor autorisatie zal ik daarvoor gebruik maken van certificaten, een veiligere methodiek dan wachtwoorden.

Iedereen die, via ARM, toegang tot een subscription heeft moet bekend zijn in de Azure Active Directory (AAD) die bij die subscription hoort. Dit geld niet alleen voor personen, maar ook voor applicaties. Het registreren van een applicatie in de AAD kan helaas nog niet in de nieuwe portal. We moeten dus terug naar de oude portal of gebruik maken van Powershell. Nadat de applicatie geregistreerd is in de AAD, moet deze ook nog geautoriseerd worden op een resourcegroup. Dit kan echter weer alleen in de nieuwe portal of via Powershell. Om die reden kies ik voor Powershell zodat ik niet heen en weer hoef tussen portals.

Om verbinding te maken met de AAD vanuit Powershell is er een specifieke Powershell module (MSOL) nodig, die je hier vindt.

Allereerst registreren we de applicatie:

> # Connect to your active directory
> Connect-MsolService

> #Create the application
> New-MsolServicePrincipal -DisplayName YourApplication
The following symmetric key was created as one was not supplied r...k=

DisplayName : YourApplication
ServicePrincipalNames : {f...1}
ObjectId : c...f
AppPrincipalId : f...1
TrustedForDelegation : False
AccountEnabled : True
Addresses : {}
KeyType : Symmetric
KeyId : 2...4
StartDate : 18-10-2015 15:13:31
EndDate : 18-10-2016 15:13:31
Usage : Verify
> # We will need that AppPrincipalId later, so keep it for reference

> # However, first we remove that Symmetric key we do not need
> # First we find its KeyId
> Get-MsolServicePrincipalCredential -AppPrincipalId f...1
cmdlet Get-MsolServicePrincipalCredential at command pipeline position 1
Supply values for the following parameters:

Type : Symmetric
Value : 
KeyId : 2...4
StartDate : 18-10-2015 15:13:31
EndDate : 18-10-2016 15:13:31
Usage : Verify 

> # Now remove it providing again the ApplicationId and the KeyId.
> # The KeyIds parameter takes an array, hence the parentheses
> Remove-MsolServicePrincipalCredential -AppPrincipalId f...1 -KeyIds ("2...4")

Nu voegen we authenticatie op basis van een certificaat toe:

> # Let's grab the certificate from filesystem and transform it to Base64
> $certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate 
> $certificate.Import("c:\...\YourApplication.cer")
> $binaryCertificate = $certificate.GetRawCertData() 
> $base64Certificate = [System.Convert]::ToBase64String($binaryCertificate);

> # Register the certificate as the applications credential
> New-MsolServicePrincipalCredential -AppPrincipalId "f...1" -Type asymmetric -Value $base64Certificate -Usage verify

Tenslotte moeten we de applicatie rechten geven op een resource. Voor dit doel heb ik een resourcegroup ‘poc’ aangemaakt:

> # Every resource under ARM is defined by an URL
> $scope = "/subscriptions/4...f/resourceGroups/poc"

> # Contributor is a pre-assigned role that includes every right, except GRANTS
> New-AzureRoleAssignment -ServicePrincipalName "f...1" -RoleDefinitionName Contributor -Scope $scope

De applicatie schrijven

Nu dat we een applicatie in de AAD geregistreerd hebben, kunnen we de applicatie zelf schrijven. Hieronder vind je een minimaal voorbeeld voor authenticatie en het opvragen van een lijst van alle storage accounts in een rsource group:

var subscriptionId = "4...f"; // The guid assigned to your subscription. If you don't have it, use Get-AzureSubscription
var tenantId = "4...f"; // The guid assigned to your AAD Tenant. If you don't have it, use Get-AzureSubscription
var aadEndpoint = $"https://login.windows.net/{tenantId}";
var clientId = "f...1"; // Again, AppPrincipleId
var certificateThumbprint = "b...a"
var armLocation = "https://management.azure.com/"

var context = new AuthenticationContext(aadEndpoint);
var certificate = GetARMCertificate(certificateThumbprint);
var credentials = new ClientAssertionCertificate(clientId, certificate);
var loginResult = context.AcquireToken(armLocation, credentials);
var token = new TokenCloudCredentials(subscriptionId, loginResult.AccessToken);
var managementClient = new StorageManagementClient(token);

var accounts = managementClient.StorageAccounts.List();

Er zijn twee NuGET packages die je moet installeren om deze code te draaien: Microsoft.IdentityModel.Clients.ActiveDirectory and Microsoft.Azure.Management.Storage

En hier het eindresultaat: Een overzicht van alle storage accounts in de resource group. Andere acties, zoals het toevoegen of verwijderen van storage accounts zijn natuurlijk ook mogelijk..


Gisteravond heb ik bij SnelStart een korte presentatie gegeven over het State Pattern. Wat is het, waar gebruiken we het voor en waarom?

Als we naar een pattern kijken als een ‘type oplossing, voor een type probleem’ dan is het niet alleen belangrijk om het probleem dat een pattern oplost te kennen, maar ook te kunnen herkennen. Kennen: Het state pattern is de oplossing voor het type probleem waarbij we een class hebben die, afhankelijk van de state waarin hij verkeerd, ander gedrag moet vertonen bij het aanroepen van zijn methoden. Herkennen: De naïeve oplossing voor dit type probleem is het introduceren van een enumeratie en in elke methode een switch/case statement om de juiste code uit te voeren. Aan deze combinatie kun je een goede kandidaat voor gebruik van het state pattern gelijk herkennen.

Natuurlijk blijft dan nog de vraag over waarom het gebruik van het state pattern beter is dan die naïeve implementatie. Er zijn tal van argumenten te noemen, maar de belangrijkste voor mij zijn testbaarheid en onderhoudbaarheid. Een implementatie op basis van polymorfisme in plaats van een aantal conditionele switches, verminderd bijna altijd het aantal testgevallen dat je moet vangen in je unit tests. Daarnaast, onderhoudbaarheid: Bedenk wat er gebeurd wanneer iemand een state-enumeratie uitbreidt met een nieuwe waarde en een switch/case statement vergeet aan te passen. Je programma compileert, je testen draaien nog en toch zit er waarschijnlijk een grote bug in je programma. Met een state pattern heb je dit niet omdat je compiler je dwingt om de nieuwe state volledig te implementeren.

Maar wat is het state pattern dan precies? Een state pattern kenmerkt zich door een outer class die zelf geen gedrag implementeert, maar alle aanroepen delegeert naar een inner class die de huidige staat van de outer class omschrijft. Een voorbeeld in UML zie je hieronder.


State pattern in UML. We zien hier een Order class die een aantal methoden adverteert. Elke aanroep is echter een delegatie naar de abstracte OrderState class. De overervingen van deze class zorgen voor het juiste gedrag in elke staat waarin de order zich kan bevinden.

Nu zegt een plaatje meer dan duizend woroden, maar is code nog veel mooier. Hier kun je een visual studio C# solution met vier projecten downloaden met een gedetaileerde implementatie van het state pattern en een stap-voor-stap refactoring hier naar toe vanaf een naïeve implementatie.