With Covid-19, physical conferences stopped happening. I gave a talk at the virtual Symfony World conference in 2020. The virtual conference was an interesting experience and a well organised event. But I missed travelling to a foreign place and meeting people between talks and in the evening. Hence, I was absolutely thrilled to be invited to do a workshop at the Web Summer Camp in Croatia.

Web Summer Camp Croatia is a unique event. There are no regular presentations, only hands-on workshops. You see fewer different topics than at a typical conference, but get to deep dive in those instead. The participants who had time to stay an additional day were invited on a boat trip on the beautiful Mediterranean sea.

Debugging PHP Applications

In my debuggin strategies workshop, I used PHP for the examples, but most of the content is applicable to any programming language. Using lots of small exercises, I let the participants try various debugging strategies to locate the bugs I had hidden in the application. Among other things, we did exercises to

• Understand exception messages and stack traces to locate a problem
• Use logs to identify where the problem is
• Use unit tests and a test coverage report to identify an issue
• Use git bisect to find the commit that introduced a regression
• Demonstration of step-by-step debugging with the PhpStorm IDE

I also showed the clean code principles as a way to avoid errors from being made. I presented defensive programming and other methods to improve error reporting when something does go wrong.

For the showcase examples, I used a simplistic Symfony application that imports CSV files into a database and shows a query result from that database on the home page. The application is super simple, so that the participants understand what is going on and can focus on the debugging technique of the exercise. Each exercise is a branch in that repository with some change to introduce the bug.

Hire Me 😉

If you are interested in providing a hands-on workshop for your team, please get in touch with me. Meeting on-site will bring the best value, as the workshop is highly interactive.

I’m a big fan of the BDD Books by Gáspár Nagy and Seb Rose, and I’ve read a lot about writing and improving scenarios, like Specification by Example by Gojko Adzic and Writing Great Specifications by Kamil Nicieja. I can recommend reading anything from Liz Keogh as well. Trying to apply their suggestions in my development work, I realized: specifications benefit from good writing. Writing benefits from good thinking. And so does design. Better writing, thinking, designing: this will make us do a better job at programming. Any effort put into these activities has a positive impact on the other areas, even on the code itself.

Unit tests vs automated scenarios

For instance, when you write a test in your favorite test runner (like PHPUnit), you’ll write code. You’ll focus on technology, and on implementation details (methods, classes, argument types, etc.):

$config = Mockery::mock(Config::class);
$config->shouldReceive('get') ->with('reroute_sms_to_email') ->andReturn('developers@org.nl'); $fallbackMailer = Mockery::mock(Mailer::class);
$fallbackMailer->shouldReceive('send') ->andReturnUsing(function (Mail $mail) { self::assertEquals('The message', $mail->plainTextBody()); self::assertEquals('SMS for 0612345678', $mail->subject()); }); $smsSender = new SmsSender($config, $fallbackMailer);
$smsSender->send('0612345678', 'The message');

It takes a lot of reading and interpreting before you even understand what’s going on here. When you write a scenario first, you can shift your focus to a higher abstraction level. It’ll be easier to introduce words from the business domain as well:

Given the system has been configured to reroute all SMS messages to the email address developers@org.nl
When the system sends an SMS
Then the SMS message will be sent as an email to developers@org.nl instead

When automating the scenario steps it will be natural to copy the words from the scenario into the code, establishing the holy grail of Domain-Driven Design – a Ubiquitous Language; without too much effort. And it’s definitely easier to understand, because you’re describing in simple words what you’re doing or are planning to do.

Most of the projects I’ve seen don’t use scenarios like this. They either write technology-focused scenarios, like this (or the equivalent using Browserkit, WebTestCase, etc.):

Given I am on "/welcome"
When I click "Submit"
Then I should see "Hi"

Or they don’t specify anything, but just test everything using PHPUnit.

Writing scenario-style unit tests

Although it may seem like having any kind of test is already better than having no tests at all, if you’re making an effort to test your code, I think your test deserves to be of a high quality. When aiming high, it’ll be smart to take advantage of the vast knowledge base from the scenario-writing community. As an example, I’ve been trying to import a number of style rules for scenarios into PHPUnit tests. The result is that those tests now become more useful for the (future) reader. They describe what’s going on, instead of just showing which methods will be called, what data will be passed, and what the result of that is. You can use simple tricks like:

1. Givens should be in the past tense
2. Whens should be in the present tense
3. Thens should be in the future tense (often using “should” or “will”)

But what if you don’t want to use Behat or another tool that supports Gherkin (the formalized language for these scenarios)? The cool thing is, you can use “scenario language” in any test, also in unit tests. The trick is to just use comments. This is the unit test above rewritten with this approach:

