Spring Boot + JUnit 5 + Mockito Tutorial

welcome to another playlist where we talk about how we can work and understand spring boot and junit in this playlist we'll talk about how we can use junit and write unit tests for our spring boot rest api application we will do this uh by learning how junit works uh what unit tests are why do we actually need to write unit is and what does testing even mean so we will start with the basics of what testing is in this video and slowly move ahead with basic uh unit tests and then we will actually build a rest api and then write unit tests for a rest api in this playlist you can expect learning about tdd which is trust driven development where we understand what that paradigm is why that is pretty famous in the current uh software engineering scenario and what do we actually mean when we say tdd or test driven development so let's uh before all of that let's just understand what our testing is and uh what do we actually you know mean by testing a software system so testing the system is an important phase in a software development life cycle the sdlc testing promotes um code reliability robustness and ensures high quality software delivered to clients if implemented correctly so testing has been given more importance since tdd has become prominent process in developing software now test driven development uh entails converting requirements into test cases and using these test cases to get keep code quality now code will be considered unacceptable if it fails any of the test cases declared in a system and the more test cases we cover uh the better the product becomes the code base is lengthened considerably but it reinforces the fact that the system meets the given requirements now rest apis are rigorously tested during integration testing however a good developer should test rest end points even before integration in the unit tests now we have these two terms called as you know um rest uh integration testing unit testing so let's understand what all of them mean so before that let's talk about the purpose of software tests so a software test is a piece of software which executes another piece of software asserting that it is behaving in a way that we want to with software tests we ensure that certain parts of our software work as expected these tests are typically executed via the build system and therefore help developers avoid breaking existing code during development activities running tests automatically helps to identify software regressions introduced by changes in the source code having a high test coverage of your code basically testing all possible edge cases in your code allows you to continue developing features without having to perform lots of manual tests now you should write software tests for the critical and complex parts of your application if you introduce new features a solid test suit also protects you against regression in existing code now some developers believe that every statement in your code should be tested but in general it is stay safe to ignore trivial code so if you have a simple if else statement or for loop statement which you uh are confident about what it does then you don't have to write a test or test whether it's working or not right because you already know how it works behind the scenes so for example it is typically useless to write tests for getter and setter methods which simply assign values to fields writing tests for these statements is time consuming and actually pointless as you would be as you will be testing the jvm now the jvm already has test cases for this so if you are developing something in java it is safe to assume that you know a field assignment and all that works properly so now let's talk about some testing terminology the code which is tested is typically called the code under test if you're testing an application then it is called application under test a test fixture is a fixed state of a set of objects which are used as a baseline for running tests another way to describe this is called as a test precondition now i'm not showing all of this uh in the video because i'll be putting the links in description and they have a much comprehensive way of understanding the definitions but before we actually you know jump ahead with the practical coding part we need to understand what these are and talk about them a little right so uh check out the description for the links where you can understand them in depth depth theoretical part and this video uh is here to make you understand how we implement everything so now let's talk about the different terminologies unit testing integration testing performance testing so now a unit test is a piece of code written by a developer that executes the specific functionality in the code to be tested and asserts a certain behavior or state the percentage of code which is tested by unit test is typically called test coverage again the percentage of code which is tested by unit tests is typically called code coverage a unit test targets a small unit of code or let's say a method or a class external dependency should be removed from unit test so if your particular function is dependent on some external class or you know it takes something from external libraries or modules then you can ignore them and only test what that particular function does now how do we do this we do this with the depend uh we do this we do the replacement of external dependencies with a test implementation or a mock object created by the test framework so junit provides another library's providers with a way to mock those external dependencies so now if you want to take uh test the complex user interfaces or how two different software components are interacting with each other for this you need to develop an integration test which checks the integration of these components now an integration test aims to test the behavior of a component or the integration between a set of components the term functional test is sometimes used as a synonym for integration tests so you know it's a functionality between two components now integration tests check that the whole system works as intended therefore they are reducing the need for intensive manual tests so uh if you want to test an api or check whether an api showing another api i can run both the apis in a testing environment and then manually uh not do a post request and check whether something happened or not or i could do an integration test automatically does this for me uh saving me time and you know it's easy it's more work for the system and less for the human now the last thing which we talk about is performance tests the performance tests are used to benchmark software components repeatedly the purpose is to ensure that the core under test runs fast enough even if it's under high load now in this playlist we will strictly be focusing on unit test which is something a developer needs to write to make sure that the code which they write is working properly before they send it to production and a unit test is something which i feel is very important for for a new software engineer who has just graduated from college or even for an intern who's working at a big corporation unit tests ensure that your code is correct and it is covering all possible test cases so this particular playlist will be about developing a rest application and writing unit tests for those apis which we develop so there are two ways of doing this one is to first implement our rest api and then write unit tests the second is the tdd approach where we first write our test and then we use those tests to build our application and in this playlist we will be seeing both of those approaches as we go now before we jump on to creating our project let's just talk about what is you know behavior versus state testing now a test is a behavioral test if it checks if certain methods were called with correct input parameters a behavior test does not validate the result of a method call it only checks if the input parameters were correct or not state testing is all about violating the result and behavior testing is about testing the behavior of application under test now if you're testing algorithms or system functionality in most cases you want to test the state and not the interactions a typical test setup uses mocks to abstract the interactions so that other classes you know are not dependent on this after that you test the state or the behavior as you need so this is some simple theoretical information that we need to know about why we do testing uh the reason for why we need to understand what our different terminologies etc etc now for this tutorial uh we are going to create a project a springboard maven project and then we are going to install some dependencies and make sure that our project is you know uh up and running for further you know implementations so let's go ahead and create a new project uh this is what you get when you create a new project go to next let's give it a name let's give it junit list api application and let's click finish now this will give us our application so let's wait for a minute for it to be comfortably loaded now now the best part about uh writing tests using intellij is that i'm using a main project is that we automatically have a testing folder where we gonna put in all of our tests so now that we have our repository ready let's go into src go to main here we have java and resources but if you see in rss you have test as well and inside test we just have a java folder so nothing in it right now but all of our tests will be inside the java folder and it will be inside the test folder which is uh which encapsulates the java folder so before we jump into all of that uh let's first enter all the dependencies that we need for this project so that you know we are good to go so the first thing that we need is our parent so the parent is going to be having a group id which is going to be our dot spring framework dot bring framework dot boot and we have the artifact id as well spring boots are apparent and the version is going to be 2.2 here 2.2.2 release so this will basically uh have all the uh typical things that we need for our spinosaurus api and get started the next thing that we need are dependencies so we need a bunch of dependencies and we will talk about uh what all of them are so dependencies and now let's add in our dependencies before that let's just add in our build plugin so that you know we want maven to get we want maven to fetch all of our dependencies so let's quickly add that here so this basically uh tells me when to get our dependencies from the maven repository and you know put them inside our um local dependencies name table enable this folder okay now what do we need so first we need some starter repositories so let's quickly get them inside here so we need spring boot starter web because it is going to be a rest application the next thing is spring boot starter test uh it has simple things that we need for our testing environment next we need uh loom work so this is basically a very handy dependency which will help us with a lot of annotations and help us with everything which we need for that and we need a couple of more so let's quickly add them and then talk about them so first is apache derby so we since uh the main intention of this playlist is going to be testing our code we want to minimize our dependency on external databases so apache adobe is an in-memory database which uh will be up and running just as we you know uh give this dependency and that's all we need to run an in-memory database i'll just add some uh add this dependency and we are good to go and the next thing which we need is spring good starter data gpa uh to have our tables uh ready and mokito uh is something which i want to save up for the upcoming videos because it is uh this will require a video of its own so now that we have all of our dependencies and everything ready uh let's quickly uh have our uh api runner so let's go inside src main java uh let's have a package so let's say com dot rest dot application and inside this we can do our test api runner and this will be a pretty straightforward and boilerplate code so before we do that let's quickly refresh our maven dependencies and you know add all the dependencies to our project should take a minute or so and i think we're good to go now we need to do another springboard application and we need to have a main method so public statistics and here we need to run or start our string application dot run and the class which we are running is rest api runner dot class and we pass in the args we get from the method okay so now we have our simple project ready and let's run it to make sure that it's running properly takes about some seconds to build up all the clusters and everything else [Music] yup should be up hopefully no errors because we have been doing this for quite a long time and yep everything looks good if you see the data source you'll see hikari and everything else because we're using apache derby so we already have our gpa and everything else installed and we literally have a database up and running with our topcat server so yeah we have um everything up and running to start implementing our unit tests in this video we are going to jump inside junit and see how jnet works so junit is a popular unit testing framework in the java ecosystem and we will be using j5 and let's see how all of this you know works so first as i said we need to have some conventions so we need to understand some conventions when we are adding tests uh we need to write a test inside the test folder inside java and here you need to have a java class which will basically have a name now when you are writing a test class the class name must end with test so that we know that is a test class so here let's just say j unit example test and now we have a class ready to be tested now let's basically first see how you know everything works here so all we have to do is do as a rate test and let's just say void demo test method and here what we can do is assert true and just do true and let's import assert2 now so more actions import static method from junit okay so now we have a simple test which basically is you know which passes no matter what happens now let us run this test and see you know how it looks like so when you run this class we want to see what happens right we want to see what are we actually doing behind the scenes or what is happening uh and how do we actually check whether test pass or test failed this one has to pass by default because you know we are asserting true and it is true so our test failed now we need to see why it failed so it should be public so we'll do a public void test method and let's run it again so now when you slowly see you'll slowly understand how it is working you know so we wrote a test the test failed and we exactly knew what was wrong with the test you know there was no public and the test has to be public no that way we can you know use our test to understand what is wrong with our code so now as you can see uh we have a part uh no we pass a test and when we pass a test we get nothing in the console that tells us that you know everything was running smoothly and you know we don't have to worry about anything that is happening okay great now let's actually write some good tests you know not something like this let's go inside our application create a new class uh let's say calculator simple simple examples uh because we're just learning how unit testing works so a very simple example a calculator this will have a method so public and multiply and we are multiplying two numbers and now we just return a b now we uh this is a very simple example and you might think you know that this is not uh worthy enough for a test because no what are we doing we're just multiplying two numbers but let's just start with simple examples to understand how the framework is and you know what the framework does and then we will add some real-life examples with the rest api application so bear with me for these tests uh they look very simple i understand but we will slowly you know go inside the good ones the good tests okay so when you have a class you know we need to write tests for that class so let's go inside java and do another one so we do calculator test and this class will have all of our tests for the calculator class now we need to test the calculator class so we need that inside our calculator calculator now we need we haven't initialized this yet right so we need to initialize this before we you know we go inside our tests right so here as you can see this is a test every our test will be method so before we go inside this method we want our calculator class to be initialized so jail provides you with annotation called as before each so before each test that we write do this and this is going to be a wide a setup method so let's set up our testing environment and all we do is we do calculator equal to new calculator and that's it we have our calculator class initialized for our testing environment now we can start with our tests so first we need to do a simple test right a simple test that we know so let's just write test um let's import the class from junit and this will be wide test multiply a simple test nothing complicated here or pretty straightforward and all we do is assert equals and our output will be 20 and when we do a calculator dot multiply when you multiply 4 and 5 we get the output as 20. let's again import the static methods okay so as you can see uh we are doing a calculator multiply from four and five and we expect 20 to be the answer and we do one equals test here pretty simple straightforward uh let's make this public um because we don't want the same errors again public yep so pretty simple test uh let's see uh what happens here and we'll do a run for our test you can also run an individual test but we'll just run the entire class because why not so the test failed because we got a null pointer exception and now let's see why that is so [Music] let's go ahead and see what was wrong again so at line 18 so calculator was null and we're going to see why that was so let's skip this for now and we'll do calculator equal to new calculator here and then we can test it again and the test is passed so before each had some problems there but we can you know worry about that later when we done but we just want to show you how how testing something looks like and here we saw that clearly with our diagonal multiplied test now let's do this again uh now we'll do the same thing but we want to test a different number so if we do our test multiply um different parameters and let's say we want 5 to 5 which is going to be 25 or uh so yeah let's test this now let's write two tests and see what happens and both it is pass pretty straightforward nothing nothing magical happening here and what you should notice here is that every nothing is changing here only the values are changing right so we don't need a different test scenario or test case for this this can basically be inside the same test so we have an asset equal and we do another equal and here we do five comma five and expected is going to be 25 great let's run the test again so let's remove breakpoints for now and just run the test yeah now you see what happens now that we have done this let's actually see what happens when we fail a test so now let's just say we expect this to be 10 because we don't know what 4 into 5 is and let's say we just printer we just put this by mistake or you know some some other developer by mistake had changed the value here and he didn't know anything about it but now if he does that it messes up the test and how does he know that so when the continuous integration deployment pipeline runs our test the build system it will fail this particular test and we will see how that is so this is how it looks like the test failed the expected was 10 and what it found was 20 by the value so it failed and that is how we know that you know it is a passing or they are failing now all we have to do here is change it to 20 and we will be back with our tests and yeah we are back to it now we haven't tested our code out properly right we have done an a into b but uh what if we do an a divided by b so if we call we have another uh method here so let's just say wide and we do a by b now how does that work you know how does that happen and let's see how this works as well so now let's write another test so we can call this test divide spell it correctly does the same thing and all we do is divide and let's say divide four by two and the expected is two let's run the test now and the test passed now this would make you seem that our calculator is pretty well functioning it's doing what it was to do is dividing and multiplying but what happens when you divide by zero because that is an edge case that we need to understand and we need to you know handle so let us see what happens here so somebody application is using a calculator and it divides by zero or we need to tell him something we need to give him you know uh something so here we say uh test failed and alteration divided by zero now we can write test cases where we handle this but we will look into that in the upcoming videos with rs applications so this is uh this video was basically an introduction of how the junit framework is and some big examples where we understand how junit works in this video we will actually build our sdpi so that you know we can once it's ready we can start writing the unit test for it so just a quick recap of what we had done in the previous videos so we had talked about uh very simple examples of junit how junit works we also had this calculator class which we talked about where we had simple methods multiply divide we had also made a simple calculated test class and we talked about the norm the guidelines for writing good tests so it should end with a test name and how we can actually assert that the output which we are expecting from that method is what we actually get so this is how we talked about junit how it works we talked about asset equals what we also talked about what happens when a test is not passed so here you cannot divide by zero so it throws an exception but when you run this and if you had not tested your code you would not know that four divided by zero could give you an exception so you write the test to check what happens when you divide four by zero and we run the application or run the tests and then we find out that the test has failed and we also get the reason why it has failed so in these ways tests are very handy for your application to make sure that you don't leave out any test cases or edge cases for application where it can break or cause some complications in your code okay now let's go ahead and create our domain and persistence layers for our rest api application and then we can start writing unit tests for them so in this video let's start now we can remove calculator for now or let's just yeah let's just remove it because it was an example we can also remove the calculated test class because we don't need it now we understand how junit works normally the next thing that we are going to add is uh a domain layer so basically an entity which we will be using throughout our videos uh and which we'll be using for our rest api application so somewhere where we can store our data in a class right so let's uh make a library you know a library or a book management system so we'll have a book class and here we will be adding everything so uh now we need to add some entities for our book record so we will be using some annotations such as entity the table annotation to make sure that the class is pointing to the right table aside from these translations we will be including lombok utility annotation so data all args constructor and builder so we don't have we won't be needing to declare any getters and setter and constructors as lombok already does that for you the string and integer field are annotated with non-null to prevent them from having a null or an empty value for validation purposes so let's quickly implement this and see how this looks like so what we do is first have annotations here so we have entity next we have table and let's give the table a name so name record the next thing that we need is data next is you know our constructor and all r is constructed and the last thing that we need is builder okay so now we have our annotation study let's start with what the book will have so each book will have a unique id so we have the id next thing that it will have is generated value and just try the g is going to be generation type auto uh the next thing that it will have is a flyweight long book id the next thing that we the book will have is a name so null and private string name name of the book the next thing which we want is private string a summary of what the book is about and lastly we need private end training so this will be out of five the rating will be out of five and we just have a few other things not down which is the book id name summary and reading this will be our uh record or a domain layer which we can use to actually run our application and handle the book create update delete apis for the book record now we don't need to actually connect it to external database because we are using apache derby which is an in-memory database which is handled at runtime so once we run our application we don't have to worry about initializing anything we can directly just start our cloud applications and adobe will handle the database things for us so now that we have our um book record ready the next thing that we need to do is have a book repository so let's quickly see how we can work with that so the next step is to create a jpa repository to provide methods to easily retrieve and manipulate book records in the database without the hassle of manual implementation right we don't want to we are only looking to have some simple crud methods on top of our book and we will be focusing more on the unit test part for us so for that let's create a new class not a class but an interface it's a new class and we'll just call it book and this need not be a class this can be an interface and all it does is it extends jpa repository and it has the book and the id which is lock and now with this we have our book repository ready and we can actually do create update delete with our repository and it will help us uh understand how all this works so now that we have our book and our repository ready let's just see uh what we can how we can work with it so the next thing the last thing that we need is our book controller class so go inside this go to new book controller and this will handle all the apis for our class and let's just quickly annotate this with our endpoints so this controller the next thing that we need is request mapping and value is equal to slash book so all of it all of the end points start with slash book and then we have our way in with it so now we need to uh inject the book repository b inside our controller so that we can do create update delete with with it we are not making a book service uh we're just going with the book repository to handle our card applications because we want to focus more on the united card states so do an auto wired and this will be book repository book repository and now with the help of this we can actually start using our book repository and our book controller and start making uh all the changes that we need to so uh for this video this is all i have a very quick uh implementation of the domain and persistence layers for our rest api application we had created the book.java which basically had all the fields and attributes for our book which will include the book id name summary and reading we also created a book repository which extends the gpa repository and gives us out of the box methods to use on top of our book data and we will be using the book repository inside our book controller class using the auto wiring injection method and then we can start creating our get put post delete mappings and our end points which can later help us writing editors so here we will be only implementing a put post and get for our methods we will write tests for those methods and then at a later stage we will be using tdd test driven development to actually implement the delete method so before we actually write the logic for our delete method we will be writing tests for our delete method and then as we try to pass each test our we will see how we are developing that particular method using tdd and we'll see how i will compare how both the methods are and which one is suitable for you or which one your organization uses and based on that you can worry about what to handle what not to handle so that's it for this video we talked about the domain and persistence layers in the next video we will finish up our book api and we will implement our endpoints and then we can quickly jump ahead with the junit unit test for our rest ap application to make sure that these applications these methods are actually running properly and they are passing all the tests that it needs to pass for this tutorial you will be having some homework as well so once we have implemented the simple unit test you will be getting some homework so stay tuned for that as well in this video we will implement uh the business layer of our rest api so that we can then start with the testing process and understand how we can test our sdpi application and let's just go over a quick summary of what we have learned in the previous videos so in the first video we had talked about um what we will be building which is a unit testing our sdap application we talked about the importance of software testing in the software development life cycle we have also talked about what g unit is in the second video and also us we saw some simple examples of junit one is here where we see how we can prepare a test class use the test annotations and then basically write our tests for our application and the third video we implemented the domain and persistence layers for our application where we had implemented a book record and also had a book repository which extended the gpa repository class now in this video let's start implementing our endpoints and see how that works out so first we need to do a simple get mapping so let's start with the get mapping and we just get all the books so we'll do a public list of book and this will be get all book records let's make sure r is capital let's import the class and this will be return book repository dot find out pretty straight forward as you as you can see uh the main reason why we're using the jp repository is because we get out of the box functions which can automatically help us with our rest api database uh implementations so this is to get all book records the next is get booked by id so we'll do a get mapping again but this time the value which we need is going to be the book id and once we have the book id we can return it back to the public or the client so we are going to return a single book so get book by id we will be having a path variable and this path variable is going to be having a value called as book id which is going to be a long book id and now let's quickly implement our book repository method so we return book repository dot find by id and we just pass in the book id into it so as you can see pretty straightforward or let me simplify this a little bit so that you know it's easier to read uh pretty straightforward uh nothing to worry about here uh return optional so this is going to be an optional book id so let's take care of that shouldn't be a big issue or all you can do is just do a get so that get that should be helpful okay so now we need uh it to be an optional but we can uh work about this later in fact we will be finding out uh all of this issues in our unit test once this breaks so wait for that let's finish implementing our cred api the next thing that we need is going to be the post mapping so at the rate post mapping and we are going to create a book record so we'll do public book create book record and now this is going to be coming in from the request body and we have to make sure that it is a valid book record and this is going to be a book dot save and what we are saving is a book record now this will create and add the book as a value inside our tables and we will be having that book stored we did not have to implement or write any native uh sql queries for this uh the apache or b in memory database takes care of all of this with the gpa repository interface that we extended and we can only focus on our business layer and the business logic which is to create update and find our books now the last but not least inside our application is going to be updating the book record so this is going to be uh you know a lengthier code so let's start with it so let's do a put mapping public book update book record this will also have a request body so request body this will also need to be valid it will be a book called as a book called now let's actually make this uh a bit better than our create book record uh implementation so first we do a check to see if the book exists or not before we get it so what we do is if book record is equal to null or book record dot get book id is equal to null then we can't really get the book back so what we can do we can throw a new not found exception and just say book record or id must not be null and that's it for now let's see we add the exception no problem uh next we then do a get so we do an optional book i'm sorry about the dog we get an optional book which is equal to book repository dot find by id and we do a book record dot get book id now we have an optional book now let's check if the book is actually present or not so let's do a check if optional book dot is present then we're going to go but we want to do a check so we'll do if not present then what do we do so we throw new not found exception which will basically save that book with id um book record dot get book id does not exist sorry and now uh once we have come till here we definitely know that the book does exist so all you have to do is go book existing book record is going to be optional book dot get and now we know for sure that the book exists and all we have to do is update its attributes so we do set the book id cannot change so set name and we do book record dot get name uh next thing that we will be doing is set summary to a book regard or get summary and last but not least is going to be ratings existing book regard set reading book record okay and this way we have our book record uh done all we have to do is save it again so we do a return book repository dot save and we do existing book record now we have updated the book record we have everything here so we have checked whether the book exists or not we did a check to the database and make sure that the book is valid once we have the book we had updated it and everything was looking good so now we have a good api ready a well written api ready where it has all the basic requirements that we need for writing our unit tests which will start in the next video so here as you can see we have our book record we have our book repository and the controller includes the book repository get all book records get booked by id create and update delete we will be writing so let's just do what to do write delete end point using tdd method so this will uh help us and remind us that we need to write another method called as lead and we'll be do doing that using the tdd method and see how that works let's quickly uh build our application and make sure that everything is working properly without any errors so that we can then start with our unit test and the best part about this is that writing unit is bad i don't need to check my check whether my application is working or not with postman or any other api tool all i have to do is write unit test and if my units are passing then uh the book controller and the book api is working perfectly and if it's not for not passing if it's failing then i need i know what i need to work on so this uh we can work on so in the next video some derby errors which we can definitely solve but for now we have our api running and the next video we will start with understanding how to write unit tests for our rest api application in the previous videos we had built our sdpi we had built the domain and persistence layers for our application we also had a created the build the business layer for our application and we did that using uh the book record which had the entry table annotations and also the fields we also created an interface uh called as book repository which extended the jb repository and it basically helped us with out of the box methods for club applications on our api last was the book controller which we had uh implemented in the previous video where we had implemented uh api endpoints such as get all books get book id post mapping put mapping and we will be implementing the delete endpoint in the upcoming videos using the tdd method now from this video let's actually start um doing the unit tests or writing unit tests for our applications and see how you know they look like how they work and so on and so forth so we will be writing a unit test for the book controller to check whether these methods are working properly or not which we had implemented so we need to test the method all these methods so get all book records book by id create book record update and also delete whenever we write it so to do this first we need to go inside test java and create a test class so we do new java class and we call this book controller test as we're unit testing the controller class and inside this now we need to uh add a lot of things and before we do that let's talk about something called as mokito which we will be using for our application so uh to give you some context for why we are going to use marketo uh now we just need to test this right we just need to test get booked by id and it should return us a book we should test that this method is working and every other external uh api in that in that method is not something that we need to test uh we can write tests for the book repository but mainly we are testing whether the methods work and if it's returning everything properly as intended so we don't really need to always uh call the book repository whenever we are writing tests for the controller because the point of writing the test for the controller is to test the controller and not the repository so what we need to do is find a way to actually uh mirror the methods given by the book repository or mock them so that we always know what we get back from the book repository and it is not dependent on an external class such as the book repository class here so for that to mock uh the methods and what we return from the book repository we use a framework called as mokito so now let's talk about mockito for some time marketo is a popular open source framework for mocking objects and software tests using mockito greatly simplifies the development of tests for classes with external dependencies now a mock object is a dummy implementation for an interface or a class in this case the book repository it allows to define the output of certain method calls they typically record the interaction with the system and the tests can validate that now let's see how it works so here is a very good website which helps understand how it works so first we mark dependencies for the class under test so we will be mocking the book repository we execute a code in the class under test that we do in our testing class and we validate if the code executed is as expected as we wanted it from uh the test so for those reasons we will be using marketo and now let's uh understand how pocket o works inside our application and inside book controller test so let's go ahead and start implementing it before we do that let's quickly set up our rest api properly before we end up with that because we saw some errors in the previous video when you were running the application so let's quickly uh clear them out so we need application dot properties file inside our resources folder and all we need to do is just have a single line which uh updates or which updates apache interview automatically so that we don't have to worry about those values later on and yeah once we have this our application should be up and running smoothly so let's test it right now let's run the application and make sure that application is running pretty smoothly without any issues just wait for a second and make sure that the application is running smoothly before we write our tests we have the console up and let's quickly see whether everything is running properly or not without any errors so far so good we have our database being registered everything is looking good uh start completed so the database driver is ready jpa has being initialized and topcat web server is running and as you can see no errors and we are good to go with our api okay awesome so now that we have our api complete and up and running we need to start using you know or writing our test before we actually write our tests we need to add some annotations to make sure you know it's test ready so first we need to do is do a run with and we'll be running with mokkito junit runner so this will ensure that we are only using market total on our class nothing else and make sure that it doesn't have the web server up before because we just want to test the methods inside not the web server the next thing which we need to do is have something called as mock mvc uh and we need a mock mvc uh object here we will initialize this uh before but uh this is something which we need the second thing which we need is an object mapper so we want to convert a json to a string and vice versa because when we do a post request we want to send the json as a string so let's quickly do that so we do an object mapper uh object mapper equal to new object mapper and next we want an object writer of the object mapper dot right so now we have our object right ready and we can use this uh for all the classes but for now we are only doing it globally not recommended but uh should suffice for this tutorial because we want to focus more on the united the book st because we don't want to call this every single time we run our test so we can do that by the mock annotation class by marketo all you have to do is mock what mark the book repository now we have a mock ready for our controller test called from book repository and uh the class which is going to accept the mocks is going to be the one which will be injected so we inject the box inside our book controller class and this basically tells us that yeah the book controller will be accepting uh the book repository as a mock inside it so we call it as inject box next let's create some test data so book sorry book record one and let's quickly import the book class and this will be new book and let's quickly give it uh the name so let's say account habits um summary how to build better habits and a rating would say five for this book uh next let's create some other records so regard to new book give it an id name can be thinking fast and slow summary can be how to create good mental models about think it and give it a rating as for last book that we can add is my favorite book so let's add this quickly algorithms [Music] correctly if you're using it and yeah we have three books ready uh we have our mock we have our book controller and all we have to do now is set up our class so let's do that let's quickly set up our test class so we have this annotation called as before uh this will run the method which we're going to implement before every single test so before every single test what we need to do is we need to set up our class and we want to set up marketer first so what we do is we do uh marketer annotations so annotations dot kenneth mocks we do this so this basically uh this piece of code basically uh initializes a marketo insider class a boilerplate code and again next thing which we need to do is initialize our mockmpc so we'll do it by mock mvc builder dot standalone setup and we want the setup only for the book controller class and we do a build on it now this ensures that we are using mockito and mock mvc for our controller class and it will not spin up any tomcat web server and it will mock our book repository when we are using it so in this way we understand how marketer works and we have our test class ready for some tests and we haven't uh actually implemented the delete endpoint yet which we will be doing later uh in the next upcoming videos where we use the tdd approach the test driven development approach to actually write our delete endpoint for this video uh we have actually we will be doing and finally implementing our unit test we will start with our two get endpoint unit tests so we have these two current points get all book records and get booked by id we will be writing a unit test for them and we'll see how that goes but before that let's just quickly go through what we have done in the previous video which was about mocking mokito and what does mocking mean so mocking is basically a way to mark all the external or hide our implementation details for external services for that particular class so for the book controller we wanted to mock uh the results and the values which we put inside the book repository and we only wanted to work our unit test our book controller and especially only these two particular methods for now for this video so we will be mocking the book repository and only checking if book records and book id works fine and for that let's start writing our tests so as we have noticed inside our general example test here we need to have a test annotation on top of our method so let's have a test annotation next we need it to be a method so let's have public and this is going to be get all records and this is going to be success so this is going to be a test where for a write input we get the right expected output so we will be adding up all of this uh inside our application book records one two three and then we will get back uh one two three as our successful output so let's do this uh let's quickly say it through the exception because it will throw an exception and let's try implementing it so first thing which we need to do here is we need to have a list of our book records right so we have three book records but they are you know three different book objects we need to have a way to have them in a list because a list is what we return here so we need to have a list of books right so first let's create the list of books so pretty straightforward list book and this is going to be the cards will be a new arraylist and inside the array list we have arrays dot as list and inside that we can have our records so we can have record one record two which are three so now we have uh the records which we uh have which should be the intended output we get or the intended uh return value for our get all book records method so this should give us out a list and the list is something which we have uh culminated here so this is what we expect back from our method if it's rightly implemented the next thing is to mock our book repository right we want to mock and fake our results using the records list so here what we do is use marketo dot when so when we do a call to book repositories find all then return so as you can see it's pretty uh easy to understand how they work then return records pretty straightforward pretty easy to read that when we call find all return records and that is what we are doing here so the get all book records is basically calling book repository find all and we are mocking this method to get back our records list of books now we need to perform uh uh emulation of the get uh you know a get request and this is where we use mock mvc uh which helps us perform that so we make a request builder so this is how it will be looking like so mark mvc request builders dot get and here it is slash book that is the end point which we are targeting next we want the content type to be media type application json so we want the content to be a json next is what we need to have inside so here what we do is basically have a request built so we have a request built and now we do and expect so this particular a piece of code will build a wreck a get request using a mock and the get request contains two things it contains the end point which is slash book and it contains the content type which is going to be in the form of json now once we make the get request what do we expect back right because we want to know exactly what we are going to expect the first thing that we expect is a status dot is okay so this basically tells us that when we do a get request to get all records here we get a 200 states and everything is okay the next thing to expect is and expect and here we expect uh let's say that since uh it is three records we want the size of the return let's return list to also be three so how do we do that we do that by mark and we result result matches dot json path and in the json path we have the expression tunnel which basically says start uh check the entire json and check if it has size three so this is a very uh interesting way of writing or checking whether the json is actually you know the js1 path from the beginning have a size 3. the next thing that we need to check is check a value randomly inside our record so until here we know that if the test is running successfully we will know that we are hitting slash book with the content as json we get back a 200 result the result which we get back has three records in it and one another thing which you can check to make sure that the records are correct is randomly check the value of our record so we do and expect and here uh what we can do is we're going to json path expression so this is going to be dollar to dot name so go to the third record and get me the name is how this we pass this json the value here is going to be exactly what we have here let's copy this and paste it here and put our semicolon and not here sorry my bad we okay no it's gonna be um yep looks good so in the last line 64 we tell that we expect uh the so it's zero index the third object's name to be glocking algorithm because that is what we intend inside our list of books as records so when we run this and if the test passes then we know that get all book record is working perfectly fine and i don't even have to run my application and check it on you know check manually on postman or some other api tool to make sure that it is running properly this is completely automated and whenever we run this it will automatically tell us whether the endpoint is working fine or not so let's go ahead and run this test and let's see whether our test passes or not and we will know whether the method that we implemented is a good a correct method or not so now it takes some time a couple of seconds for the test to run it is far faster compared to uh running a proper you know uh spring boot application so as you can see it just took us nine seconds to get the test right uh it took nine seconds because it uh my laptop is slow and it takes some time to things to actually get up but as you can see inside you know the debug info here you can see we do a get with no parameters that means get all and using application json and we are writing this and you know we get evaluating the path the path is okay it has completed 200 okay and this is how we actually understand that we are doing we are simulating or marking a rest api get request and this is basically how we write our credit point and now the next thing which we need to do is do it for get by get booked by id but we will do that in the next video or let me uh again read rate of what we had implemented in this video we had talked about uh get all record success which was for this get all book records and we expect it to be a success which we did get it by success i mean that it should be a 200 status code where uh the status is okay every all of this is provided by hamcrest and you know or the testing framework by springboard so we don't have to worry about how to implement it we just focus on the business testing part of it we check whether the json return had three objects record one two three and we also check whether the last records name was groking algorithms now you can you have to stick to the last one you can have a random tests here so you can have another random test for example let me show you another one so we do a control d and here instead of two let's do one and one is going to be thinking fast and slow and we should get one's value as thinking fast and slow and now we can run this again and see what happens this way you can make sure that every single record which you have returned back is correct and not false and this is a very good way a very simple way to check it and we will know that in a second when the tests are running and if the test passes we have implemented a correct get all records if not we screwed something up and as you can see the test has passed so we know that this particular method has been implemented perfectly and we don't have to worry about uh getting application up and testing it manually so this is it for the first method so let's get into it in the previous video we had written our first unit test which was a get all record success where we had where we understood how when and then return works by marketo how does how do we do a request builder and set up our get mock request and we also see what to expect back when we do an expect from our application in this video we will write the unit test for get booked by id and see how that works out for us and let's get started let's uh see how we can write it for ourselves and see how this is going to go out we do at the rate test same world we do a public void get book by id and again it's going to be a success throws exception and now let's see how do we do this so now instead of uh doing it that way let's do it another way of implementing this let's directly start with the marketo method so marketer.when the method call is going to be book repository dot find by id and the id is basically going to be record1 dot get book id now once this is done uh when is done we do a then return and we are returning an optional book so a simple way to return an optional book would be to directly uh wrap the record into an optional so the way to do that is java util optional of record one and that way we have logged our we have marked this particular stub where we have book repository find by id book id and now we will always get the record one as the return value whenever we call this inside this particular test method the next thing which we do as we know is pretty straightforward we have our request matcher i'll quickly swim through this so that you know we can save up on time and it is pretty straightforward and similar to how it was so we don't have to worry about it uh as you can see uh we do a mock request builder to get slash book slash one because one is the book id for this we application json status is okay we do another check here instead of checking the size we can just check whether this is not null so that it has something inside the json has something inside it that tells us that it does not null and the next thing would be uh to check the name and the name should be atomic habits because that is the first record atomic habits and that way we should automatically know that the test passed or not pretty straightforward nothing complicated here very straight forward to the point and let's quickly run the test and make sure that our both the tests are running properly so yeah as you can see this one also ran perfectly because we had auto we uh intended it to be running you know successfully so we had marked the find by id we performed a get request emulator and we expected the response as we wanted so these were successful and now let's actually write the tougher ones which are kind of tough to write not exactly tough but a bit convoluted for create book record so let's see how this is going to look like we do a test public void create record success now this is an interesting test because first we need to create a book record the second thing would be to mock save which is basically save method and then we want to when we do a post we want to make sure that the content is in the form of a string and then we perform our request so a bit on but we will uh you know make this code um we'll modularize this code to make sure that you know we understand everything that is happening inside it so let's start first let's post let's create a record to post okay so we'll do a book record equal to book dot builder class and we can use the builder class for a lot of things so first let's do book id which is going to be 4l next is going to be the name let's say the name is introduction to c next is the summary the summary is going to be the name but longer and next is going to be rating five uh obviously dot bill and this way we have a record which we can post now next thing would be to mock our repository method which is save so let's quickly mock it so marketo dot when and what do we do here so when book repository dot save and we are saving our record then return the same exact record and pretty simple pretty straightforward mocking scenario here next uh instead of you know writing our request builder here let's actually you know uh write this separately and then do a perform so what do we do here what i mean by that so what we are going to do here is we are going to build a mock http servlet request build so mark http servlet request builder which is going to be a mock post request and this request is going to have mark m we see request builders dot post so they have everything handy for post and we are posting to slash book pretty straightforward the content type is going to be media type application json right the next thing is going to be what we accept so once we do a post request we are returning back a json to the client as well right because if you see here once we create a book report we are returning back a book exactly as we are reading back our json here so we are accepting a media type as application json the next thing that we are doing is passing the content or the request body basically so the content is going to be well content and that we need to actually uh implement so we can't directly pass a java object up a pojo plain or java object to the content but it has to be converted to a json here this was handled by springboot for us but with these annotations but here we need to manually address that so for that reason we have the object mapper and writer here so how we quickly do this is we do string content which is going to be object writer dot write value a string and the value which you want to be written as string is record now this will convert the plain old java object to a conte to a string and then we pass the content inside here and now we have a mock request ready to be sent now the next part is similar to performing that post request right so how do we perform the post request we do a mark mvc dot perform and what are we performing the mock request that we just implemented the next thing would be to expect what when we perform a post request we do an and expect this is going to be a boilerplate so status dot is okay to make sure that it was successful second is and expect the json part to be null so we can copy this from here and we can also copy this from here so let's copy it out and let's quickly paste them the only change here would be the name so the name has changed to introduction to c this also needs to be introduction to c and this is how we write a post request so we will go through this again but let's quickly first run the test to make sure that the implementation is correct and then we can talk about what we don't actually learn in this particular video so so far so good we have the information and the test has also passed great let's see the logs okay so here as you can see we are doing a post request we see that we are reading application json and for this particular string and we see what supported by we are writing or doing a post we get back to 100 and we can evaluate the path of the json so here uh we did not go through this approach because we wanted to abstract out or you know make our code look better and more readable so first we created a book record using the build builder uh method inside our record so if you go inside book you see the builder annotation that helps us uh make or create an object quickly using the builder method next would be the market one and then which we have talked about in the previous video as well where we make sure that whenever we mock an object we return back uh the we mock a class and method we return back the object next thing as we are passing doing a post request we need to send the request body in the form of a string and we achieve that using an object writer and finally we create our mock request and then perform the request and expect the values back so let's quickly run all of them again just to make sure that everything is nothing has no we didn't break anything because each each test has to be independent of itself it should not it should not be stateful because the unit test it should be the smallest unit which you can test and they should never ever interact with each other so as you can see all the three of the tests pass none of them have anything in common other than the controller which you are testing and this is how we write our test for the create book record method and now in this video we will be writing the code for the update or the put api and then in the next video and the final video we will be writing a slash delete endpoint using the test event development method where we first write the test and then we implement the delete endpoint for our application and as you can see we have tested out every single endpoint whether it's working properly or not based on just our tests and we did not uh have any tomcat web server running or we didn't have to even run the application to understand whether our code is functioning properly or not and that is majorly the power of unit tests where these confirm uh the usage and the implementation of your code and it ensures that the code which you're writing is implemented correctly so yeah pretty important and you should be doing this whenever you write code which is used by organization so before we start writing our unit test for the put api let's just run the tests and see that everything is running smoothly and we have only two more tests uh left right one is the update test and the last one which is going to be done via tdd is the delete end point so let's quickly see that everything is running smoothly and we should be good to go so everything is going on perfectly all the tests have passed and let's start with our put api so for this uh it's going to be how we want it to be right so we want to update a book record so for that first we will have to mock two things here so if you go inside book controller and see update book record we are calling the book repository twice first to find uh the existing book record by the id uh so the one which you want to change and then we update it with the record which we pass it in the request body and then we call book repository again with a dot save method so here uh since we're using book raw an external service twice we'll have to mock both the methods find by id and same so when we mock both then we are actually able to emulate or mock the entire repository and see whether the update is working properly or not and the logic of it so let's do it let's actually see this in action we have our test annotation public void update book record success close exception and let's start with it so first we need to have an updated record right which will be in our request body so we need to have a book record which is already updated so let's have a book updated record and we can we use the same builder class for this we use builder and dot the book id has to say the same uh the next is the name so the name is going to be changed to let's say updated book name next thing is summary the summary is going to be updated summary and lastly the rating is going to be 12 1 dot and now we have an updated book record so first we find the record for 1l so we need to mock that and then we update it with the updated book object so let's see how that is going to happen so we want to mock uh things right so first thing which we need to mock is find by id so let's mark that first so marketo dot when book repository dot find by id and this is going to be record one dot get book id so whenever it finds the record one l or one then return record one right so that is basically what we did for get book by id and you know we were good to go now uh the next thing that we need to do is mark the next part which is mocking the save method inside book repository so let's copy this exactly and here we do a save and when we save we want to update it with the new uh updated record so we do updated record and here then we return updated record again so this will tell us that we have updated the record properly and we are good to go in this context so let's quickly make the syntax look good and yeah so now whenever it goes inside the port it first we'll go into this check whether exists or not and this is the logic which we are testing by unit tests this will uh work because it is not null then we mock find my id so we get back record one which is the existing hardcoded record which is mentioned globally next we test unit test the logic here and it is present so we don't get it not found and we go here we go in here this part is handled by us where we update the record and then when we go to save this is where uh we again uh mock it and we return back the existing book record which confirms that our test is working properly without any uh issues so what is next uh next is to again create a mock request so before that let's uh we have to get our content again so let's quickly have our content defined and here the content is going to be the updated record and we can just call this updated content because it under helps understand what it means so we have updated content here and the next thing would be to have a build a mock request builder right so let's implement that so we want a mock http servlet request builder which would be a mock request and this is going to be mock mvc request builder dot put so we want to test put and we want to test it for slash book the next thing is the content type which we want to accept so it is going to be media application json we accept the same thing so media application json again and last but not the least is the content which we passed which is the updated request body and this is going to be updated so now we have our mock request ready and the last thing is a pretty similar pretty straightforward to what we had done for uh post request where we do mock mvc dot perform and we perform the mock request and once we perform the mock request we expect something the first thing which we accept expect is status to be okay the next thing which we expect is that we should get we should be returned something from it so this is going to be json path which will include the entirety of the json and it should be not null this ensures that we did we did get back something from uh our request and last thing is to check whether the name has been updated or not so here uh we do a json path uh dollar dot name there's only one id here and we do is and we match the value of updated book name and this will confirm that yeah so we went from record one and the name in record one was atomic habits and then we are returning it back uh as updated book name here so that is what we want to confirm that output worked perfectly and it ha it has given us exactly what we needed from it so let's run this and see how this works so the test has passed that means our api all of our create update and get retrieve apis are working properly for the ideal uh input that it gets or the ideal parameters now uh we have done this for the success cases right but the homework here which i would like you guys to try is to try this for the not found exception for example what happens when you do a get by id and you give it a random book id which is not present in a database and then what happens how do you handle not for an exception because here if i would not give it as a book id but i would give it as 4l which is not technically not present inside r you know in memory objects so here this would fail and we want to make sure that we also cover the cases where uh what happens when the method fails and you know when the code crashes are we handling that or not so the homework would be to try to uh have a test which handles not foreign exceptions because as you can see we get a test fail here so we need to handle those conditions in our unit test as well and that is the homework for you guys where you need to understand how to write them and we can definitely talk about them once you have you know given a solution in the comments uh make sure that you have a test class like this a test method like this and you have it again booked by id underscore 404 not found or just not found and implement this and let me know how it looks like and then we can discuss it as a new video so that's it for this video uh we have covered how to actually let unit test for our apis now in the previous videos we have learned about how to write unit tests for our pre-written api methods get all book records get book id create book record update book record and so on and so forth but we have left out writing the delete endpoint using the tdd method which is the test driven development method so in this video we will be writing or implementing our delete endpoint using uh unit tests which we write first and then we implement our delete endpoint so this is going to be a very basic tdd implementation which will give you an idea of how it works and then your homework would be to add in the not found exception edge cases to the uh method using test event development so without further ado let's actually start implementing it so first to implement this we need to have a test so a test which is going to be public void delete book by id and this is going to be a success test so this is going to work to get our basic delete up and running and working so it should just delete our book and that's it so we are going to be deleting by id so the first thing that we need to do is we need to uh use the book repository to call find by id right you need to get the book first and then we delete it so let's do that first let's actually mock our book repository find by id method so that we know that whenever we called find by the in our actual implementation it will be mocked so we do mock it o dot when and here book repository dot find by id and let's do record two because we haven't done that in a long time and then return uh optional of record 2. so when we query the query for the second book we get it back and once we get it back all our delete endpoint is going to do is deleted right we are not going to return back uh what we deleted but what we can do is just send a 200 status that yeah what we uh the delete worked so that is what we will be testing with our simple success test case where once we delete the book from the database we get a simple status code status is okay so that is what our test is going to look like so we do mock mvc mvc.perform and here we can do a simple mock request builders and under this we can do dot delete content type also so let's quickly do that dot delete and will be slash book slash 2 because it's the second record that we're deleting the second thing that we will be doing is the content type so let me quickly go and do content type and this is going to be media type application json and as you can notice here uh when we write this we already know that the way we implement our delete book method or endpoint is by having a path variable right as we have for get book by id so similar path variable and no request body will be there in our application so this is something which we understand as we write our test cases so now that we have our perform and request builder ready we just have to expect one thing which is that the status is okay and that is all that we need for a simple delete book by id success test case unit test so now that now in this test driven development approach we have written our tests and uh in theory this test should function well in order for our delete api to function well so let's run this and obviously it will fail because there is no such api yeah and that is exactly what we want we should always predict the behavior of our code with the test that is test driven so here we will know that the dust will fail and for the exact reasons why we wanted to so we wait for it and as you can see we wanted the status quo as 200 but we got a 405 which is not what we wanted so now we know what to do now what we do is we head to the book controller and here we start implementing our code so let's start this is going to be a delete mapping and the mapping will have a value which is going to be the book id and this is going to be in strings so let me quickly make them in strings and public void delete book by id and this will have a path variable because that is how we are approaching our method and this will have a variable book id as specified above and this is going to be a long book id this throws are not found exception so we will delete the node from exception later but for now let's just implement our method so now uh we check the book repository first we do a find by id book id dot is present and if it is not present then we throw new not found exception uh book id book id not a simple uh friendly message that the book is not present and the next thing that we need to do is just delete the book from book repository so book requisite dot delete and delete by id is what we are going for and we give it the book id and we are good to go so now we understand that it just took me uh two minutes to implement my method because i already knew what i was looking for and what i was looking for in terms of the idea of how to implement it because i already had my test ready now i do have my test ready and i have written some code if uh i would not be using unit tests the way i would test this code would be to run my entire application and then uh create a book then i delete the book i check the database whether it's deleted or not or i can just run this test again and this will automatically tell me whether my method which i just implemented is correct or not and that is the main reason why we want to write unit tests and follow test driven development because we don't it makes it very very very easy to understand how our code is functioning and behavi and as you can see we have a pass.test that automatically tells me that the code which we have written for our delete endpoint is working and then we can remove this to do and we are good to go so this is how easy it gets with test driven development because we now exactly know how our code is behaving and how it should be here because we have written a test for how it should behave we know that it should behave in a specific way where if it's going for god 2 it should delete record 2 and the same thing would be for record 1. so if i do this as 1 i change this as 1 and also this as 1 it will delete record one and we can test that again and you can see how easy it is to actually update your tests and change them and understand how your code is functioning as you do it now another way uh to do this or to see what's happening behind the scenes is to you know run this in debug mode with a breakpoint so once you know the test is running we'll see how that is working so now i want to know what is happening behind the scenes right so i can just put a breakpoint i can run it in debug mode and when it comes here we will break the code and we will see what's happening behind the scenes so the test is running and once we reach line 138 the execution will stop and yeah as you can see now we can see the data behind our application so mock mvc is what we are using and when you see inside mock mvc we see the servlet context we see what we have we see the dispatcher which we are using the default dispatcher and what is inside it the value or what kind of logs it does all of that so you can see the servlet as it's using the different kind of mappers we also i can see what we have here so we have records book id etc etc then when we continue running it we see that the tests have passed so this is how we implement a delete api using test driven development where we first write the test and then we implement the logic behind the test now uh a couple of things that would be the homework would be these so the first thing which i would like to do is i want you guys to add this in the comments where you do get book by id and we do not so how would you implement this this test is what we would like to know the next test would be something like not found for a delete so public void delete book by id not found and what happens when you give it a record as 70 as a book id and we try to delete 70 but delete but 70 a book id does not exist in the database so what how do you handle that test case will the code break or not so we handle that and we want to know exactly how the code is working so that is basically what we do with our uh you know negative tests so this is a positive test where we know what is going to happen it's going to be successful these are negative tests which tell us uh what to when we have control over what happens when the code breaks so this is this was the playlist about how we can write unit tests for our spring boot rest api application i hope this was helpful if you have any doubts please mention them in the comments below and thank you for watching i'll see you in the next playlist

Channel: ProgrammingKnowledge

Views: 115,404

Keywords: Oracle, Javaprogramming, Javatutorial, Spring Boot, Spring Boot Tutorials, Learn Spring Boot, Getting Started with Spring Boot, Spring MVC, Spring Boot Actuator, Spring Boot Projec, Learn Spring Boot Tutorial, Spring Boot Full Course, Spring Boot Online Course, Spring Boot - Online Courses, Classes, Training, Tutorials, Free Spring Boot Tutorial, Go full stack Spring: Spring + RESTFUL API + Spring Boot, Hands On Spring Boot Course, Junit, unit test, spring boot testing

Id: KYkEMuA50yE

Length: 108min 48sec (6528 seconds)

Published: Wed Nov 10 2021