Bonus Episode. I want to show you a couple of really cool command line utilities that PEST offers that will also help you as your test suite grows. So one term you've probably heard of is code coverage. Code coverage tells you how many lines of code in your application are covered by a backing test, and it isn't an indicator of test quality, but at least you'll know if you have missing tests that really needed to be added to your application. Usually coverage will come in the form of an XML file or a JSON output, but PEST ships with a beautiful coverage driver for the console, and in fact this has now been ported to Laravel so you can use it in a PHP unit as well, but it was initially a PEST only feature. In order to use it, you need to make sure you have either Xdebug or pcov or some other

so you can use it in a phpunit as well, but it was initially a PEST only feature. In order to use it, you need to make sure you have either Xdebug or pcov or some other coverage driver installed. How to install those drivers is out of the scope of this lesson, but I'm going to assume that you've gone and installed Xdebug and set up coverage mode for it, or you've used pecl to install pcov. All you have to do is run php artisan test, and I'm going to exclude a group that I've created called parallel, and then I'm going to run the coverage flag, and when I do that it's going to execute all of my tests, but you'll see at the end of the tests we receive this coverage report, so it tells me I have a coverage of 34.57%, not very high, but it gives us plenty to work towards and improve on.

have no backing tests, so lines 38-44 are missing tests, line 55 is missing tests, and lines 72-129 are also missing tests. So by glancing through this code coverage report you'll very easily be able to see where you need to go and add more tests. Now you can supplement the coverage flag with a min flag, and this is a percentage between 0 and 100. If I set this to 20, you'll see that we get the exact same output, nothing changes. But let's set this to 40, which is higher than my current minimum code coverage percentage. If I run this, you'll see that I actually get a failure, and it gives a non-zero exit code in the CLI, so if you were to run this in continuous integration, it would actually

If I run this, you'll see that I actually get a failure, and it gives a non-zero exit code in the CLI, so if you were to run this in continuous integration, it would actually fail your CI workflow. You'll see that it's basically saying that the code coverage is below 40%, which is why the whole thing failed in the first place. So super useful for making sure that you've reached a minimum level of code coverage in your tests. Okay, second thing I want to show you in this episode. As your test suite grows, the length of time it takes to execute tests is also going to grow.

As your test suite grows, the length of time it takes to execute tests is also going to grow. And just to try and illustrate this, I've added a few tests between the last episode and this episode. If I simply run php artisan test, you'll see that we have four very slow tests. I fake this with a sleep inside the code, but obviously in real life, you may well just have complex tests that are being run, and they take time to finish. Now what you don't want is to end up in a position or situation where it takes absolutely ages for your test suite to execute, because that's going to slow down the process of being able to ship code quickly.

ages for your test suite to execute, because that's going to slow down the process of being able to ship code quickly. So how can we rectify it? Well, PEST ships with a parallel mode, and what that's going to do, instead of running your tests one after the other, it's going to use the available processes on your computer in order to run the tests at the same time. And this can dramatically decrease the length of time it takes to execute your test suite. Now in order to run parallel, I'm going to need the PEST parallel plugin, which you can grab from the PEST website. Once I have that, I'll install it via Composer.

grab from the PEST website. Once I have that, I'll install it via Composer. And once installed, I'll run php artisan test with the parallel flag, which you can shorten to just -p. And you'll see that all of a sudden, our test suite runs much faster, 2.41 seconds, which if we just scroll up, we can compare to our previous run of 8.66 seconds. Now you can imagine as our test suite grows even further, the difference in time is going to grow exponentially. So it's always worth trying parallel as soon as your test suite starts to slow down your process and you need to look for some quick wins to fix.

So it's always worth trying parallel as soon as your test suite starts to slow down your process and you need to look for some quick wins to fix. Literally a single composer install can dramatically decrease the time it takes to run your tests. So that's pretty much everything you need to start using PEST PHP in your projects. I hope that this series has been of use for you. And just remember that PEST is evolving and changing all the time. New features are being added constantly, so keep checking the documentation, keep looking for learning resources on the testing framework, because by doing so, you're going to maximize your efficiency when writing tests for Laravel and other PHP code.

your efficiency when writing tests for Laravel and other PHP code.