// Given the system has been configured to reroute all SMS messages to the email address developers@org.nl
$config = Mockery::mock(Config::class);
$config->shouldReceive('get') ->with('reroute_sms_to_email') ->andReturn('developers@org.nl'); // When the system sends an SMS
$fallbackMailer = Mockery::spy(Mailer::class);
$smsSender = new SmsSender($config, $fallbackMailer);
$smsSender->send('0612345678', 'The message'); // Then the SMS message will be sent as an email to developers@org.nl instead
$fallbackMailer->shouldHaveReceived('send') ->with(function (Mail $mail) { self::assertEquals('The message', $mail->plainTextBody()); self

Truncated by Planet PHP, read more at the original (another 3134 bytes)

The PHP team is pleased to announce the release of PHP 8.1.0, RC 2. This is the second release candidate, continuing the PHP 8.1 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.1.0, RC 2 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the third release candidate (RC 3), planned for 30 September 2021. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.

In essence, everything is a string.

Well, you can always go one layer deeper and find out what a string really is, but for web apps I work on, both input data and output data are strings. The input is an HTTP request, which is a plain-text message that gets passed to the web server, the PHP server, the framework, and finally a user-land controller. The output is an HTTP response, which is also a plain-text message that gets passed to the client. If my app needs the database to load or store some data, that data too is in its initial form a string. It needs to be deserialized into objects to do something and later be serialized into strings so we can store the results.

We create objects from strings, and turn them back into strings because the protocols we use require strings (e.g. HTTP, SQL, AMQP, and so on). These protocols are only used near the edges of the application, where data comes in from and gets sent to external systems. In the core of the application there should be no need to serialize/deserialize data. There we should only have to deal with objects. That will be great, because objects can provide guarantees regarding the data they keep, so they are safer to use than strings. They also have an explicitly defined API, so they are much easier to use.

Of course many developers know this. They’ll use Value Objects to wrap strings, enforcing data consistency and ease of use. And not just strings, because we have several other primitive types at our disposal that support different use cases like doing math.

The problem is, how do we safely go from a string to an integer. To complicate things, most string data gets to us in the form of an associative array (i.e. map) of key/value pairs, both of which are a string. For instance when we get a record from our database abstraction library, it will be an array. If we want to use that data we can access it by its key, but we have to ensure it’s there. The next step is to ensure it’s of the correct type, and optionally cast it to the correct type:

/** @var array $record */ $title = $record['title'];
$numberOfComments = (int)$record['numberOfComments'];

From the type signature if $record, it’s not clear that we may expect keys title and numberOfComments to exist. Even if they exist we can’t be sure that their values are of the expected type. When working with arrays you always have to check if the key exists before accessing it, or you may get a PHP Notice (and hopefully to the error that it really is, but most frameworks nowadays do this for you). We can use the so-called null coalescing operator (??) to overcome the problem of undefined keys:

/** @var array $record */ $title = $record['title'] ?? '';
$numberOfComments = (int)($record['numberOfComments'] ?? 0);

This works if the key is undefined, but it will also revert to the default value of they key did exist but the value was null. We lose an important piece of information, namely that the requested key is undefined. In most cases this is a programming mistake, e.g. we forgot to add the column to the SQL SELECT statement. When using ?? it’s a lot harder to discover this problem because it “swallows” the problem.

Instead we should explicitly assert that the key exists:

/** @var array $record */ if (!array_key_exists($record, 'title')) { throw new LogicException('Expected array $record to have a key "title"');
}
$title = $record['title']; if (!array_key_exists($record, 'numberOfComments')) { throw new LogicException('Expected array $record to have a key "numberOfComments"');
}
$numberOfComments = (int)$record['numberOfComments'];

Of course, this quickly becomes annoying. So we introduce a helper function for this, e.g.

/** @var array $record */ self::assertKeyExists($record, 'title');
$title = $record['title']; self::assertKeyExists($record, 'numberOfComments');
$numberOfComments = (int)($record['numberOfComments'] ?? 0);

The helper function throws that same exception if the key is undefined.

But couldn’t we just define the expected shape of $record, thereby fixing the issue? E.g.

/** @var array{title: string, numberOfComments: string} $record */

Not really, because it isn’t this method that defines the structure of $record. It’s the result of fetching a result set from the database, and that doesn’t give us any guarantees about the shape of the array, or the types of the values. There’s a slightly better type we can use though:

/** @var array<string,string|nu

Truncated by Planet PHP, read more at the original (another 4337 bytes)

“Yes, I know. Our tests aren’t perfect, but it’s better to test anything than to test nothing at all, right?”

Let’s look into that for a bit. We’ll try the “Fowler Heuristic” first:

One of my favourite (of the many) things I learned from consulting with Martin Fowler is that he would often ask “Compared to what?”

• Agile helps you ship faster!
• Compared to what?

[…]

Often there is no baseline.

— Daniel Terhorst-North

The baseline here is: no tests. The statement is that having some kind of test is better than having no tests. Without any context, this is evidently true. Since we know that tests are good, and we want tests for our code, but we have no tests yet, adding some kind of test gets us at least one step closer to the end goal.

However, without context, most statements can’t be judged for their value. So let’s add some context. My guess is that most development teams want tests for their code for two reasons:

1. They want to have the tests form a kind of safety net, for when they’re making changes to that horrible legacy code.
2. They want to understand why something was implemented the way it is by reading the tests.

To judge the value of any test over no test we should find out if those few tests that developers write in a #NoTest code base are actually helpful to achieve 1 and 2.

UI Tests

Another common minimal approach to testing is to go The Framework Way. Whatever the framework describes in their “Testing” chapter, the team will do. Mostly this results in tests that focus around performing web UI interactions and checking what ends up being in the database afterwards. These tests also break for all kinds of unrelated reasons, which makes them annoying to maintain. They are usually quite slow. This reduces the value of the safety net they provide. Furthermore, in most cases they still don’t document the “why”. They show a number of steps and what’s supposed to happen, but they don’t explain why that happens in this case. There is often no clear connection between the start and the end of the test.

Based on my experience with different teams and different projects, this leads me to think that it’s definitely not better to write any test than no test. If you don’t know what types of test you should write for each area of your application, you’ll end up with an unmaintainable test suite, and demotivating team standards like “every class should have a test”. If anything, you’ll get people to dislike writing tests. At that point, your principle that “any test is better than no test” has reached the opposite of the intended effect.

Good Tests

Instead of writing just any test, focus on writing good tests. Work on tests together, treat them as specifications (which makes it easier to include the “why”, something we programmers often forget). While doing so, make sure that writing tests is Fun, Easy, and Effective. The FEE for this is that you have to invest in:

• Test tools that help you run specific tests really quickly (Can you right-click a specific test method and run it in PhpStorm? You should!)
• Tests that give quick results (How long does it take to run the relevant tests before committing? If it’s more than a few seconds, fix it!)
• It should be really cheap to add more test cases to show how the code behaves when different data is being provided (How much do you have to copy/paste when you want to create a new test class, or a new test method? Make sure it’s just a few lines).

This approach, I claim, is Effective; when the test suite no longer works against you, it’ll become a trusted safety net instead of an annoying maintenance burden. More tests will be created, and they will be of a better quality than just one-class-one-test or make-request-then-look-in-DB tests.

Test Debt

I’m sure it takes a lot of effort, but just like everybody understands Technical Debt for production code and invests in improving its design, you know you have Test Debt; both in your own experience as a developer and in your project. So, go go go!

This episode is sponsored by
RingCentral Developers

The post Ep#361 – Interview with Dana Luther appeared first on Voices of the ElePHPant.

Version 8.1.0 Release Candidate 1 is released. It’s now enter the stabilisation phase for the developers, and the test phase for the users.

RPM are available in the remi-php81 repository for Fedora ≥ 33 and Enterprise Linux ≥ 7 (RHEL, CentOS), or in the php:remi-8.1 stream, and as Software Collection in the remi-safe repository (or remi for Fedora)

The repository provides development versions which are not suitable for production usage.

Also read: PHP 8.1 as Software Collection

Installation : read the Repository configuration and choose installation mode.

Replacement of default PHP by version 8.1 installation, module way (simplest way on Fedora and EL-8):

dnf module reset php
dnf module install php:remi-8.1
dnf update

Replacement of default PHP by version 8.1 installation, repository way (simplest way on EL-7):

yum-config-manager --enable remi-php81
yum update php\*

Parallel installation of version 8.1 as Software Collection (recommended for tests):

yum install php81

To be noticed :

• EL8 rpm are build using RHEL-8.4
• EL7 rpm are build using RHEL-7.9
• lot of extensions are also available, see the PHP extension RPM status page and PHP version 8.1 tracker
• follow the comments on this page for update until final version
• should be proposed for Fedora 36

Information, read:

• UPGRADING
• UPGRADING.INTERNALS

Base packages (php)

Software Collections (php81)

The PHP team is pleased to announce the release of PHP 8.1.0, RC 1. This is the first release candidate, continuing the PHP 8.1 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.1.0, RC 1 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the second release candidate (RC 2), planned for 16 September 2021. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.