AUTOMATED TASKS All right, before we move forward, let's take a quick stop and talk about automated tasks. First, because tasks are very important, you should be writing them. And secondly, because it's a very easy change for modular applications. First, let's run php artisan tasks and see what we get. Cool, we have two tasks running. It's this two, example-tasks under feature and example-tasks under unit. The first change I'm going to make is I'm going to go to phpunit.xml and I'm going to change the DB connection to SQLite just to make things easier.

The first change I'm going to make is I'm going to go to phpunit.xml and I'm going to change the DB connection to SQLite just to make things easier. We won't be leveraging any particular MySQL features, so we can use SQLite in-memory for this just fine. If you don't know what I'm talking about, we're basically instructing Laravel to use SQLite and an in-memory database during automated tasks. For modular applications, there are two strategies that I like. The first one is you can just group your tasks within tasks as usual and group them by module. So, for example, I could go in here and I could create a directory called modules.

and group them by module. So, for example, I could go in here and I could create a directory called modules. Let me close this. And inside modules, I can replicate each of the modules we have. For example, we can create a directory called order. Inside that, we can create a directory called models. And here we can place a Task, for example, OrderTask. If I go here, I have to extend the BaseTask case as usual. Let's write a simple task. So, it, or rather, it creates an Order.

Let's write a simple task. So, it, or rather, it creates an order. Now, let's write something for the sake of tasking this. I'm going to say newOrder, like this. And then we can just dump in like this. If I go back to the command line and I run php artisan tasks, you can see that it wasn't executed. And that's because inside phpunit.xml, we have to register that directory as a test suite. We can do something like testSuite. We can call it modules.

We can do something like test suite. We can call it modules. And now you can pass the directory like this. So, we're instructing phpunit to look within tasks/modules for the modules test suite. Now, can we do this here? Yes, we could just copy this directory and use it on the feature test suite, but I like to separate it. So, we have a test suite for modules. If you want to be even more specific, you could create a test suite only for the order module.

If you want to be even more specific, you could create a test suite only for the Order module and then just pass the order path as well. For what we want to do, this is fine. Now, if I run the same command, you can see that this task is being executed. Another strategy, and it's the one I particularly enjoy, is to have the tasks within the module. So, for example, we could go under order. We can create a directory here called tasks. And let's just move what we have here into here.

We can create a directory here called tasks. And let's just move what we have here into here. Now, phpunit automatically updated the namespace for me, but you might have to do that manually. Now, if I run the test, it is no longer found. Let's go to phpunit.xml, and we're going to change this. Now, it's under modules, order, tasks, right? Let's rerun this. And okay, now it's found again. Now, let's do the following.

And okay, now it's found again. Now, let's do the following. Let's also add a task for Product. So, I'm going to create a class. It's going to be called ProductTasks under tasks. So, phpunit is already filling those for me. We want to extend the TaskCase. And let's say something like task, it creates a Product. We're going to instantiate a new Product and dump and die. We're going to go back to this task right here.

We're going to instantiate a new Product and dump and die. We're going to go back to this task right here. And let's just do something down like assert true, just so it passes. And let's rerun our tasks. As you can see, we're only getting three tasks. It is not finding this one. And it's obvious why. We haven't passed the path here. So, what we could do is we could copy this.

We haven't passed the path here. So, what we could do is we could copy this. And then we could change this for product like this. If we do this, now we are reaching the task. Another option that we have is you can pass a * here. So, phpunit will know that it should look for every folder within modules and then for the task directory. If we run this, we're also hitting this task. So, this is an option. As I said, now you have a test suite for all your modules.

So, this is an option. As I said, now you have a test suite for all your modules. You might want to be more specific. So, you could create a test suite for your product module, a test suite for your payment module, etc. The good thing is you don't have to take that decision immediately. You can start with something simple. And if you feel the need of having separate test suites, you can do that later. Okay, it's this simple.

you can do that later. Okay, it's this simple. Before we end this lesson, though, I want to add one more thing. I highly suggest that you create Task cases for each module. And the reason is each module is going to have domain-specific things that you might need to either instantiate in the beginning of tasks or fixtures you might have to load or custom assertions, that kind of thing. And it makes it much easier when you have a base Task case within your module that does not interfere with the others. So, for example, under Product Tasks, or rather under Order Tasks,

that does not interfere with the others. So, for example, under Product Tasks, or rather under Order Tasks, we can create, go back one directory. So, we're under Tasks. We can create a new class, and we can call it, for example, OrderTaskCase. Sorry, this is in the wrong namespace. So, I'm just going to put this under Tasks. And now here we can extend our BaseTaskCase, which instantiates Laravel. If you do not want to inherit from this BaseTaskCase, you can replace it with its content.

If you do not want to inherit from this base task case, you can replace it with its content. I don't think it makes a difference because you're already extending Laravel's task case. So, let's keep it like this for now. And then within your task, you can extend the OrderTask case like this. We can get rid of this. And obviously, if we run our tasks, it is going to find all of them and stop at this one. I'm sorry, at the ProductTask one.

it is going to find all of them and stop at this one. I'm sorry, at the Product task one. If we were to do an assertTrue and pass false here, this task is going to fail. So, yeah, it's this simple. There's no tricks to it. It's just a regular class at a different namespace. All right, this is pretty much it. See you guys in the next lesson. Bye-bye.

See you guys in the next lesson. Bye-bye.