Mockito and BDD : A Quick Tutorial

before we start with the next step we would start with a few exercises first exercises what would happen if we combine a machen with a hard-coded value in this particular method I'm using English mob Dutch submit sub-lists sorry and I would want to pass in one of the parameters as any integer so if the first parameter is any integer and the second parameter is five I'm saying then throw this exception most important thing is what would happen in this particular case so you can cry it out and see what would happen and you will find out that mockito does not allow a combination of matches and a hard-coded value so you should either be generally always or you should be very specific in each case so you can try that out and find a little bit more about it the next thing you can try is to mock a few other list method try and play around with it so that you will be able to understand much mouth and the other thing is to find out what would happen if a nun step is called we have played around with this already peek understood the concept of nice mock because by default we know now that for all methods that return a value a mock will either return null a primitive value or an empty collection we saw that it returned an empty list when we did not stub it so similarly it would return an empty collection of that particular type when we do not stub it so one of the examples is deterrence a zero for an integer for any boolean value by default it would return a false back so those are the things that would happen when an unstable method is called so you can try all these three exercises before you move into this specific step we are now in step 6 and in this step we are going to be introduced to something called BDD behavior driven development so what is behavioral development let's try and understand that with an example so you'd know that most of the agile projects use user stories at the user story level you'd say as a store owner I want to add items back to stop stock when they are returned so when items are returned back I would want to actually add them to the available items in this store so that's the user story but if I'm properly doing behavioral development what I would do is I would kind of create scenarios around this specific user story so the first scenario which we are creating is that when when there are let's say three black sweaters in stock and a customer returns the black sweater then I should have four black sweaters in stock so you write the scenarios in a given fan then format so you take given that somebody has bought a sweater from me and I have three sweaters in stock when he returns this waiter back then I should have four black sweaters in stock similarly other scenario so given something and something and something when an action happens then this should be the result in a given in a behavior in development scenario what we would start doing is splitting the story the user story into multiple scenarios of given when then conditions and once I've split the story into given one condition then conditions then I would start writing tests for each of these scenarios so what do you do is we would start writing tests in the same format as the scenarios so you'd write start writing tests in a given when then kind of a format so you'd start saying given something when something happens then do this this is the kind of test that we would start writing so this perfectly matches how unit testing is typically done because at the start of a unit test you do something called a setup so the setup is usually to set up all the scenarios I mean set up the base situation for a specific scenario that's the given and when is the actual method call so the actual method call which we want to test the system under test method call so when the specific action happens then we check all the asserts so then we would assert that something has happened so this given when then is a good way of writing your tests and what mockito did is also come up with a specific class it's called BDD mockito where there are specific methods which would help you to write tests in that way so instead of using one and then return you can say given this then do this something of that kind so even the syntax of mockito allows us to write given when then kind of a situation let's use the BDD methods that mockito provides let's go to the to do business I am PL mockito test and we know that there is a test case in here where we were using a mock so I would actually now copy this test case I will remove the empty list one which we created to understand mocks in more I'll say using a bead using BDD enough I've copied this perfect test the test is not doing this is a very simple one so basically we are stubbing the to do service mock and then we are actually invoking the specific method and then we are checking whether the size is matching or not so now we would want to actually divide this into given when then kind of our way given should be everything that is doing this setup so if I look at these lines of code this is the one which is doing this setup so I'm setting up the mock to return something and when is the specific business method action so this is also part of the setup so I'll know this up as well when is the specific action that needs to be done so this is the method call which is doing the actual when and then is this in the given I do the setup in when I would actually call the method system on the test and then I would check whether all the changes that I am supposed to be making in that specific system and the tests have happened the great thing about mockito BDD is it even gives a specific method so instead of using when I can use given so given add a static input instead of using one because I am doing the system setup I can use given this the specific method would return to do so it's just as change in syntax nothing more but you can actually express the fact that you're doing system setup so I'm doing a given so given this specific thing I will return this back so when I am doing something as part of the Givens steps of these tests then I can use the given will written syntax and so this is the given part so in the given part I am doing this setup so I do the setup in here and I also use the given syntax so this is just a syntax change I mean instead of n then return I'm using given will return the given is implemented as part of a specific package sorry specific class BDD mockito this class is used to do all the BDD kind of a thing where you have a given build return kind of a format so all these methods are defined in this particular class so if you look at this we have automatically statically ported that particular things would be actually just static import on BDD market or that given and that's how we are using it in here so we using given will return so given will return and then we are actually doing the when and the then the other thing about BDD mockito is that there aren't a few specific methods so I would have methods like introducing assert equal I can say assert that filter to do start size ease to let's add a static import for that so you'd see that instead of assert equals filter to do to comma filter to rules or tries I can do something called SL diet filter to restore size is to you can see that this is much more readable so we are saying given this particular thing this will return a to do when this happens I said that filter dot to do size is two so this is kind of much more readable than using a set else to come a filter to those dot size so this is one of the things that you can do to make this more readable so use the assault that things with the core matches which are available as part of hamcrest so this is part of the East method is part of the hamcrest matches we will discuss a little bit more about the hamcrest matches in subsequent steps but for now you can think of this would check if this value is the same as this value and if it's not this test would start failing so basically if you look at it switching to BDD is not really a earth-shattering thing it's basically a small changes in syntax which kinds of make the test more readable so you actually split the test into three different parts given when and then and in given you do this setup and also you'd use the given kind of a syntax so you'd use given will return and in the end you would actually make the actual invocation and in the den you would actually use readable acids introducing assert equals you do something like assert that and you would actually check if the post conditions that you would want to check are all satisfied so given our preconditions when is the actual method called then you check all the post conditions so that's basically what you would be doing in a typical BDD test so what we'll do is we'll quickly go to the list test or Java and let's pick up a test from here let's say this one let's quickly transform this to use BDD so if I was using BDD here so you need to first say which is this setup part of it so that's the given so this is given right so I'm creating a mock and when this is happening then return that back so that's given and the actual system invocation is this right so I'm actually doing a list mock dot get 0 that's the actual 1 and then is the actual I mean then are the asserts so what I will do is given lists including amok and then I would use the given syntax so given this I'll add a static import and I'll say given when it's given then it's will return so we'll return the specific value so given any to int so I'll take the first element and put it into a let's declare it as list of string because it's not loving me to typecast to that so string first element is equal to list mark dot get 0 and I'll say instead of salt equals I'll make it more readable and say I said Qualls sorry I should say I said that and yeah the first element I'll use the YZ YZ in 28 minutes I remove the second condition but that's okay so let's restrict our test to the first condition alone so you'd see enough that this test would succeed mr. succeeds and we were writing this in the given well then style so given when then so given a mock where everything is written in in 28 minutes when I get the first element I am asserting that the first element matches my expectation so this is the way you can write tests using PDD like bead it is nothing I mean as far as stress is concerned BDD is basically a good way of organising your tests so you structure them and given when then and also you'd make the specific syntax which is available for them so in given part you'd use the given will return and in the in the then part you would probably use something like a ham Chris matcher I said that methods so that's about BDD one of the exercises you can do is you can take more methods that we wrote I mean more tests that we wrote and you can try converting them into a BDD format so try and put them into the given there when then structure making use of the appropriate it syntactical sugar to theory look that's about BDD until the next step okay there is one question we are frequently asked what do I learn next hour in 28 minutes course guide has the answer to that question think about this for a moment what gives more satisfaction to a course creator lots of money yeah it does but what else great reviews yay that's it for me the happiest moments are when I really receive great reviews and we had 1,500 such moments in the last eight months so that's 1,500 five-star reviews in the last eight months alone thank you for that these reviews really reflect what we wanted to achieve when we started in 28 minutes there is one question we are frequently asked what do I learn next hour in 28 minutes course guide has the answer to that question it has the details of our most popular free and paid courses you will find a link to it in the description of the video let's take a quick overview of the different courses that we created for you as Kevin says the Java EE made easy code gives you the big picture there are a lot of pieces that make up the Java EE and this course should help you to understand how all the pieces fit together the spring MVC course takes you through a journey of building a web app in 25 easy steps as Alexander says we follow the 2080 principle and take you through a great journey with java servlets and JSP building a java ee web application in 25 easy steps mavin is the dependency management framework used in more than 80 percent of the projects this goal take you through a journey with mavin with real-world examples and we have courses on C for beginners and also see puzzles for interview preparation we have a huge list of free courses as well spring Eclipse J unit design patterns Java tests Lyon development transaction management JavaScript Java collections mojito and we are number one on YouTube for Java interview questions good luck with your learning always remember that the best way to learn is by doing you'd never learn riding a bike by just watching somebody do that similar to that learning programming is all about getting your hands dirty keep getting your hands dirty and good luck

Channel: in28minutes - Get Cloud Certified

Views: 21,846

Keywords: in28minutes tutorial, bdd, in28minutes, Mockito BDD Tutorial

Id: ukAmNbW790s

Length: 15min 48sec (948 seconds)

Published: Tue Sep 06 2016