I often come across legacy projects that have a very low code coverage (or none at all). Getting such a project up to a high code coverage can be very frustrating as you will have a poor code coverage for a very long time.
So instead of generating an overall code coverage report with every pull request I tend to create a so called patch coverage report that checks how much of the patch is actually covered by tests.
Having something like that in place also allows me to force contributors to include tests for their newly contributed code. Which in turn successively improves the overall code coverage up to a level where I might be able to go for that instead of the patch coverage.
But how to implement that?
That’s not as complicated as it sounds. As Sebastian Bergmann already wrote a tool for that.
phpcov requires us to
- first generate a diff against the last code-revision,
- then generate a coverage-report via
phpunit --coverage-php and
- then run
phpcov against those artefacts.
So it’s as complicated as
$ git diff HEAD^1 > /tmp/patch.txt
$ ./tools/phpunit --coverage-php /tmp/coverage.cov
$ ./tools/phpcov patch-coverage --path-prefix /path/to/project /tmp/coverage.cov /tmp/patch.txt
It will return a non-zero value when not all lines are covered and it will tell you which lines aren’t covered.
So add that to your automation to have it executed at whatever stage you like (I recommend in the CI-pipeline of your Pull-/Merge-Request and let that fail whenever the return code is non-zero)
If you want to see a way to implement that in GitHub Actions, check out this gist.
Recently I had to build something where an Enum would have been perfect.
It needed to run on PHP 8.0. Of course.
So what to do? I decided to build an Enum like thingy that I can easily upgrade into a real Enum once we are on PHP8.1 with that project.
Why not use a library for that? There are plenty of libraries on packagist that already provide you with the basics!
For one thing: I only needed one Enum. Not a multitude. And Adding a further dependency to make creating one enum easier that will (hopefully) converted into a “eral” enum in about half a year? That sounds bit like taking the sledgehammer to crack a nut.
And on the other hand it turned out that creating an enum from scratch isn’t rocket science.
Continue reading Enums. With PHP < 8.1 →
I’m using Eclipse for a while now. In the good old days Eclipse has been delivered as a “proper” Mac-App with all libraries contained inside the Application.
But for some time now that is not the case any more. Now an Eclipse for the Mac comes as a folder containing the Application (called Eclipse.app) and a lot of other clutter that i’m not interested in. But when I drag the Eclipse.app into my Application folder and try to start it nothing happens (apart from that nice little Error-Message).
I simply accepted that.
Continue reading Convert eclipse into a real Mac-App →
This morning I was attending Zeev Suraskis keynote at the International PHPConference in Mainz/Germany.
He spoke not so much about PHP or new technologies but what happens when technology fails. He gave us an insight into the things that happened around his last holiday in the south of Italy starting with a lost Internet-connection through a malfunctioning lens, a dead GPS-Display and his troubles getting mobile internet-access up to the dead fridge back home.
Besides the strange accumulation of bad luck it again showed me how much we depend on technology.
Continue reading Social and Ethical Responsibilities →
There has been much said about the advantages or disadvantages of unit-testing. So I will not recap on that.
But where to go after you have choosen to use unit-testing?
The following short tutorial will give you an ovberview of how to install the necessary software, how to come to unit-tests from your requirements and how to write your tests and your code simultaneously.
Continue reading Quality-Assurance with PHP – Unit-Testing →