So, if you haven't heard, PESTv2 has just been released and I thought it would be the perfect opportunity to show you how you can very quickly upgrade to PESTv2 and how you can make use of the new features that it ships with. It's super simple and there is no reason why you shouldn't upgrade your existing test suites to use all the new goodies that will help you write tests even better. So, we're going to be using our good old trusted PingCRM application to do this, which will give us a very good base, seeing as we already have all of the PEST tests we've created so far. Since the last episode of the series, I've gone ahead and migrated all of the tests to use PEST. So, we're fully migrated over to PEST now in PingCRM. Let's start in the composer.json file where we'll need to make a few updates. First of all, PEST's minimum required PHP version is now 8.1. So, if you're not on 8.1,

PEST now in PingCRM. Let's start in the composer.json file where we'll need to make a few updates. First of all, PEST's minimum required php version is now 8.1. So, if you're not on 8.1, you'll need to make that upgrade first. Then, the Laravel framework also needs to be 10, obviously only if you're using Laravel, for you to be able to use PESTv2. Now, let's move down to the dev section, which is where the big changes happen. First of all, Nuno Maduro's collision package should be 7.0 or greater. The PEST package obviously needs to be upgraded to greater than 2.0, as do the official PEST plugins. So, the PEST plugin Faker, the PEST plugin Laravel, and we have the PEST plugin Parallel here, but we can actually now completely remove that because Parallel is baked into PESTv2. You don't need any additional tools to make it work. You'll also notice in this particular project, we have a specific PHP

remove that because Parallel is baked into PESTv2. You don't need any additional tools to make it work. You'll also notice in this particular project, we have a specific phpunit dependency. If you want to carry on doing that, you'll need to change it to greater than 10, but we can just remove this and allow PEST to manage phpunit under the hood for us. With this in place, we should be able to run composer update, and I'll pass the -W flag to make it update all sub-dependencies at the same time. Okay, everything's updated. Why don't we type PEST and see what happens? Alright, almost all of our tests passed without any issues. There were three failures, and at the top of the test run, you'll notice there was a warning. Your XML configuration validates against a deprecated schema. So, this is actually a phpunit change. The PHP

at the top of the test run, you'll notice there was a warning. Your XML configuration validates against a deprecated schema. So, this is actually a phpunit change. The phpunit XML file has been updated, but thankfully, they provide an automated tool that you can run to make this work without problems. So, we just need to run the test suite again, and pass the migrate configuration flag, and it will automatically convert the phpunit file into the new format. Okay, let's now take a look at these three failures. You'll see that it says that there is an undefined function. Well, that's because in v2, the faker plugin has renamed the function faker to fake. If you follow Laravel, you'll know that fairly recently, Laravel added its own fake function, so this brings it more into line with how that works. So, let's open up this storeTest, and move over to the new

that fairly recently, Laravel added its own fake function, so this brings it more into line with how that works. So, let's open up this StoreTest, and move over to the new fake function. I can simply select all instances of faker, and instead, I can type fake. And with that done, we should be able to run our test suite again. So, the configuration warning has now disappeared. We do still have one failing test. Let's take a look at the message. Call to undefined method Closure::getKey. It's in that same test file. Let's have a look at what's going on. You'll note here we have a test, which is going to check that if you pass an Organization to the createContact endpoint, then the organization's account has to be the same as the user's account. Now, how do we do this? Well, we've set up a dataset with an organizationResolver, this is a closure, and an array of errors

account has to be the same as the user's account. Now, how do we do this? Well, we've set up a dataset with an organization resolver, this is a closure, and an array of errors that we would expect to be thrown if the organization's account isn't the same. And you'll see that we pass that organization resolver, the currently authenticated user. Now, take a look at what's going on inside the dataset. We have this funky double closure syntax. Why? Because in PEST V1, any closure that was used in a dataset would automatically be resolved by PEST. This allowed you to do really cool things like create an organization inside of a dataset, which usually you wouldn't be able to do, or perhaps access a route inside a dataset. However, in PEST V2, things have been updated to make it much cleaner to use bound datasets and closures inside datasets. So we can remove this weird double closure

a dataset. However, in PEST V2, things have been updated to make it much cleaner to use bound datasets and closures inside datasets. So we can remove this weird double closure syntax, and instead, we can type in the closure, and this will inform PEST that it shouldn't try to resolve what's going on inside here, and instead should leave it for us to do inside the test itself. Okay, so with that done, we have fully upgraded to PEST V2. It takes minutes, and now we have all of the new goodies that PEST V2 has to offer. Why don't we take a look at a few of them to finish off this episode? So first of all, sometimes when you're running the entire test suite, you don't want to see all of this information. You just want a compact format that will allow you to see if things failed, or if things passed. And PEST ships with a brand new compact flag, which will do just that. You can see we see

