I realized I hadn’t written an article in quite some time. Now that I’m not actively using the social app formerly known as Twitter, I figured out that the only way to share some useful things I find out while developing is by writing them on my personal blog.

I mean, that’s the point of personal blogs for developers, no?

Okay, so back to the topic at hand.

Writing tests

If you haven’t done it already, please, start writing automated tests. I don’t need to repeat myself on why this is important.

Tests make your code more resilient to bugs.

The main testing tool (or at least the most used) in the PHP world is PHPUnit. When writing tests you aim to have a large code coverage. Or your managers go and say that they want a high code coverage in your codebase – they LOVE their metrics.
It’s one of the metrics that will show how well your codebase is tested. It’s not ideal, as you could cheat to achieve high code coverage.

Tests should be written in a way that will cover both happy and unhappy paths, check for edge cases, etc. (check this amazing video by Juliette Reinders Folmer on writing quality tests).

Choosing the right driver

Whether you’re using PHPUnit, Pest, or wp-browser, all of those testing frameworks allow for generating code coverage.

In addition to having a proper configuration set up, you’ll need a code coverage driver.

You can choose between Xdebug or PCOV. I am using Xdebug, mostly because I actively use it for debugging while writing my code, and in version 3 (which has been out for quite some time now) the code coverage generation is really fast. Running automated tests without code coverage is faster, as you don’t have the overhead of analyzing code that tests went through.

Running the tests with code coverage

To run tests with code coverage you’d run a command on your terminal like:

XDEBUG_MODE=coverage vendor/bin/phpunit tests --coverage-html tests/coverageCode language: Bash (bash)

This will enable Xdebug’s coverage mode, check all the tests in the tests directory, and will write an HTML file inside the tests/coverage folder.

For Pest, you’d write something like

XDEBUG_MODE=coverage vendor/bin/pest --coverage

Now, this is all cool and well, but we don’t want to write this all the time (yes, most terminals remember your input so you’d just press the up arrow until you’d find the correct command, I did that as well).
Is there a better way that will allow us to type less? Because we all are lazy, don’t lie to yourself :D.

Yes, there is!

Using composer

We can utilize composer scripts. There are some developers who are not crazy about those, and I get it, but it gets the job done.

So in our composer.json file, we can actually write something like this:

"scripts": {
	"test:integration": "@php ./vendor/bin/pest --group=integration",
	"test:coverage": "@php -dxdebug.mode=coverage ./vendor/bin/pest --group=integration --coverage",
},Code language: JSON / JSON with Comments (json)

So you’d use it like this

composer test:coverageCode language: Bash (bash)

Bonus points if you alias composer with a letter c :D

What do all of these mean?

@php will automatically resolve to whatever php process is currently being used.

–dxdebug.mode is a way to define INI entry (because when you install Xdebug, you need to set its configuration in the php.ini file, or other *.ini related files you see when you type php --ini). In this case we are just setting the xdebug.mode value to coverage.

The last part is just running the script to run the tests (phpunit, pest or codecept).

And that’s it. Now you can save an extra 5 seconds to your workflow when running tests from the terminal :D

Hope you find this short tutorial useful.

Happy coding!