PHPUnit beyond basics: Dataproviders

Once you have set up your first unit tests, and you have a good configuration, its time to add a lot of tests. Lets take a look at using data providers, as a way to test with a lot of data. For this example we’ll test a piece of code that is supposed to do the following. Given the array ['a', 'b', 'c'], return the string a a-b a-b-c b b-c c.

PHPUnit beyond basics: configuration

If you just got started with PHPUnit, its configuration file may be a bit daunting. Today we’re gonna walk through (what i consider) the ideal config file. If you’re just here to copy paste the config, then you can find it at the bottom 👇. A minimum phpunit.xml may look like this: <?xml version="1.0" encoding="UTF-8"?> <phpunit> <testsuites> <testsuite name="Tests"> <directory>tests/</directory> </testsuite> </testsuites> </phpunit> The first thing we can do to improve this, is link the xsd.

Every day design pattern: Builder

Just like the factory pattern, the builder is a creational pattern, meaning it is about how objects are created. But unlike a factory, a builder allows you to build an object in parts. I tend to use it for creating objects that take a configuration. Lets start with an example. This class builds a guzzle client, with a certain config. Normally we have a timeout of 10 seconds, with a 5 second timeout for both connect and read.

Every day design pattern: Factory

The previous two chapter of this blog series were about the decorator and the adapter. These are structural design patterns. Meaning they deal with the structure of a system. They can help with simplifying relationships, and moving responsibilities. The factory is a completely different type of design pattern. Its a creational pattern. A creation pattern is intended to make creation of objects easier. I generally use one when a class needs a multiple parameters, but only a few need to be ‘dynamic’.

Every Day Design Pattern: Adapter

This is the second post in a series of design patterns i use (almost) daily. You will find the other posts at the bottom of this article. On wikipedia, the adapter pattern is described like so: the adapter pattern is a software design pattern (…) that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.

Every day design pattern: Decorator

This is the first post in a series of design patterns i use (almost) daily. You will find the other posts at the bottom of this article. The Decorator pattern On wikipedia, the decorator pattern is described like so: In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other objects from the same class.

Replacing private services with mocks during tests

Use a custom services file for your tests, to allow changing dependencies as needed.

Testing code that generates warnings

Our code base has a lot of code that looks like this: <?php try { $this->doScaryThing(); } catch(Exception $e) { trigger_error("Downgraded: " . get_class($e) . ":" . $e->getMessage(), E_USER_WARNING); } Or sometimes trigger_error is used as a way to log other thigns. This makes it rather difficult to test. Thankfully PHPUnit 8.4 has the expectWarning method, that allows us to check this: <?php public function testItTriggersWarning(): void { $object = new Danger(); $this->expectWarning(); $object->doWarningThing(); } This does mean that the execution stops after the warning is triggered, so we can’t assert anything after that.

What is the boy scout rule

Our code base is a lot like a camp site, and we can learn a thing or two from the boy scouts.

When to add comments

Most code bases have far too much comments, while only a few are really usefull.