 So, let's see your first test, and what for to be confident, if you want to be more confident about your data at the assertions, you can use your assertions by sending negative numbers to give it a try. Decimum points, and run the pitch given again, then it will show you that you ran two tests, but much more assertions. So, I'm going to show you a unit test for the subtract method, but if you go to the technique, you can come up with this example code. You can go a little bit about the configuration testing, because if you learn about the WordPress plugin, you probably think that, hey, I don't write only simple calculator classes, even with your WordPress plugins and metadata costs, change some options inside the options table, use some other classes. So, in that case, if you want to test integration with WordPress, it's very simple to unit this. The unit tests are isolated to your code. It doesn't run anything else, or if your code is being integrated with some others, it is. But then, you write some similar code for testing, but those tests are called integration tests. Let's say this code. Let's say we add one more class called POSCAP data, and it has a constructor. Then this constructor expects the calculator instance, the instance of the class we just created, and it has an update method. Update method receives POSCAP and two numbers, and those two numbers, it will add those two numbers using the calculator's add method. So, you are passing those two numbers as an argument, you see, and it adds this value as a metadata to that POSCAP ID, as unit tests, the plugin demo, and data key, for that key, it adds this to the POSCAP ID. So, how are you testing? As I mentioned, very similar. I'm creating another, and this class I have is it updates the POSCAP data. As I said, it's not starting with tests. I did start the name with test-perfects, but for integration tests, it's better to give a very descriptive, expected functionality. It's like a choice you can decide. POSCAP data class, but you don't have to remember it's expecting an instance of calculator. So, we're creating a new calculator and testing it to POSCAP data's constructor. Now, look at this code. This factory POSCAP ID. This is one of the benefits of using this WP unit test case. WP unit test case provides you with these activities. So, you can use it to create, on the client, generate new POSCAP and use it inside your test. Once your test passes, it destroys, once your test suite runs, the wordless test students see it automatically destroys everything and it creates a lot of information. So, it creates a new POSCAP ID and now you have a POSCAP ID. Now you can run that POSCAP data update method, send that POSCAP ID and send some numbers to it. So, we expect that this code will add these two numbers and update the POSCAP data, right? So, we can assert it. We can write an assertion to it. Here, I'm reading the POSCAP data now. I'm not checking the result of the function. It's not returning anything. I'm checking what it did, if it did the job I expected it to do. So, I'm reading the POSCAP data using the POSCAP ID and the method key and then I'm asserting that it's out here. I'm reading it from the database. So, if you're a test, write the file, open a database connection and do something more to network on some VPI calls, then those tests are almost ready to do. Testing or writing tests can be a bit hard to get started, but it's like physical exercise. So, it's hard to get started with modeling or so. First, it may seem pointless why you need to do this, but in the long term, you will see the benefit. You will see the benefit as soon as you do very, like, a little bit significant change in your code, a little bit significant refactor on your code. You will see the benefit. You will see how it will be easy to refactor your code, change the function names, class names, move them over to other colors, etc. You will immediately see the benefit. I will give you some links to learn more about this. You can open the link to this presentation after this call. You can go to these links to learn more about this stuff. You can go to the sample code I used for this presentation, I want to integrate that code with Travis CI. You can see how these tests are being automatically ran in the continuous integration environment. As soon as I push some change, Travis CI logs these unit tests using different versions of PHP and shows me the result. So, there is a link on the reply app too. You can go and see it. You can go to code pages of, like, web norm, WordPress plugins, like JPEG, Yoast, or AMP, for your community, others that you know. You can take a look to the pool bar plugin template that can be used for scaffolding. There is an alternative to WPCRIs template. That's another template that XWP developed. Learn more about PHP and assertions. There are a lot of other assertions. You can learn more about walking objects, stop methods, dependency injection. These are more advanced topics that will be very useful. You will be able to do those things organically when you are testing, because it's not always possible to test some stuff. Sometimes you have to create more objects of some other classes. With the team, what is your hardest part on getting other people to actually do a unit test for a function they write? So, we do the code reviews. They should start the practice of doing code reviews. Probably no one has used GIMPAR, or GIMPAR. It allows you to read Google requests or virtual requests to your code. It's just the developer creates a branch from the name branch. It does everything that he wants, but he cannot merge the message. He cannot merge the language. We disable access to the name branch, but we can create a full merge. We are asking the senior developer or other team members to see the style of what he changes and merge it with the merge button. Before clicking the merge button, and if there are issues, I can comment right away and ask them to change it and send it to the next. So, you just have it as an internal policy that no one can merge unless they are doing a unit test. Another thing you can do is creating automated coverages. It's a bit hard to do in WordPress budget, but still you can do it. So, coverage reports shows how many percent of your code is being covered by tests. It shows how much of your code was executed when you ran the unit test. So, you can automate that and see that no one did it. You just identify what you were expecting. You identify what you were expecting, then you choose an assertion. For example, if you are expecting that you get an array, as a return value, you get an array, then you assert that the return value is a array. If you are expecting that the array contains five items, then you run the count function and assert that the result is equal. If you are expecting that one of the items will be, let's say, number one, then you can assert that this array contains... You should run on your local first, but you have to run it on the server still because everyone wishes to code and the CI server wants to... And also, when you run the code locally, when you run off the small team on your machine, you may choose to run it using only one version of WordPress, but the CI tools, you cannot figure it out. If you go to the GitHub platform, you will see it. It prints a new one. The command that I mentioned prints a new one, but there is a command for creating a test suite for the existing code. It goes to the documentation, and it's a similar command, but it has a test suite that's over between a configuration file and your existing code. And you can write a test first, see if it fails, and then write a code. It takes the payload. So you can write a test, create an instance of a class that doesn't exist, and try to run the method of that instance that doesn't exist. And it fails. Then you start creating a class. Thank you very much. Thank you very much.