#PHPUnit 12.1.0 has been released: https://github.com/sebastianbergmann/phpunit/releases/tag/12.1.0
![Added
#6118: expectErrorLog() for expecting error_log() output
#6126: Attribute #[WithEnvironmentVariable] for setting an environment variable for the duration of a test
The AfterTestMethodCalled,... Added
#6118: expectErrorLog() for expecting error_log() output
#6126: Attribute #[WithEnvironmentVariable] for setting an environment variable for the duration of a test
The AfterTestMethodCalled,...](https://cdn.masto.host/writing/cache/preview_cards/images/014/325/510/original/7a4c562fe99c0ac7.png)
#PHPUnit 12.1.0 has been released: https://github.com/sebastianbergmann/phpunit/releases/tag/12.1.0
Managed to get unit tests working in a pre-commit hook today - no more commits unless they pass the tests! Although every developer has to setup the hook manually because you can't easily put hooks into Git itself (there are hacky ways around this, e.g. by using post-install-cmd in Composer).
Nearly everything I work on is bespoke and legacy, so getting tests setup is a lot harder than with a new or modern project based on a framework.
A couple of years ago I wrote a #php script that mucks around with some system files. Because I didn't want to break my system while testing the code, I wrote some relatively tedious tests in #phpunit with mock objects, validating the parameters that were passed down to the filesystem.
It was a real pain in the butt, but I got the thing debugged without making a mess of my working environment.
Today I decided to add a new feature, and there's no way to express how much time having all that stuff set up saved. I copied a similar test, adapted it to the new feature, got it to pass tests, and deployed it without issue.
Coding a good test suite pays back over, and over, and over again.
Exciting News, PHPUnit and TYPO3 enthusiasts!
Are you ready to take your TYPO3 development skills to the next level? Join me at TYPO3Camp 2025 in Vienna for an in-depth PHPUnit workshop!
Date: Friday, 9 May 2025
Location: TYPO3Camp, Vienna
https://www.typo3camp.at/workshops/phpunit-in-typo3/
See you there! Let's code smarter, not harder.
Here is a recording of my "So you think you know #PHPUnit?" presentation at #LaraconEU: https://youtu.be/CpkHHxE5g7c
This will be a crazy week: today and tomorrow I am at #LaraconEU and on Friday I will release #PHPUnit 12.
Why don't you join me on Friday for a two-hour, free-to-attend, online session?
https://phpunit.de/test-smarter-not-harder.html?ref=mastodon
I will talk about PHPUnit 12, of course, and share unique insights on how to get the most out of PHPUnit in 2025.
I just found out that I can run `tidy -xml -indent --indent-attributes yes -m phpunit.xml.dist` to format a #phpunit configuration file. I love how PHPUnit can migrate its configuration files after a new release, but the new file has all attributes in one line, making them hard to read. Manually indenting files in 15+ repos after an update was a pain. Now, thanks to a 22-year old tool I can have automatic and consistent formatting.
Looking for #phpunit code coverage dark-themes, are you using it?
Did not find any native support from PHPunit's tools, just some drop-in custom.css files.
Found so far just 2 of them:
1. https://github.com/chriswpage/phpunit-coverage-theme (updated 2024)
2. https://github.com/Porthorian/phpunit-code-coverage-theme (updated 2022)
From my preliminary research: the coverage tool is using bootstrap v4, while a dark-mode was only introduced in v5.3.
I should not dig into that migration path, or should I?
#PHPUnit is developed with a focus on development environments and the command-line.
No specific testing or hardening with regard to using PHPUnit in an HTTP or web context or with untrusted input data is performed.
PHPUnit might also contain functionality that intentionally exposes internal application data for debugging purposes.
If you upload #PHPUnit to a webserver then your deployment process is broken.
On a more general note, if your vendor directory is publicly accessible on your webserver then your deployment process is also broken.
#PHPUnit is a framework for writing as well as a command-line tool for running tests.
Writing and running tests is a development-time activity. There is no reason why PHPUnit should be installed on a webserver and/or in a production environment.
The vendor directory managed by #Composer must not be publicly accessible. It must therefore be located outside the so-called document root. Should that not be possible then public access to that directory must be prohibited using the web server's configuration.
A dependency such as #PHPUnit, which is only required for working on the software but not for its operation, must not be present on a production system.
#PHPUnit 11.5.2 has been released: https://github.com/sebastianbergmann/phpunit/releases/tag/11.5.2
#PHPUnit 11.4.3 has been released: https://github.com/sebastianbergmann/phpunit/releases/tag/11.4.3
Just posted my experience of the #phpunit code sprint in munich and the topics I was focused on for the last few weeks, which got finished at this event.
https://staabm.github.io/2024/10/19/phpunit-codesprint-munich.html
On my way home from a great #PHPUnit Code Sprint in Munich.
Thank you so much, @localheinz, @markusstaab, @sebastianheuer, @theseer, Nicola Pilcher, and @Schrank, for taking the time to work with me on PHPUnit for two days.
And another "Thank you!" to celebrate.company for hosting us in their office.