Your PHP Tests Are Not Enough in 2026

追加: 2026-05-27

[00:00:00]What's up, everyone? It's Nuno here. On today's video, I'm going to show you how do I configure my testing pipeline. We are going to see how do I work with Pint, Rector, Pest, PHP type coverage, and more. When people think about testing, they only think unit testing, but in fact, it can be so much more than that. It can be things like static analysis, formatting, or linting, and much more. Just to give you the perspective, let me just show you some of the tools I use literally all the time when it comes to testing. I use Pint, I use Rector PHP, I use ESLint and Prettier, I use Pest PHP on the mode type coverage, but also on the mode unit testing. I use PHP Stan, I use TypeScript. As you can see, it's much more than simple unit testing. So, first of all, this file you are watching right now, this is my composer.json. And a lot of people don't know, but you can actually set up scripts on this composer.json file. What is a script?

[00:00:45]Well, it's basically a way of typing composer demo, and then all these scripts are going to be executed automatically. Here, for example, I can just come here, type something like composer demo, and by doing this, I see subscribe, which is exactly the result of this script. Now, what real example is my composer lint, which will execute Rector, will execute Laravel Pint, will also execute on the NPM side ESLint and Prettier. Meaning that if I execute composer lint, I see all those tools being executed at the same time. Now, this is actually super important because if a new team member is coming to your team, he doesn't need to know which tools this project is using. You just need to type composer lint, and that's it. Now, the composer lint is useful, but this one is actually even more important because it will run exactly the same tooling as linting, but it will run them with the dash dash test flag to make sure the code is properly formatted. Now, just below, I have this script called the test type coverage, and this is honestly one of the most underrated features of Pest PHP.

[00:01:40]Basically, make sure that your entire code is fully typed. Let me show you an example. I'm going to move here into this update user, and I'm going to just remove this void return type. And by doing this, now if I go to my terminal, I execute test type coverage, Pest PHP will tell me literally it's missing a return type on the line 22. How cool this is. And now I can just go there, reintroduce the type, run type coverage once again, and now we are with 100% type coverage. Now, just below type coverage, we have test types, which runs PHP stand and TypeScript. And honestly, it's 2026, my friends. If you're not using PHP stand, what are you even doing? All right, just in case you don't know what is PHP stand, I'm going to literally just try to access to an attribute that does not exist. I'm going to run PHP stand now on the console by typing composer test types, and automatically PHP stand tell me exactly what is going wrong with my code base.

[00:02:27]This is insane, okay? This is a tool that goes through all your project and lets you know what is wrong. And finally, we also have the test unit, which will run past PHP on parallel, very important to be super fast, but also with coverage at 100%. You've probably have been listening people telling you that code code coverage is not important. That's okay?

[00:02:45]That's totally Code coverage is super important, especially on the era of AI.

[00:02:50]You want to make sure the code generated by AI is fully covered, and for that you can use code coverage with past PHP. And finally, the most important script on the planet called it composer test. This one will aggregate all of the scripts we just mentioned, and will aggregate in them in the single script called it composer test. Let me just show you. I'm going to just run composer test here, and this will run code formatting testing, will run static analysis, will run type coverage, code coverage, will run the entire story. How cool this is.

[00:03:18]Now, why all this stuff is game changer?

[00:03:20]Well, for a couple of reasons. The first one is that if a team member just joined the team, you can literally run composer test and you have the full testing pipeline. Reason number two, your GitHub actions workflow no longer need to have all of the scripts being executed. You can just simply run composer test, and that will be your CI. Reason number three, you can literally tell your AI coding agent that it's super important, okay? Super important, always but always run composer test at the end of a coded feature that you have made. This is dope. And this is my testing pipeline.

[00:03:51]Honestly, if you like this type of content, make sure that you watch this video. This video is a 40-minutes talk that I mentioned all of the tooling I use and I mentioned a lot of tips like this. And that's it for this video.

[00:04:01]Don't forget the best way to support my work is subscribe to the channel and click on the like button. And also make sure that every single time you watch a video of mine, you watch the entire video. Love you all. Peace out.