Now I'd like to talk to you about test doubles for input. So, just to recap, we are using test doubles to provide the ecosystem for our system under test. So the idea is that our system under test may interact with other systems, but these may be unavailable, may be incomplete, or they may just be too expensive to use. So, instead, what we're going to do is we're going to provide our own inputs to the unit tests in a way to fake that we have these other systems. In order of the amount of work that's required and the amount of functionality that's provided, we have three different kinds of inputs. The first are dummy objects, which are values that we need as parameters for the test input, but we don't care about it all. So, we just want to pass in something, but the test, for example, won't except a null input. The second thing are test stubs, and these are very lightweight special-purpose objects that we construct, that for a handful of values can provide outputs. So, basically, if we call a method on the test stub and it has these specific inputs, we can provide a value back out. A more rich notion is that of a fake object. So, basically, we want to replace something that's expensive to use with something that's cheaper to use, but otherwise, it acts in much the same way. So, a fake object would be, for example, an in-memory database which is much cheaper to query than an external database that's running on a server somewhere. So we're going to talk about each of these three kinds of inputs focusing on the first two. Fake objects, essentially what you do is you write a new class that acts like the thing you want to test. But for dummy objects and test stubs, we can use a framework to very, very easily construct those objects, and that's called Mockito. That's what I'll show you now. So the thing that we're going to use is something called Mockito. Mockito, which is available at this website, site.mockito.org, is a mocking framework that's specifically constructed for creating unit tests in Java. What we're going to do is we're going to use Mockito. The way it's designed to be used is through something called Gradle. Gradle is a build system that integrates in with Eclipse that allows you to bring in external tools very easily. So let's look at our Eclipse environment. If you're not running Eclipse, Gradle is very easy to use from the command line. So the Gradle files that we construct will be just the same ones that you would do if you were writing Gradle by hand. So, here we have a file that we're going to use to describe how we do mocks and stubs, these test doubles that we have. We're running in Eclipse, so much like you've seen Kevin run Eclipse in previous exercises. So this is just the same. In order to use Mockito, we're going to install a plugin that brings Gradle into Eclipse. The way that we do that, is we go to the Eclipse Marketplace, in Eclipse, and we type in Gradle. When we do that, we find this thing called Buildship Gradle Integration 2.0. We click on install, and that'll add support for Gradle into the system that we're using. Now, I've already installed it. So, you can't see the installation process, but it's quite quick and easy to do. Once we do that, then we get a Gradle file. We can create new projects. I'll just do it this way. We can create new projects, and we can say that we want to create a Gradle project. So, that's what I've done in the example that you see here. When you go out and look at the files associated with this lesson, you'll see a project file, and it'll look just like this, this travel system. So, if I want to create a new Gradle project, I just click here, I click Next. I'll say "Example", and Finish. It's thinking about it a little bit longer than I expected. But usually, this goes pretty quick, especially after you've done it once. It's one of those things that it has to load it the first time. So that's how you get Gradle integrated into your Eclipse environment. Once you have it, if we want to use Mockito, all we have to do is, in the Gradle file, there is a space called dependencies. So, if you look at like this new example thing, if you look at the Gradle file here, there's a dependency section and already we're using JUnit. What we would do is we add in this dependency to Mockito. So if we look at the website for Mockito, it tells us that step right here. So we can just add that in and then we can use Mockito. So that's how we get started, and that's all kind of background for what we're actually trying to do. So what are we actually trying to do? Well, in this exercise, we built an employee travel scheduler. So, imagine you work for a company and you're trying to manage employee travel. In order to do that, you're going to have to interact with a bunch of external services, maybe an airline travel service, maybe a hotel service and other things. In this case, we're just looking at our interactions with an airline travel service. So what we can do, is we can go look at these employee travel scheduler. What are the things that we can do with it? Well, we can find flights. What the findFlights() method is going to do, is it's going to go out to the airline travel service, find flights, but then we have special rules that we set up as an employee travel service. First, we're going to sort them in order of price because we'd rather the employers take the cheapest flight. The other thing is that if there are flights that cost more than $2,000, we're going to remove them from the list. So we're not going to allow flights that cost more than $2,000. So we have this function called sortAndExcludeNonconformingFlights(), where we take a list of flights, and then we sort them by price, and then we filter them to remove the flights that don't conform to what we want. So this is the class that we want to test, and we're going to try and do it using mocks and stubs. So let's look at a couple of things that we can do. Oh, there's one other thing I want to bring up, that's also external to the lesson. So, once we've brought in Mockito and Gradle, we can import Mockito classes into our test framework. One of the interesting things that you see here are these "import static's". So, what does this mean when I import something statically? What it means is that I can use the static methods from those classes without prefixing with the class name. So, here we have an example where we have the class prefix. So, we're calling a static method on org.mockito.Mockito. So, this is the package and this is the class name and this is the method name. But because we've imported Mockito as a static class, we can use the methods out of that class directly without putting all the prefix stuff on there. The same thing is true for assertions, and we've already seen this in JUnit. So, we've used things like assertTrue() and assertFalse(). The reason that we can use them without a prefix is that we've imported them statically. So, that's how static imports work. I just wanted to get that out of the way in case you didn't cover that in your Java class. But anyway, what we can do is we can construct a dummy object just by calling this one method called mock. So, mocks are something different according to what we talked about in the intro. Why do we call this creating a dummy object a mock? Well, in Mockito, there's a distinction between the roles that a class plays and how you construct it. So, the roles that a testable may play might be a stub or a mock or a dummy, and sometimes it can be all three at the same time. The way that you construct them in Mockito is the same. So, we use this mock to construct just an object that doesn't have any functionality, that has default values for all of its fields based on the class name here, so this is Employee.class. So, now we have a dummy Employee, and we can pass that Employee in to methods that expect to get an Employee but we don't care about what Employee it is. The way that these dummy objects are constructed, there's a convention that it uses for the fields. It always tends towards the zero element. So, in an Employee, you have a name, you have an ID which is a number, you have a salary, you have an address, and the way Mockito works, if you have a dummy object, if you have any field in that class that is an object, that gets assigned null. If you have an integer, that gets assigned zero. If you have a floating, it gets assigned 0.0 and so on. So, basically, it always tries to find the zero element, and those are the assignments that get made. So, always assertions are true here. Now, those dummy objects are only useful in a small number of circumstances because usually if we have a parameter to a method that we're testing, we want to do something with it. So, that's what stubs do. So, in this case, we'd like to be able to test our employee travel service, given an airline travel service. But the real airline travel service, we can't use in our unit testing because it's actually an external service running somewhere. Now, we don't want to actually book any flights, we just want to pretend that we're booking flights. If we call out to the real service, we'd be in trouble. So, what we want to do is we want to create a stub of that airline travel service that we can use for our testing. So, how do we do that? Well, what we can do is we create the same process that we use for a dummy object, we create a mock of this AirlineTravelService.class. But here's the really cool thing about Mockito, is that allows us to incrementally define functionality for this dummy objects. So that under certain circumstances, when it gets invoked, it'll actually return a value even though we haven't really instantiated it correctly. So, what we can do here is we call this thing stub service, and we've created a couple of flights as things that the stub service should return when we make a query to it. The way the service works is you pass in a day and a time when you want to find flights, and then it's supposed to return you a list of flights that match that date and time. So, what we can do is we can say, when we get a call to the findFlights() method, which is defined in the AirlineTravelService class, for any date, we will first return this list of flights which we define here, it has two elements, and then the next time we call it, we're going to return an empty list of flights. So, there were no flights available for that date and time. What will happen is the first time that our employee travel services calls the findFlights method, it's going to return this list and the second time, it's going to return an empty list. So, now we can use that stub to instantiate our EmployeeTravelScheduler. We can create a dummy employee, and then what we can do is we can check to see the behavior of our employee travel service is working correctly. So, what things do we want to check about our employee travel service? Well, we want to check that it returns the flights in price order. So, what we're doing here is we're saying that we've defined the flights in such a way, in the original list, that the more expensive flight was first and the cheaper flight was second. What we want to do is we want to say that after we call this employee findFlights method, the first element that we get is the cheaper flight. Then, what we want to do is if we are asked to find flights again, we'll get the empty list. There are no flights available. So, this gives you an example of how we can actually use these stub objects to test the class we care about, which is the EmployeeTravelerScheduler, even though we don't have access to the real airline travel service. Let me just run these just to show you what it looks like. When we use Gradle, we get another tab down in our Eclipse framework here, and we can run different tasks on the project. And, one of the things we can do is we can build it. So, we'll do that here, and it runs for a little while. And, one of the things it does is it runs all the tests that we've built and all the tests that we have right now passed, so that's good. So, we're able to check that our EmployeeTravelScheduler does the right thing when we give it that stub. Now, in that previous example, we had a stub that worked for any call that we wanted to make to it. So, it doesn't matter what date the person passed in, we're first going to return the list we defined, and then we're going to return an empty list. You can also parameterize the results that get returned. So, we can look at a particular date. So, right now, this thing is just creating the current date and time. When we do this, we're only going to match when we get a call to findFlights() for that date. So, right now, this works because we're going to find flights based on that date. But if I was to, for example, choose a different date, replace that date with, say a date, this is just a date 10 seconds in the past, and then try and run these tests. What I would find is that the test would fail. So, let me just go back to Gradle Tasks, here, rerun build. Now, we get a red exclamation point in here, and what happened is that the EmployeeTravelerScheduler testFindFlightsMatching1 failed. The reason is because when we define the stub, we said, "Okay, here's the return value for that method if the parameter is equal to the current date and time." But then, we changed it so that it only would match the current date and time minus 10,000 milliseconds. So, now, when we try and use that stub object, there's actually nothing there when we put in the current date and time. So, this allows you to essentially define for multiple different parameter values, the expectations of what the stub object should return. You can define those in lots of different ways. Right now, we've looked at any class or a particular concrete object. But it turns out, you can match on things called Patterns. And that's outside the scope of what we're going to talk about in this class, but I would encourage you to go out to Mockito and check that out. So, we have more examples of matching. There's a whole language on this called Hamcrest, and here is the website on that ("http://hamcrest.org/JavaHamcrest/"). When you look at the code, all these comments are in there, so you can go out and do further exploration on your own. But this gives you an example of how you can use stubs and dummy objects to provide inputs for your system under test when you're testing. Thank you.
