 To apply mock objects, we're gonna use Moquito. Moquito is the most popular Java framework for mock objects and I really recommend you to go to the Moquito's website as the documentation is very complete and Moquito is a very powerful framework. So if you want to master it, you will have to read the documentation. So what we're gonna do in our test is to get rid of the real database and mock it. So let's just start by completely deleting the database access part from the test. Then, now that our test doesn't use the database class, we introduce Moquito. And the first thing we do is to tell Moquito which class it needs to mock and in this case it's the invoice database, the one we want to mock. So the mock method from Moquito receives the class we want to mock and you see the dot class because we are getting the definition of the class from the JVM. Moquito returns the same type of the class, in this case invoice data access object. And this is very useful for us because it means we don't have to change our code that much because the mocked class has the same interface as the real class. Of course for Moquito to do it, there's lots of magic going on behind the scenes. But for us consumers of the framework, we can just take advantage of it. The second part, as discussed in the previous video, is about setting the behavior we expect. And for this mock, what we wanted to do is to return a list of invoices when the method all is involved. And this list of invoices can now be just an in-memory list, way simpler than a database. So that's what we do here. We create an array using the arrays.slist method from Java and we add the tooling voices I1 and I2. And then we use moquito.when method and when the all method happens in the mock object then returns this list that we just created in memory. With these two lines of code from Moquito, we now have a class that simulates the database object. And this mock object is able to return this in-memory list when the all method is involved. That's nice. We're almost there, but now we need to do changes in the production code as well. And I'm going to discuss more about it in future videos, but changing the production code to ease the stability is something that we will do quite often in practice. So if we go to the production code, we need to get rid of the instantiation of the database object class. We cannot do this anymore because if we do this new there, this means we are always going to use the real database and that's not what we want. We want our code to use the mocks when the program is being tested and we want the program to use the real class, the real data access object when the program executes for real. A common way to do so is to receive the class we will mock as a parameter of the class. And we usually do it in the constructor. So as you can see in this code, the invoice filter class now has a constructor receiving the database object. And this is nice because due to the polymorphism of the Java language, we can pass any class that is or inherits from invoice data access object in this constructor. In other words, I can pass the real one, the one that I want to be executed in production, but I can also pass the mocked one just for the tests. So our production class is now more flexible. This pattern has a name and it is called the dependency injection principle, which we'll discuss more about it later. We are almost there. So if we go back to our tests, we just need to then pass the mock via the constructor. And in terms of implementation, that said, what happens is as soon as we execute a test, the filter method invokes the all method in the data access object, which is not a mock. And this means that this all will return the least we created in the tests with two invoices. And now we completely got rid of the database and we are able to test our invoice filter class without being bothered by the complexity of having a database in our tests. This is again a unit test. And because of the mock object simulating the database, we can now explore bad weather, corn cases, and write several test cases for this class in a much more easier way. This is what mock objects are about. They help us simulate the behavior of classes so that as testers, we can really focus our energy on the class we want to test and not on its dependencies.