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.

Advanced PHPUnit shenanigans

Larry
1 September 2021 – 11:27am

Whenever I read a test method I want to understand it without having to jump around in the test class (or worse, in dependencies). If I want to know more, I should be able to “click” on one of the method calls and find out more.

I’ll explain later why I want this, but first I’ll show you how to get to this point.

As an example, here is a test I encountered recently:

public function testGetUsernameById(): void
{ $userRepository = $this->createUserRepository(); $username = $userRepository->getUsernameById(1); self::assertSame('alice', $username);
}

The way I read this:

/* * Ah, we're testing the UserRepository, so we instantiate it. * The factory method probably injects a connection to the test * database or something: */
$userRepository = $this->createUserRepository(); /* * Now we fetch a username by its ID. The ID is 1. That's the * first time I see it in this test. This probably means that * there is no user with this ID and the method will throw * an exception or return a default name or something: */
$username = $userRepository->getUsernameById(1); /* * Wait, the username is supposed to be "alice"? * Where did that come from? */
self::assertSame('alice', $username);

So while trying to understand this test that last line surprised me. Where does Alice come from?

As it turns out there is a setupTables() function which is called during the setup phase. This method populates the database with some user data that is used in various ways by one of the test methods in the class.

private function setupTables(): void
{ $this->connection->table('users') ->insert( [ ['user_id' => 1, 'username' => 'alice', 'password' => 'alicepassword'], ['user_id' => 2, 'username' => 'bob', 'password' => 'bobpassword'], ['user_id' => 3, 'username' => 'john', 'password' => 'johnpassword'], ['user_id' => 4, 'username' => 'peter', 'password' => 'peterpassword'], ] ); // ...
}

There are some problems with this approach:

• It’s not clear which tests rely on which database records (a common issue with shared database fixtures). So it’s hard to change or remove tests, or the test data, when needed. As an example, if we remove one test, maybe some test data could also be removed but we don’t really know. If we change some test data, one of the tests may break.
• It’s not clear which of the values is actually relevant. For example, we’re interested in user 1, 'alice', but is the password relevant? Most likely not.

The first thing we need to do is ensure that each test only creates the database records that it really needs, e.g.

public function testGetUsernameById(): void
{ $this->connection->table('users') ->insert( [ 'user_id' => 1, 'username' => 'alice', 'password' => 'alicepassword' ] ); $userRepository = $this->createUserRepository(); $username = $userRepository->getUsernameById(1); self::assertSame('alice', $username);
}

At this point the test is already much easier to understand on its own. You can clearly see where the number 1 and the string 'alice' come from. There’s only that 'alicepassword' string that is irrelevant for this test. Leaving it out gives us an SQL constraint error. But we can still get rid of it here by extracting a method for creating a user record, moving the insert() out of sight:

public function testGetUsernameById(): void
{ $this->createUser(1, 'alice'); $userRepository = $this->createUserRepository(); $username = $userRepository->getUsernameById(1); self::assertSame('alice', $username);
} private function createUser(int $id, string $username): void
{ $this->connection->table('users') ->insert( [ 'user_id' => $id, 'username' => $username, 'password' => 'a-password' ] );
}

Going back to the beginning of this post:

• When I read a test method I want to understand it without having to jump around in the test class (or worse, in dependencies).
• If I want to know more, I should be able to “click” on one of the method calls and find out more.

With just a few simple refactoring steps we’ve been able to achieve these things. As a consequence we achieve th

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

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

Fun with PHPUnit Data Providers

Larry
24 August 2021 – 12:13pm

In this blog post, we focus on virtual machine images and cloud deployment for ZendPHP.

Several years ago, when the PHP-FIG (PHP Framework Interop Group) created its first PSRs (PHP Standard Recommendations) they started some big changes in the PHP ecosystem. The standard for class auto-loading was created to go hand-in-hand with the then new package manager Composer. PSRs for coding standards were defined, which I’m sure helped a lot of teams to leave coding standard discussions behind. The old tabs versus spaces debate was forever settled and the jokes about it now feel quite outdated.

Next up were the PSRs that aimed for the big goal: framework interoperability. It started with an easy one: PSR-3 for logging, but it took quite some time before the bigger ones were tackled, e.g. request/response interfaces, HTTP client and server middleware interfaces, service container interfaces, and several others. The idea, if I remember correctly, was that frameworks could provide implementation packages for the proposed interfaces. So you could eventually use the Symfony router, the Zend container, a Laravel security component, and so on.

I remember there were some troubles though. Some PSRs were abandoned, some may not have been developed to their full potential, and some may have been over-developed. I think it’s really hard to find common ground between framework implementations for all these abstractions, and to define abstractions in such a way that users and implementers can both be happy (see for example an interesting discussion by Anthony Ferrara about the HTTP middleware proposal and an older discussion about caching).

One of the concerns I personally had about PSR abstractions is that once you have a good abstraction, you don’t need multiple implementation packages. So why even bother creating a separate abstraction for others to use? Why not just create a single package that has both the implementation and the abstraction? It turns out, that doesn’t work. Why? Because package maintainers sometimes just abandon a package. And if that happens, the abstraction becomes useless too because it is inside that abandoned package. So developers do like to have a separate abstraction package that isn’t even tied to their favorite vendor.

(By the way, I think it’s strange for frameworks to have their own Interfaces or Contracts package for their abstractions. I bet there are 0 cases where someone using Laravel or Symfony keeps using its abstractions, but not its implementations. Anyway… If you have a different experience, or want to share your story about these packages, please submit a comment below!)

Is it safe to depend on PSR abstraction packages?

Back in 2013, Igor Wiedler made a lasting impression with their article about dependency responsibility. By now we all know that by installing a vendor package you can import bugs and security issues into your project. Another common concern is the stability of the package: is it going to be maintained for a long time? Are the maintainers going to change it often?

Yes, these concerns should be addressed, and I think in general they are not considered well enough. But we need to distinguish between different kinds of packages. Packages have a certain level of stability which is in part related to its abstractness and the number of dependencies it has (if you’re interested in this topic, check out my book “Principles of Package Design”).

The abstractness of a package is based on the number of interfaces versus the number of classes. Since abstract things are supposed to change less often than concrete things, and in fewer ways, an abstract package will be a stable package and it will be more reliable than less abstract, i.e. concrete packages (I think this is why frameworks provide those Interface or Contract packages: as an indication of their intended stability).

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