a compact format that will allow you to see if things failed, or if things passed. And PEST ships with a brand new compact flag, which will do just that. You can see we see dots. If there were failures, we'd see Xs, and if there were warnings, we'd see Ws, so that we don't have all of this information to pass. We have a beautiful thin line that represents our passing tests. Okay, what next? Well, in order to show you the next flag we can pass, I need to introduce a problem into our test suite. So I'll just add a true here, which is obviously incorrect, because this is a compact, not a Boolean. And if we run our test suite again, sure enough, we should see a failure. Now, if you're working in a little bit of a TDD cycle, or perhaps you're ready to ship a feature, you may come across a few failing tests that you need to fix and ascertain what the problem is. It's

in a little bit of a TDD cycle, or perhaps you're ready to ship a feature, you may come across a few failing tests that you need to fix and ascertain what the problem is. It's annoying to have to rerun the entire test suite each time. And it's also annoying to try and have to filter down using the filter flag or something similar, just to target those few tests. Well, Pest V2 ships with a really cool new flag called --retry. So if I type the --retry flag, you'll notice that it only runs that one failing test. And I can keep typing --retry as I attempt to fix the test until I have it fixed and it passes again. So in this case, why don't we come back into our test here, remove toBeTrue, and then head back into our runner and run pest --retry. And you'll see now we run the entire test suite again, because everything should be passing. So that's really cool,

head back into our runner and run pest --retry. And you'll see now we run the entire test suite again, because everything should be passing. So that's really cool, and it can save you a lot of time. I mentioned earlier that parallel is now built in just to show you that I can use the -P flag, and we'll see that the test suite will now run in parallel, you'll see it runs much faster. In fact, Pest V2 ships with parallel speeds up to 60% faster than Pest V1. So no doubt many of you will be very pleased to hear that. And you'll see that it automatically uses that new compact printer for beautiful output. Although parallel will save your skin on many occasions, sometimes you'll need to target tests which are very slow and try to actually improve them. Well, Pest V2 ships with a beautiful way to do this called --profile, you just add the --profile flag and run your test suite as

tests which are very slow and try to actually improve them. Well, Pest V2 ships with a beautiful way to do this called profile, you just add the --profile flag and run your test suite as normal. And you'll see once our test suite has finished running, we get a beautiful output telling us our slow tests. So you'll see, believe it or not, these parallel tests are the slow ones 2.04 seconds 2.04 seconds, whereas our other tests are really fast. Well, if you can remember from earlier in the series, these parallel tests don't actually do anything, they were just added as a way to show how parallel can speed up a test suite. In fact, if we jump into that to test there, you'll note that it's literally sleeping and then expecting true to be true. These tests do nothing. So let's completely remove them. And then let's rerun pest --profile. And we're told that the test suite is running

expecting true to be true. These tests do nothing. So let's completely remove them. And then let's rerun pest --profile. And we're told that the test suite is running quicker. There's still a test we can fix. But in all honesty, that is really fast. I'm not too worried. So if we run pest --compact, again, we'll see the test suite now executes in 1.71 seconds, super quick. So you can use the profile option to find and eliminate slow tests in your code base. Now let's take a look at our PinkCRM application. Again, there's a little bit of functionality that we haven't got a test for. And that's in contacts. If I select a contact and hit delete, we have no tests that check that this deletion works correctly, and that you have to have the right permissions. So what if you have something like this, where you know, you need to add some test cases? Well, pest v2

deletion works correctly, and that you have to have the right permissions. So what if you have something like this, where you know, you need to add some test cases? Well, pest v2 has a really cool feature that you'll love. Let's create a new test file called DeleteTest. And inside here, rather than writing the tests, now, I'm going to come back to this later and create them. So I'll use the new toDo function to document the fact that I do need to create these tests. So toDo it can delete a contact. And maybe we have toDo it cannot delete somebody else's contact. And now if I run pest, again, you'll see that rather than showing that as a skip or a warning or a pass, we have a toDo if I run without the compact printer, by the way, you can see that it's shown in an even more clear way where we have these toDo items. And if you only want to show toDo so that you have a bit of a list

compact printer, by the way, you can see that it's shown an even more clear way where we have these to do items. And if you only want to show to do so that you have a bit of a list when you start work in the morning of which tests you need to create, you can pass the --to-do flag, and they are the only items that will show up. So a super useful tool, I use it all the time in TDD, because I'm able to write a list inside a file of the tests I will need to create. And then I just start filling those tests out one by one and creating the backing application code. So I think you'll really love to-do's in Pest PHP v2. They are super powerful. Well, those are more or less all of the new exciting flags that Pest v2 ships with. However, that's not the end of what Pest v2 has to offer. In fact, next I'd really like to look at a cool new plugin Pest v2 ships with called the Arch plugin.

v2 ships with. However, that's not the end of what pest v2 has to offer. In fact, next I'd really like to look at a cool new plugin pest v2 ships with called the arch plugin that allows you to test your applications architecture in the same way you write unit tests. Let's dive in.