Mockito: Unit testing in Java

1. Welcome to this course!: Hello guys and welcome to this course on the Java unit testing framework, Mockito. My name is elks and I'm a software engineer that has been using this framework in my coding workflow for quite some time now, when I heard of the possibility of creating a course to explain more about its use and also benefits. I was quite eager to develop one. This class will be structured in 11 lessons that can ping practical steps for you to take in order to understand exactly what can be done with Mockito, I will first evolved show you how to set up a local environment on your machine with Mockito on it. Then we will take a closer look at all the ways in which these two makes unit testing easier for us. Things like spice, argument matchers, the in-order and verify functions, specifying return values for methods and so on. If you are interested in bettering your way around unit testing in Java, this course is for you. There are no other prerequisites then a computer with an Internet connection. As for the project of this class, it will be extremely practical and it will involve you to follow the steps presented during this course. So you can start on your journey of writing unit tests for the code you are developing using Java. We thought, we said, I think we already see you in the first lesson. 2. Installing the JDK: Guys, welcome again to this tutorial. In this tutorial, we are going to get started learning by of course, getting our environment ready on our local machine. So first of all, of course, being the framework that it's using Java code, we need to make sure that we have the JDK installed on our local machine. So GDP comes from Java SDK. Sdk comes from software development kit. For this tutorial. We are going to use the version of one dot dot 01 for Java 16. First of all, you need to make sure that you have these JDK installed on your computer. Now, I have a Windows machine here. How would you check if you have this JDK already installed on your computer or you don't have it, you just need to run your CMD. So your command prompt with administration, and then write in each java dash version. As you can see, I don't have it installed. And the thing that brings on my screen is Java is not recognized as an internal or external command, is not installed. This way you can confirm that you don't have it installed. If it would have been installed, the message would be something like Java version and then it will tell you the version, then some other farming messages. But now that we know that we don't have it installed, we are going to go on image store it. If you already have it installed, you can skip to the next step that is going to be in a few minutes. But for now, how would you install it would be to go to the link that I provided in this screen right here, and that's oracle.com, Java technologies. Java SE downloads the HTML. This you can see we have here the Java SE downloads job, I see 16. And we can click under the Oracle JDK on JDK download. Now it will redirect us to the Java Development Kit 60. So you see Java SDK and then scrolling down, you can choose the version for your operating system, in my case, is a Windows 64 beats, so it's the version right here. I will directly select the executable files so we can go on and review the agreement, then click on Download. You can see the executable is actually downloading right now. In just a few seconds, it will be done so we can click on the nail. And as you can see it starting this installation, welcome to the installation. We can click Next. Now, the default bath where it would install it. And I suggest that you leave it SEC is C Program Files, Java, dish, and then the JDK version of it. The reason why I tell you to leave it this way is because we will be later setting some variables of the environment. The spec. And if you change it, you are going to need to remember that Beth it's changed the two and have it may be based in Notepad document. But for now we can just go on and click Next. And as you can see, it will basically start installing be GDK, that it was completely installed. We can close it. And just like that, the first step of this tutorial is done. The second step, as I said, we need to set an environment variable, more specifically the Java home environment variable. And we need to point it to the bath where we stop these JDK. So to do that, you need to go to the Search button, then write the system environment variables. Click on Enter. Then here on environment variables. Then we can click on New. Then we have the variable name, which is going to be Java under home, and then the browse directory. And then the directory is going to BSA said Local Disk C Program Files, and then of course Java, and then this JDK for the debt, it got us. So this is going to be okay. And as you can see here, the Java home system variable is now added and the value of it is the actual Beth. Now we can furthermore, other than adding the system variable of Java home with the value of the path in here at bat, we need to edit this and also add new. And then we need to graphs for the bin folder debt with edit here. And then as you can see, the Java JDK and these folder of being right here after I reached, started my computer. Because if you do not restart it, you will not be able to see that the Java installed when you restart it and enter java dash version, you can see that it actually tells you some information about the attributes and specifically the fact that the JDK installed successfully on your computer. Once again, I added into the system variables in Java underscore home set to the path where the GDK was installed and I added to the back. So user variables for your user, then you click on it, click on Edit, and then new browser, and then the bin folder of JDK installation breath. If you do that after installing the JDK that you get from this link, you are going to successfully installed the JDK on your computer and complete the first two steps. For now. This was about the Enter. I thank you guys very much for sticking with me up to the end of this lecture. 3. Installing IntelliJ IDEA: Hello guys and welcome back to the tutorial. For this tutorial, we need to obviously have an IDE in which we can jump code. And for that we're going to use the IntelliJ idea IDE, which my opinion is the best IDE for java out there. But we can just starts to grow for intelligent and then click on the Download on JetBrains website. This will redirect you to the download of Intel G idea. Now of course we are going to use the community version. Not the ultimate is do not write code for it enterprise. We are just going to use these from the comfort of our own homes. But if you want to do that by all means, if you have a company or something like that, you can go for the ultimate. It's just that for this tutorial, we are going to go with the windows dot EXE. And as you can see, download basically started. I'm going to get back to you guys once it finishes. Okay, so I'm back that Intel has been downloaded beads and now when we click on these executable file, we are going to be greeted by an installation processes. You can see the setup weekend just go on into installing. It eats our default destination folder in the C drive. Now, the 64-bit longitude is what you're going to need to select here. Then we are going to associate the Java files with it. Then we can update the context menu, edit the Open Folder is project. The launchers directories to the bed. I don't think that's necessary is that we'll open things up from the actual application so we can go on and click on Next and then install it. After it has been installed, you're going to be greeted with these final window. And you can choose to run Intel J after these actually finished installing and we can click on debt. We confirmed that we have read and click on Continue. You can see the Intel G ID is going to open up right now. And it will ask us to open a project or create a new one. And then of course, some plug-ins into the customization window regarding Color Themes and stuff like that. So this was about it with the installation of GID for the job that we're going to use in this tutorial. It is a pretty simple and straight WordPress is, but I thought I should do the tutorial on these just to make sure that you guys are aware of the way that you are going to get up and running. Hopefully, you got something out of this tutorial, and I really look forward to seeing you in the next one. Thank you very much for sticking with me up to the end of this lecture. 4. What is mocking?: Hello guys and welcome back to this Mockito tutorial where we understand how we can better against our Java methods using these testing framework. In this lecture, we are going to get a peek into some theoretical notions about mocking. Just before we deep dive into the Mockito testing framework and understand how we can write code to test our methods. We are going to cover a few basic stuff like what is mocking, what should be marked, different types of marks and this sort of thing. Just so we can have a good knowledge of them before we apply it. We understand the process that we will be going to where writing the actual code in our IDs. Now in simple terms, the marking process refers to providing control, instance or implementation, or even dependency that the code under test depends on. In order to test each core logic. In the case of our first Mockito application, the chair going to look at in the next lecture of the section before we get into more detailed features of Mockito, I'm going to present you a basic application using Mockito and in debt application. The method that will be referenced in a function that we want to test will be mocked and will be made by asked to return a specific value that we desire. So this is the practice of marking. These marks come to rescue in the situations where no matter whether you are dependency is up and training or not, you are always guaranteed to run your business logic with a programmed response for the dependency that's being called from the code under test. If you ever heard the third test double essentially refers to an object which is replaced by an equivalent tree or object instance or dependency. There are two main advantages as to why the mocking processes useful when testing our code. You can think of these as the base pillars that we base the use of our unit testing upon. The first advantage is the efficiency that the smoking process brings with it. Because with mocking, we are assured that there is just our code that gets executed. When being tested. All the other dependencies will have hard coded, mocked values given by us and that code will not be actually run. Now, the other reason is regarding the exact control that we have on all the other components that our test IF function needs. This can create a separation that is very beneficial. Helping us this way to quickly see if the function that we want to test is behaving AES-128 or not as the parts that are used in the process that are not actually part of the function that we want to test. We'll have set values that will be marked by us. We will already know what the return and how they behave. And we only limit our testing. The function that we actually wanted to test. There are different types of test doubles or marks. And we're going to run through each one of them just in order for you to have a better grasp on their classification. And in a future lecture, if you see one of these names, you're going to be familiar with it and quickly understand and have a reference point as to what exactly that type of this double E's. First of all, we have the fakes. The fakes are working implementation that is pretty similar to a real dependency, except the fact that it is situated on the local machine where the code under test is actually staying. Here, the example that is most often used and the scenario we are fakes are the most useful. When dealing with the persistence of Theta. When dealing with databases. And instead of fitting a real production database, test uses a simple collection or an in-memory to store data. And why that is very useful is because you may not want, for each test that you do to actually populate some rows in the actual production database. Or even you have a testing database. Maybe you do not want to populate it because there can rise some problems when we do that. First one would be that Daniel have to delete it. Second one would be the time and efficiency that is wasted on these two operations. Even to say that database is not even depth that you want to test. We want to test a method that's calling the actual database. You wanted to see how the function behaves and not if the call to the database is actually working, that should be in another class. If you have a good separation in your project. And that class should be in the project of repositories, where the staff regarding the database is still tweak. What fakes are used most of the times. They are very important from this a perspective. Next we have the stubs. And this stuffs are just pre-configured responses when a dependency is called from the system that these 100 tests. Now, other than stops, we also have Spice. These are different from the stops, fakes and also marks because the real function or dependency actually gets called. In spice. It has some watching mechanism that is attached to this call for Delta B test and post the call this watching mechanism. It can be verified whether the coal was actually triggered or not along with the parameters. And lastly, we have the most important type of test double that we are going to concentrate the majority of this course on. That is the mocks. The marks are special instances of objects and the subjects responses can be specified by the tester. That's what makes them unique. The fact that the Mach gut called can be verified SAML assertion in the test. And this is going to be the angle in which Mockito we'll shine, as you will see in the preview project that I'm talking about. And we will get into that in just a moment in the next lecture. It facilitates the creation of mock objects seamlessly. The way it does this is by using the reflection feature on Java in order to create mock objects for a given interface. So you have an interface and it basically creates an object instantiated as a concrete. But that concrete doesn't really exist. You just mark it till you make it up and make it return some values that you think in line which you are interested in order for debt values to appear in the function that you actually want to test. And furthermore, to see again how the function behaves when it has controlled input parameters given I, either as parameters or as the results of the functions that get called Long image. Now, just a few words on why Moche W so popular and you should choose to study, is that this framework allows you to create and configure these mock objects that we talked about. That would be pretty obvious from the title of this framework as well. But Mockito use greatly simplifies the development of tests that you do for either classes with external dependencies or simple methods within these classes. If you, the test statistic framework, you can, as I've said, mock the external dependencies and also insert the marks into the code under test. Dose that you want to give this specific values to functions within the function that you want to test in order to see how it behaves. You can, of course execute the code under test with monkey DO and also validated the code is executed correctly in this controlled environment that you set up with the marking process. This was about eat for the theoretical mocking notions that you shoot, have in place just before we start the actual mocking in code and see how that works. Hence, on. In the next lecture, we are going to see a quick look at the first Mockito project that I will have set up using the gravel dependency resolver. And if that sounds interesting, I look forward to seeing you guys in the next lecture. And I thank very much for sticking with me up to the end of this one. 5. Quick look at a Mockito project: Hello guys and welcome back to this Mockito tutorial where we understand how we can better test our chatbot methods using this unit testing framework. For this lecture, we are going to take a quick look on how we can set up our project in New Delhi in order for us to write unit tests that are mainly using the Mockito framework. Once you open up IntelliJ, you can click on New Project in order for you to obviously enough greek, a new project. Then in this window that you see on the screen right now you need to select Gretel. Then you need to have Java ticked and the SDK of Java that you have downloaded on your local machine. I already had a lecture now you can do that. But if you already had it installed, you can, of course, add JDK. So blink the path that you have on your local machine or you can directly download the TFEU did not follow that step of downloading your GDK directly from the intelligent, but we got it. So we can click on Next. Here are the naming of our project. I'm going to name my project or tutorial. And the location is going to be the default one which is situated in the Idea projects folder. Then the artifact ID is going to beat tutorial, the group ID or ORT dot examples. That's pretty straightforward. And when clicking on Finish, going to select the new window is I've already had a window opened up with another project. Now you can see that we have basic project opened up and it is pretty much ready to write code in. And you can see that when it opens up, Gretel is going to make initiation built on it. Just to see that everything is fine and get it all ready to go. You can see that the build was successful. And here on the right part we have also a great toe tap without the task of building, assembled, built, and all that good stuff. And you can run each of these in order for you to say that it's all good, but it should be everything should be in order on your environment if you follow the steps that I just described in class lectures. So the first thing that you're going to need to do in order to get Mockito up and running, is going to go to this file of bill to that Gretel right here in the project window opening top and on the dependencies section on line 12, you're going to need to enter these two lines. So test implementation of our jeep. That Mockito, Mockito in line 377 and Mockito, you need to Jupiter 377. Once you enter these two values, you can see that you have this elephant. It also has a synchronous sessions sign in the bottom right of it. And if you hover on it, you can see that the means that you can allow to the gradual changes. And it basically detects that the project structure has changed. And in order for these changes to be assimilated into the system and to build based on it and resolve all the references, you need to load this gradual changes in. Once you click on this, you can get another build was made. And once this was made, you can basically go on and write your code. The code is going to be placed in these two folders. You have the main folder with the Java sub folder where you're going to place workplace, these interfaces and so on. So basically that's the code that is going to be tested. The release code. So to name it in the test folder, more specifically again, in the job a sub-folder, you are going to make a test classes. The classes are going to use Mockito in order to test the methods of the classes that are available and written by you that you want to have tested in the Java folder of the main parent folder. And of course, you can just go on after this basic setup to ripe your Mockito unit test. Of course you have to import Mockito, but that's just a line of code. More specifically is import static ORT that Mockito dot Mockito with a capital letter M and then dot star in order for it to retrieve the whole a library. And then after that you can use all the good stuff like methods of Mach when and so on. We are going to of course get into in the next lectures. But this was above it. Now if you do not see that your Gradle simple solution building like in my case, it was automatically built. What you need to do is you have to click on this blue grid on and then right-click on it and then run tutorial. And this will by default, execute are built on the whole project. Of course, it will execute it with all the dependencies that you enter right here. This was basic environment that you need to have setup on your local machine before you go any further, this tutorial, if you want to do, actually have some following good experience. So if you want to replicate what I do or do it in your own way or similar ways, because starts with the dependencies and this is the way you need to set up your Intel J project. But this was about it for this lecture. I look forward to see you in the next ones where we are going to take a few keywords, notions and stuff that the Mockito framework and do more in detail, understand it and take a deep dive into it. That sounds interesting. I look forward to seeing you guys there. And once again, thank you very much for sticking with me up to the end of this lecture. 6. Setting up your first Mockito project: Hello guys, and welcome back to this Mockito, Java framework tutorial, where we better understand how we can unit test our Java methods using this testing framework. For, for this lecture, we are going to take a look at first application that we have, a few of the concepts that we are going to deep dive into later on in this tutorial. Just for you to make the picture of how a project would look like in each entirety. And also how would you create the starting from 0? For starters, we are going to of course, head into our chosen IBD for Java. That is IntelliJ J, as you saw in the last lectures. In you're going to create a new project of course. And you can either go file new project or if you don't have already an open project, then it will not open anything but starting window where you redirect you to open a project or a new project. You can set up a new project and what you want to select Next is gradual. Instead of simple Java. The reason for that is that it makes our job much easier when linking the Mockito framework in our project. So instead of just going on and downloading the GIA IR files from Maven repositories, the ham crest JAR file, the Mockito, and also linking DOS system variables to the back. What this will do. Grader will automatically link Mockito very easily as I will show you in a second to our project. So we will use grid off for this tutorial. Just in case you don't know, I will run you through a quick description of what credit. So you can think of is just a tool for automation. So what it does, it's automating the creation of applications, it making it much easier and faster. These are automation includes the link in packaging and compiling of different parts of your code. But for now, you can just choose Gretel here on the project density j, you need. Of course, choose JDK that you installed. On your local machine. We installed our 16 JDK debt is automatically detected by intelligent because we left it at its own default path. But if you chose that path in a different way or you have a different version of JDK installed, it should be automatically, as I said, be chosen here. But if it doesn't, you can either download JDK if you do not have it and he'd be automatically downloaded for you. You don't have to go through all that process from the earlier lecture. Or you can add your JDK if you already have it installed, but it is not detected. You can choose a path of where you install that bin file. But for now, you can also pick Java and then hit onto next the name of the project and the location. Also the artifact coordinates as the artifact ID are entirely up to you. So this will not in fact our project in any way. Then when you click Finish, it will open up a project for you by default starting from the bottom width not included. Of course, we are going to do that in a future lecture and I will run you through exactly how the dependencies are built and what you should do in order to import Mockito and all that good stuff. But this lecture is just in order to show you a quick project that I set up right here with some classes that are actually working together with the Mockito framework. In order to test specific method from a specific class, we are going to take a look just for you to get a better idea of how things work in this unique testing framework. You can see here I have industrial sees file, the main file. Here I have a Java. A file, of course, along with the main file, we have the testfile where intuitively enough, we are going to write our test methods. In the Java. We're going to just declare our classes. Types of methods that may be we want to get tested. For starters, we have the car glass here. This class has three fields, car ID, that's a string, name, that's a string and quantity that's a string. And we imagine these exercises like some kind of authority that is selling cars sell well, I called it the dealership. And we also have a car service that facilitates these transfer. Now another observation here is that when you hear that class has service in its name, you should automatically be thinking at that class is doing some methods for your other classes. We've been US service in it. And if you hear repository that something to do with persisting good data, storing it in a database and so on. That was just a quick parenthesis. So now moving along, the class car, of course has a constructor with all three parameters that yet initialized here. And then we get some setters and getters that are public. And through this, we're going to actually set or get our private fields achieving this way. Done encapsulation, good practice. This is the list, nothing really out of the ordinary here. Just some fields that yet set and get cell wall. We cannot really test anything here, but we are going to see that we are just testing or class that easily do. Well, be further along here now, we also have the car dealerships. So this is the method that we will test the glass cell. First of all, we import Java util beast as we are going to make use of the list right here on line 15. But the class car dealership has to filter. You need one that's car service, which is an interface and wine list of cars because the dealership would have at least of cars, of course. Now the car service gets getter and also a setter. And then the list of cars also get a in the getter. Lastly, we have another method here that is going to get tested using the framework case. You will see in just a moment, what it does is it declares a variable of type double called market value, and it increments it with 0. Now, we are going to iterate to the cars least that he's a member of this class. We are going to increment the get price of a car. So the car services can see it's just an interface that has these signature of get price here. And this is the method that we are going to mock using Mockito to return something that we wanted to. That's what mark means. And other than that, we are going to multiply the price that we are going to mark the value that we are going to give. The quantity method that of course is in the car class. The quantity that returns how many cars there are. Finally, after iterating through each car and incrementing it with this value of multiplication, we are going to return this value. So as I said, the car service has this signature, a method that is not actually implemented. And we are going to now move on to the testing class. As you can see under test and Java, this way grid, we don't know that this is the testing method. Here is the magic happening, so to say, and Mockito is involved. This is the class of card tests that we are just going to import some utils that we are going to use. So with this, you can see we are importing the Mockito. As I said in a future lecture, we are going to see exactly how we can import these Mockito using Gretel. We are starting to in the class of card tester here. So we have a car dealership, the car service. The service is an interface. Here we have the main method that is the entry point where we are going to run these, this pretty straightforward. We are declaring card tester, which is this class. So we are going to instantiate it and then you are going to call it setup for it. So the setup is this method right here that instantiates the dealership and the car service. Can see for the car service that's just an interfaces I've said in does not actually implemented. We are going to use the mock method of Mockito. And we are going to give you the car service and glass. So we are going to just mark the class as it will be concrete class in not just an interface for the dealership. We're going to also set the car service to these marked car service, as you can see here next into main method after we set up these tests, their object of type card tester, we are going to code this test market value. And depending on the Boolean and it returns, we are going to eat that framed best if the test passes or fails. If it fails. Getting deeper into that test market value, a method. Here we are just going to declare a list of cars. Then I'm going to actually instantiate two objects of type car. The first one being Lamborghini and the second one being an Audi. Going to use the constructor with all the actual values. We are going to give them some stock ID, some names and the quantities we have to learn working nice. And three are these, both of these cars, which are actually lists of cars because these are to begin using these three or these are going to be added to our list, of course, that is called the cars, as you can see online there to 1637. Then on 40, we're going to call the method on the dealership object. That's a car dealership. What these set cards method did was, if you remember adjust the attributing the list that we give it as parameter to the list of field to the car dealership. Furthermore, after we do that, this is where demo.com scene and of course we are going to have a later lecture where I will explain exactly what this method does. But for now, just so you can get the bigger picture, what this method of when receives basically a Call. It says when the gap price method of Christ's service would get called with a parameter of Lamborghini. Then you should read 250 thousand, which would be the price of Lamborghini I estimated. And then again, when they get price method of car service would get called using the car, then you should return 50 thousand. Again, it marks these calls. So the code doesn't actually have to go through all get price class because you're just going to want to test the market value method. And that's what it does. It marks the glass of the method of get Bryce. And after we see these, you can see that we are going to call the get market value function from the dealership glass, which was this one. And as you can see here, we are marking the Net-price method because that's not what we want to test. We just want this to get market value method. And as I said, when this would get called, it would iterate to the cars and first of all, it will deliver it to the number guineas. And when the car service get price of Lamborghini would get called, the Mockito tells you to return to 50 thousand and not even bother to call the actual get price, which of course is not even implemented because this is an interface and we are marking it. Then all the ADI the same way and beast allows us to test the get market value method in very controlled conditions and also very efficiently as they get price method is not going to the cold et al. We are going to, as I said, call it from the dealership. After that, we are going to turn the market value is equal to 650 thousand, which would be the correct value given the fact that 250 thousand times two is 525,000 thousand times 350 thousand. Add those two up and you would get 650 thousand. Of course now, it is going to print either pass or fail, depending of these true or not, the value that this test market value returns. So if we right-click on the car tester class, we say Ron Cortez domain. You can see that right now is actually building the whole project up and interest. Second, you can see that it is a best. Now let's see if it works. If here we would have 65 thousand, which is not the correct value, you should get a fail here. So let's see if that happens. Does happen. Now, this was about deed for the first introduction on Mockito. Seeing a bigger project in town, Mockito would get used in an already set up project. But starting with the next lecture, we are going to gradually present from the start how you can create your first project. Also present particular keywords and features of the Mockito framework and how they are used, what they do, and so on. So if that sounds interesting to you, I hope I will see you guys there. And thank you very much for sticking with me up to the end of this tutorial. 7. Specifying return values: Hello guys and welcome back to this Mockito tutorial where we better understand how we can test our methods in Java using these unit testing framework. In this lecture, we are going to take a look at how Mockito can specify return values in different scenarios for some functions that get called in different types of situations. With Mockito, you can add functionality to mark an object using different methods. You can see that we did that here in our desk at line 23. We marked the entire car service class that was on an interface and head no actual implementation. But other than that one Mockito kidney, it can also mark the behavior of a function that gets called with certain parameters. And in marking debt, it can specify the exact return value that that function should have when called with that specific parameter. For example, online 43. As you can see, the Mockito instructed the function of get price from the car service, which actually had no implementation in the interface. To return the 250 thousand fail you when getting cold, we could the argument of Lamborghini. And as you can see, the stacked syntax for that is the wing keyword. Then the function that is going to get called with a specific parameter. So debt is the situation where you want this behavior to be added. And then the den return keyword, and then the value, the function that is getting called with that specific parameter should have in debt exact situation. At this point of time. Mock already recorded the behavior and it is working mock object, car service type of interface. The car service object is already a working mock object. Again, I already said this, this code right here is very useful because this code will get executed in the dealership, get market value. We are going to test and we want those two calls to have our exact given values, marked values, just in order for us to make sure that this function is going well or not regarding these function of get price. So whether the function of get priced works or not, definite method twice, because we specify the values it should return. And we want to concentrate on unit testing to get market value method. This is the basic method of when and then return, which is SHE said, the Mockito framework specifying the return values. As some other programmers might think of. This is adding the behavior. In certain types of situations. That's a pretty useful thing when you want to create that separation that we talked about from the class that you want to test in the under dependency and classes that are called within it. So this was above deed for this lecture. And in the next one we are going to start looking at the verified keyword, which is a very important keyword, demo dope, unit testing framework. And we are going to see exactly what it does and all the various scenarios which are a lot of them that verify keyword can be used. That sounds interesting. I look forward to see you guys there and thank you very much for sticking with me up to the end of this lecture. 8. Verify method behavior: Hello guys and welcome back to the smoky told Turiel. Wherever we understand how we can better unit test our methods written in Java using this framework. In this lecture, we are going to talk about to the verify method that Mockito provides us with. Also how we can use it and why useful for us when trying to unit this one or even more methods that we wrote in the R. Maybe in production or maybe we want to deploy them at sometime in the future. So getting started here, I created a whole new project in Intel J. And the way I did that was pretty similar to the other one that we saw in the previous lecture where I introduced the overview of a project to you. More specifically, I just clicked on File New Project. And then when that opened up, I chose the Gradle dependency solving system, chose Java, and then the JDK of my choice. Then on next I just chose a title for it, same for the artifact coordinates and then I click on Finish and then it created my project for me. After that, I just went to build gradle and I imported some stuff to some dependencies that we are going to need in order to make these project work. To be more specific than debt. Used JUnit and also the Mockito packages. The JUnit Jupiter API was already here after you will include these. As you remember, if you change any character of DC build gradle file, you'll get the self and with the synchronize button that you need to click on in order for it to import in synchronized with all the latest dependencies, right in the build Gradle file. After I did that, the source is filed with the mean and test folders were created after the project built. In the Java folder, I have a class and the interface. The class is called billing application, and the interface is called bond shop service. The pawn shop service has two methods you need to sell and buy. One, they are not implemented at all in the billing application. That's actually a clinic, not an interface. I have these private fields. That's a type font shop service, which was the interface. And then I have the set barn shop service, which sets my bond shop service field. Then I have cell function which just adds two numbers. The first one should be the total profit that the punch up has had up to this point. And the second one should actually be the price we sell our specific object for. Again, these are pretty much just for an example in they are not implemented to a degree in which they would be intuitive or nothing by by method as well. That calls the bike from the punch up service, which as you saw, it's not implemented, but we are going to see how that works in just a second. Now where it gets interesting, because up to this point it was pretty similar to the other project that we looked at. Ease at the test folder, where we have automatically the java folder created and I create these two functions here. These are both classes. One is called the billing application testers. So each testing application for displays that you see on the screen right here didn't billing application one. And then I have a test runner which has the main function you need, as we will see in a second, is responsible for actually running all the different desk class is that we would have in this folder, in my constraints, just one. But in bigger production project, there can be a lot of testing glasses. I know is pretty useful for running dam as opposed to having domain in each one of them because that would be much more time-consuming to click a lot from buttons on each of the projects. Furthermore, to billing application test right here. As you can see, it's pretty different from the one that we saw in the last project. And the main difference is that this tester class is read with JUnit trainer. And as you saw if you remember, we import interchange unit in my case is 4131, the version. And explaining a bit what these dots, a JUnit runner is just a class that extends the runner class from JUnit, which is abstract. These boundaries are used for running the test classes. They have some patience with the at sign that helps the building process understand which object is the mark, which object is the object that should inject the mock him too, and also the test functions. The JUnit tests are started using the JUnit core class. And this can be done from running you from the command line. But in our case, this going to be done by default, by our IVE when we are going to press the Run button on the disk drive that has the main method. We will see that in a second. These JUnit runner uses reflection to find the appropriate trainer for the best test glasses. And of course, he's going to first look for the annotation of rhyme width on the test class, and no other runner is found. The default runner will be used. It will be instantiated and the test class will be passed to the runner. In our case, debts, the application tester class. The job of the runner is to instantiate and best test glass. So that's the run or does it pretty straightforward? It just helps us run our test in Intel J by using intuitive and conditions in order to show to the ID which component is switch n. What is the role of each actor in this process? Now, moving on to the test runner and we will get back into this best-in-class in just a bit. In the test runner class, you can see that we have the main function and we have a result which is assigned to the JUnit run classes method. And that is given as the parameter d testing class. As I said, the chain unit or is going to run the class of testing. And of course, these annotations is going to help him do that. The result is assigned to the JMU trunk classes. The two-minute core ranks that glass using reflection and then puts the result into this result variable right here. Now we're going to iterate through these results failures. So these results object has a maximum method called get failures and it will return all the failures if there were any on our test. And it is going to print them on the screen. Of course, it is going to also print if our result was successful or not in DC is going to either print true if all the tests were succeeding or false if some of them were failing, as you can see on the description on the screen, right now, this was pretty much the structure of our project. We see on the screen. I just wanted to show you all the elements that I did in detail. Just so if you want to follow along with this project or maybe even write it and then modify that you're online. You are going to be able to do that. After this presentation. I am going to get more in-depth into the concept that we are actually going to talk about in this lecture. And verify method, the public class of billing application tests that I wrote on the screen here, does a few things that are very knowledgeable within the Mockito framework in their dump, very good with this framework and that's why I wanted to present them to you. First of all, it declares an object of billing application. The annotation of Inject marks test that this is the object where the mark should be injected in. And as you can see here, the pawn shop service is the mark because it's just an interface and we should inject it into this glass. Now we also declare within these tested upon shop service object, which we annotate. That is actually a Mock as you saw, iterating, That's an interface and we should market and market behavior to return exactly what we want to return and that actually have it implemented. Remember, we are doing these in order to avoid overhead in testing our production classes. Either by not wanting to recreate all the database flows in just some mock given by us values and also to control better the flow of parts often function that are not actually related to it. And we just wanted to test that function separately from any other classes. And now the test at function, which is the actual single test that we wrote in this application. As you can see, this is annotated with the test sign. We're going to, first of all, at the behavior using Mockito, that when the pawn shop service sell method is going to be called with the parameters of 1020, damage should return 30. We are adding this behavior is otherwise this line of code right here would not have existed. The pawn shop service with the cell method with return nothing as that method is not component, we added the behavior. And then we are going to test these add functionality and assert whether the pawn shop service sell method with the arguments of 1020 will actually return 30 S we instructed to do. And we're going to do this as you can see with the assert method, which is belonging to the JUnit class, JUnit reference is very important here. And then these place has an assert equals method, as you can see, that takes two objects and then starts whether they are equal or not. That's pretty straightforward. Now, we can verify the behavior using these verify keyword and also method. Verify behavior says that we should verify the pawn shop service sell method with the arguments then in 20. What this means is basically verify whether the bond shop service class method of cell with the argument 1020 was actually called. We can also do another thing using verify. And that is also suggesting the times of these function being called. Now, going a bit more in-depth in the theoretical verify method knowledge. Mockito can keep track of all of the method calls that you do in testing methods and also their parameters to debt mock object. You can do this by using these verify method that I am talking about right here on the mock object. As I said, you need to use this in order to verify that the specified conditions are met. For example, you can theoretically verify that the method has been called it certain parameters is we are doing here on line 30 to this kind of testing is sometimes called behavioral testing. That's pretty suggestive. And it does not check the result of a method call buddy checks that the method is called with the right parameters. As you can see in this verify statements online 3333, the actual result, which is 30 and it should be 30 on debt method that is marked nowhere to be found, So that is not implicated at all. The result of that method call, we just checked whether depth method was called or not with red parameters and also the number of times what it was called. Of course, it can do a lot of other stuff that we're going to do, check into later lectures. But in this lecture we are going to only concentrate on these two factors. Going through it again, the monkey toy refined methods are just used to check the certain behavior happened. We can use this verify methods at the end of the testing methods and that's the way it should be used as you can see on my screen as well. To make sure that the specified methods that we upwards of them called are actually called. This way, have another way of verifying that the actual workflow that we suggested, this test method actually took place and E's working as we thought it would be. We can go ahead and run this and see what happens with these test functions. When right-clicking on the test runner and run it, it is going to go to the main function. Then using the JUnit core, it is going to run all the classes in this testing class. Then it is going to iterate through each of the failures if there are any, print them and if not, or even if they were less, VT is going to print on the screen whether the result was successful or not. Successful, meaning that there was any errors or not. It is pretty intuitive when the JUnit core run classes method gets called width the billing application test. Our test method is going to be called. First, we add the behavior of the pawn shop service sell method that gets called with the first document is Dan and the second argument as 20, it should return 30. Now we are going to assert whether the behavior is actually done by asserting whether the cell method of this interface and the actual and the 30 value are equal. Then we are just going to verify whether this cell method, well, it's actually called online 29. And also we're going to check whether the cell method, the arguments of tenant 20, what's called onetime online 20 as well. When we run these, as you can see here, it says that the task of test runner Maine was. Invoked, which was this task right here. Anti-trust voltage to true. White resulted to true. Well, that's because it iterated through all of this getfield years and literally turned nine because our test method didn't have any failures. And then it prints that the results were successful. These what B's true stands for. Everything happened as we plant here, our cell method was called. It was called, as a matter of fact, one time. Now let us check what happens. If we want to verify if the cell method with the arguments scan in 30 was called. If we run it each shoot, let us know that it was not called with the values 1030, but the actual values 1020. And as you can see here on the task test render main, it says that the arguments are different. We wanted the arguments to be 1030, but the actual invocation that happened at line 29, as stated here as well, where 1020. So it specifies us the failure in detail as we instructed to do in the test Turner online then then also prints to us that the result was not successful, so it was false. Now let's continue checking this 1020 so it should return it. Alright, but now let's verify whether the method cell with the parameter standard 20 of the mock object of type punch up service was actually called two times. So again, it should warn us and it should return false when we run it. As you can see here, again, it returns false. And specifically US debt, the test method failed. And the pawn shop service cell function with these parameters was wanting to be called two times. So that's what we want it to happen. That's what we specified it would happen. But actually the number of invocations, that was one time. This pretty straightforward because it was called Only one time here on line 26 is not called. It's just specify that when Scott you should return 30. So this is not actually a call to it executes C. Verify method is extremely useful in order for us to verify that the flow is specified in our test was actually executed. Not only that the methods that we want you to call were actually called, but also the times they were called. The fact that it specified that this depth, the things that went wrong, is again very useful because you can see at a deeper level what went wrong exactly. And you can then debug much easily, you are test and see what happens wrong. Maybe either in your desk by specifying the wrong thing or in your actual method. The method has a lot of other actual complimentary functions like these times function right here. And we're going to run through them in detail in the future lectures. But for this one I just wanted to do quickly show you our Set Up Project and also these features of the verify. Again, iterating through them that the function was called with certain parameters and the times that equals called for other functions that were complimentary with the verify method in Mockito sounds interesting to you. I suggest you to stick around in the future lectures. And again, I'm very grateful that you stick up with me up to the end of this one. I look forward to see you guys as well in the next one. 9. Verify the range of method calls: Hello guys and welcome back to this Mockito testing framework tutorial, where we better understand how we can use this particular framework in order to better test our methods written in the programming language of Java. In this lecture, we are going to continue understanding the method verify of the framework Mockito, more in depth. And you are going to do this through some other experimental methods that can work with these verify method and also some other related methods to verify method. The project that we are looking at, what's presented in the last lecture. It was that of the building application with the pawn shop surface, the punch up service again with the interface and the building application. Whereas a concrete class that was using the pawn shop service in the byte method. The building application. This is the class where we have our actual unit tests written, we Mockito. And this one is just an actual class that will run all the testing that we have. Some snarky is just the billing application after class. And last time we looked at the verify method in order to verify that the function was called. And also, we looked at the Times complimentary method that was working with verifying order to check an exact number of times that method was called. But more so than these times function, there are other complimentary functions that works with this verify method of Mockito and are again very useful when we want to unit test our methods. It is useful again for checking com many times natural method of glass that we are testing was executed. First of all, you need to remember the general syntax of these verifying method, which is the keyword verify. And then it can take as parameters, first of all, the object of the class that you want to test in our class, it is the marketplace of pawn shops surface. Then it can optionally take a second parameter that is a function. We will see what that function does in a minute. But after these actual verification, verify method dates the argument only the object of Democritus we want to test. And then the syntax specifies the method of that class with actual parameters. It verifies not just the method from the graph that we specify as the first parameter, but also its parameters. Now getting back to the second argument is optional, but again be given into the verified method. It specifies the tanks that this function had actual costs may do it. He can either be times. And we talked about this last time, as I've said, which specifies how many times that actual method with those actual arguments was called. But it can also be at least at most and network at least specifies whether the object of class as the first parameter given to the verify method and its method with those arguments was called in this test at least. And then each takes an integral as to the number of dimes is called or utmost cell. You can put a limit here, but not just that, we can also have the network function, which again is very useful because it's basically the opposite of the verify simple function which verifies whether debt function has been called. The second complimentary function here, which is never makes sure that the method of that object in which those specific parameters was never called. Furthermore, than these complimentary functions that we can give as verified parameters along the Arctic Dr. marked glass. We also have the method verify no more interactions. That takes the mock object as a parameter. What this does, it verifies that all the interactions were verified. It takes out the actual cause of methods with these classes objects. And it verifies whether all of those costs verified. And if there are any unverified interactions on these marked object, it will return false at it. We'll specify that as you can see at this point, there are no unverified interactions. As the cell method is the only one that is being called and it actually gets called online. 29 is I've set up to line 39. There is no unverified method of the object punch up service. If we run the test in this point, you can see that it will return true and as everything is verified. But then on line 40, I called the cell method again on the object bunch of service. And this time I am going to write again the verify no more interactions. What this function does, it verifies up to the point where it's written. So only before it, whether there are any unverified interactions of methods of the object that it receives as parameter 41. Now, I again specify this function only that online 40, I called the method of the punch of service. As you can see, with the arguments of 1020 DC's less important. But the important thing is that after I call it, I did not verify it whatsoever. So if we run this right now, when it gets to the very fine normally directions here, it will sense that it is false. And as you can see, it specifically says in very much detail that knowing directions where one bead, line 41, as we specifically said with this function. But we found the interaction of the mock pawn shop service at 940. And it also additional would keep you for your own reference list of all the locations that were made to these mocked object online 40 was unverified. Online, 29 Wednesday fight. And it tells you that this sign right here means that the actual implication was not fighting. As you can see the information online 40, which is this one where it's not verified. And online 29, which is this one, was verified. So there's no question mark there. Then if furthermore returns false, as you remember, that was the result of line 13 of whether the result of the chimney Quran class of the glass building application tester was successful or not. And in our case, it was not successful. So this was about it for this tutorial where we looked again at some other complimentary methods on the verify multi-dose method. And also we look at the very final more interaction in order to understand how it works. In the next tutorial, we are going to take a look at the order of the costs that are made and how we can verify those as well. Again, using the verify keyword. If that sounds interesting to you, I look forward to see you guys there. Once again. Thank you for sticking with me. After the end of this lecture. 10. The InOrder class: Hey guys, and welcome back to these Mockito, Java unit testing framework tutorial, where we better understand how we can unit test our methods written in the programming language of Java. In this lecture, we are going to continue talking about the verify method, the Mockito framework. And more specifically than that, we are going to verify in this lecture, the altar of invocation regarding the methods of among objects. In our testing class. We can use it in order class, as you can see right here, to verify the order of the invocations of different methods on our mock object. We can actually skip some methods that we wanted to verify. But the methods that we want to verify must be invoked in the order so you can skip this chain, of course, at any point you want, but the chain detuned verifying needs to be in the actual order that you give it into the in-order object that you create. You cannot skip costs in-between the cost that you are trying to do. With the in-order object. Looking at the code on the screen, you can see on line 40, as I said, I declared an in-order object of type in order, which is an interface that is available in the Mockito framework. And that will actually take an in-order type of object, mock, the only parameter. And then using the in-order objects that we create it, we can call on it the verified method that again is taking, as we know, as the first parameter, the mocked object that we have in the test class. And it can optionally take another parameter that specifies the number of times call has been made. And that's the disparate Phi. We have the syntax that we know by now, dot the function that we wanted to test of getting the code from the mocked object and then its parameters. Solid line 41. I am very fine with the in-order object, whether the punch up Service cell with the argument 20 was invoked and try it after. I verify whether the cell method of the object bunch of service with the arguments then in 30 was called two times. And then after this, I am testing whether the bind method with the arguments of 1035 of the object bunch of service was called. We are again verifying the order of the invocations of discourse on the market. Object with these in order to class and furthermore, verify method. As you can see, I changed a bit the code before this method call. And online 30 we have the pawn shop service cell with the argument 20 cell. This is the start of the verification on the chaining invocations. Then we have online 35362 cos of the cell method with the arguments is done in 30. And you can see that that's what we are testing on line 42. And then lastly online for D3, we are testing whether the bind method we document standard 35 was called next, which taxi was H can see online 35. Right now, if we run this class, you can see that it is going to return true. But what happens, for example, if instead of calling the method with the arguments, then in 35 I would call it documents standard 45. With these still work well theoretically now you can see on the screen it doesn't work. And eat again specifies in detail, which is very useful feature that the verification of inorder, it was failure and 35 method was wanted but not invoked. It was wanted anywhere after the following interaction, which is the 1030. But these actual invocation was never called. Ec2 is expecting the 1035, it actually got 45. And the method of the object function of service with the argument standard five was never actually called in the sequence. This false error was given here. This was about it with the in-order function available in the multiple framework can be very useful if you want to verify a sequence of calls that you make in your testing class. I hope you got something out of this tutorial. Thank you very much guys for sticking with me up to the end of this tutorial. And I will see you in the next one. 11. Argument Matchers: Hello guys and welcome back to the small ketones tutorial. In this lecture right here, we are going to discuss Mockito, argument matchers and more specifically be Amy argument matcher in demo Quito framework. These are very important components into the Mockito framework and we will see why in just a moment. Now getting a bit into the things that we already discussed about, Mockito allowed us to create the mock objects and also add behavior for them. The way that the behavior was added was by the keywords when and then return keyword, the mock object. And remember we had the when keyword and then parameter took the function of debt mock object and also its parameters. And then the return keyword followed by the document. What that method of the Marked Objects with those specific parameters should read there. That was the way Denmark. Let us add specific behavior, marked behavior, of course, to our month objects just in order for us to make them return exactly what we want. Now, of course, up to this point where you see any double here, we had actual values like you see these dirty right here. That was a pretty generic way to mock the behavior of a mock object. But Mockito late weak argument matchers do a pretty, a straightforward, much broader way to basically let you mark that behavior. Let's suppose that we wanted to mark the behavior for any argument of the given type. In that case, we can use this argument matrix that I'm talking about. They are defined into the Mockito, argument matrix class and they are static methods. As you see, we just, we can call them right here. We talked any object that are related to them. We can call them by their own. As you can see, instead of actually writing specific values here, we can write this any double function. And what this will do, it will return 34, actually, any double values that are received as parameters on the same method of the Marked Objects, LB service of the service class. And as you can see, I made a bunch of asserts here that have a bunch of different arguments that are pretty different from each other. And up for each of them, I specified that it should return 30. This is just a way for us to test that these adult behavior here with the argument matters in Mockito is actually working. If we right-click on it and click Run, you are going to see that for each of these cell methods with all these different arguments out, these methods actually return 30, can see it returns true. If you remember that was the result of the successful method, the wrong class method on the JUnit. For the argument of our testing class. It actually works. So this argument matrix are very useful again, if you want to do mock general behavior and you don't even care about the arguments that the function receives. For any argument that it may receive, you just want to return the same result. Maybe because you want to test method and there is another method within that method and you went to market. So you just want to eat that function and no other functions. And if there are any other function, you went to mock them to return aesthetic value, which in this case would be, as I've said, 30. And in this scenario, debts are pretty valuable thing that Mockito lets you do, besides the N double method. Of course we have any eat any Boolean and so on. For each datatype that you can think of, any methods, you can replace any datatype that might be given as an argument for the Where method. But thank you guys very much for sticking up with me to the end of this lecture. And in the next one, we are going to discuss spies. Within the Mockito framework, we're going to take a look at what exactly they are and how they can be useful to ask when unit testing our methods. So that sounds interesting to you. I look forward to see you guys. There. 12. Spies: Hello guys and welcome back to these Mockito tutorial, where we better understand how we can unit test our methods written in the Java programming language. In this lecture, we are going to discuss about Spice, Mockito framework. And also understand what exactly they are and how they can be useful on a journey. To write these unit tests, we can use a Mockito spy to partially mock an object. Partially mocking an object is mocking debt object. But when we create that spy actually off an object, those real methods of the objects are called, even though it is mock object. Now, I have on the screen an implementation that will be a great example for this definition and will help you understand exactly what Spice are. You are familiar with this project in Intel J, we hadn't building the application here. And also mock object. The mock object was injected into the building the application, which was actually a concrete method. Now on our testing method, first of all, I added the behavior that the pawn shop service, which was the marked object in the event that the cell method of it was called with any two doubles whatsoever, It's arguments then H2, H3, pen dirty. Now what they did, I declared an object of type of billing application, and I assign to it a spy on the billing application object. Then what I did, I called on this pie object the cell method, width, the arguments of 1020. Dead billing application class. The cell method. I had it implemented so it return and print it on the screen, the sum of the two numbers that are given as parameters. After that, I also created an object of type pawn shop service online 34, and they're assigned to eat the SPI of the pawn shop service object. That was actually the mocked object in this testing class. And what they did. Furthermore, I printed the cell method of this spy object with the 2323 arguments. If this was not a spy on the pawn shop service, it should return 30 because that's what we do. If the cell method of the pawn shop service object is called with two doubles, then it should by default, return 302223 are two doubles. And when we run this, you can see that first of all, this one returns 30. Because then and 20 is 30. And I specifically strictly to print on the screen the sum of the two parameters. Furthermore, it returns 0. And why is that returning 0? Because the punch up service object is actually of a mock glass, which was just an interface. And the cell method is not actually implemented, so it returns the default double, which is 0. If this was not a spy, and we actually had here instead of SPI to the pawn shop service. You can see that by default it will return 30. As you can see here, because that's what the behavior of this one then return statement don't need to do. So. That's the difference between a marked object with ADD behavior and a spy unmarked object. The spy on the mock object will actually call the real method of that object. We can also use instead of the Spy class to call real method, method on a marked object to call the real method. That is also a variant here, but it's not recommended and it is recommended to use a spy for this partial marks. And the main reason for that is because spy that chickens we have is actually instantiated. When we create a mock object, the monkey TO creates an instance of an object, which pretty much just the skeleton of it. So with the bare minimum, and there may be a chance that those required dependencies will not be initialized when the market is being created with the Mockito. And this can lead to bad results in the end. And that's why spice are actually preferred instead of the code below method, method that's also available in this context. So I hope you guys got something out of this tutorial and understood what spies are and how they can be useful to us. Thank you again for sticking with me up to the end of this lecture. And I look forward to see you guys in the next one.