We've been talking a lot about unit testing and how to do it effectively. But it turns out that you can't do unit testing in a vacuum. You need an ecosystem, so oftentimes you're trying to check a particular class or particular subsystem. But in order to do it, you have to interact with other subsystems. So maybe the thing you want to test interacts with the database or it interacts with the file system or some kind of framework. Maybe a GUI framework of some kind, or maybe it uses services that even aren't under your control. Maybe you're calling out to an airline travel service that you don't own. So it calls out to remote processes. So, one of the things that happens is that to do effective unit testing you have to get to the things that may not even be available. So, if I need to ping the airline travel service and buy flights in order to check how my thing works. That's going to be a problem when I'm doing unit testing. And sometimes I want to use services that aren't even written yet. So we're developing something parallel and some other team hasn't finished their work, and so I can't test my stuff because this other thing that I need isn't available. So we need to have strategies that allow us to unit test even in these circumstances. And the way that we do that is something called test doubles. So test doubles are lightweight versions of the components that your system under test or software under test interacts with that are necessary for us to do unit testing. They're kind of like stunt doubles in the movies. So it wasn't really Indiana Jones who was running away from that boulder in Raiders of the Lost Ark. Test doubles sort of take the place of those stunt doubles you see in movies. So why create test doubles? There are lots of reasons. As I already mentioned, the real components may not yet be finished. It could be that it's just expensive to construct a real component, so maybe I'm hitting a database but in order to build up the connection and set it up, it takes seconds, or minutes. And what we want to be able to do is test effectively in seconds or even fractions of a second. It could be that the real components are owned by someone else and they don't want you to just go out and hit them repeatedly to do your unit testing. Another reason is you want to avoid side effects on real components as a result of testing. So maybe your system makes changes to the file system. But if you do that repeatedly, you'll actually fill up the temp space. Or maybe it makes changes to the database but we don't want those changes to be permanent. And the other thing is that test doubles help prevent something called Flakey Tests. Tests that work sometimes but not all the time. So it could be, for example, that I'm trying to hit the database, and sometimes the information that I expect to be there is available and sometimes it isn't. Because I'm not the only person using that database. It can update without my knowledge. Or maybe, if I'm trying to use somebody else's service, like this airline travel service, maybe that service is down. It's just crashed and I can't get there and then my test will fail. So what we want is we want to avoid Flakey Tests. Tests that work sometimes, but not all the time. And finally, with test doubles, we can not only look at the result of the test, but sometimes we can look at the interactions that the component that we care about has with components that it talks to. So we'll call this mocking, and we'll see examples of it here in just a few slides. So test doubles are the things that provide this ecosystem to allow us to do efficient unit testing and there are several different kinds. We have dummy objects which fill in dummy values into objects that are required as parameters by the system under test, but are otherwise irrelevant to the test. So we don't want to bother having to create them, especially if they're complicated. Test Stubs are dummy input data sources that are used by the system under test. So maybe I'm interacting with the database, but rather than having a real database. I just create a fake database that for a couple of entries has interesting values the test can use. Fake objects are lightweight implementations of heavyweight processes like databases. So rather than use the external database that's running on a different server, maybe I'll use an in-memory database. And I'll populate it with a small number of entries, and I'll use that as my vehicle for interacting. And finally, we can talk about Mock Objects, so with Mock Objects. What we can do is we are testing our system. It's going to call out to these other systems. And we want to make sure that it's calling out to these other systems in a correct way. And Mock Objects are a way for us to determine whether or not our system is using other systems correctly. And there's a near synonym with Mock Objects called, Spy Objects. So Mock Objects are fake objects that we're constructing just so that we can run the test. A Spy Object is something that we wrap around the real object, so that we can again, monitor these interactions between the system under test and this other object. So if we think about it, the first three kinds of test doubles provide test inputs. They're going to allow us to run our test. And the last kind, the Mock Objects and Spy Objects, allow us to monitor the test in a finer-grained way. And we can do just by looking at the output of a method call, say. And to make it concrete in the next few lessons and in your exercise, we're going to use a tool called Mockito. Mockito is a popular framework for creating test doubles in Java. And it integrates well with JUnit, so that we can quickly and relatively easily construct these Test Stubs and Mock Objects. The goal is to be able to mock away dependencies for the unit tests to other systems that may not be complete or we don't want to use for one reason or another. And also to inspect the interactions between the system under test and Mock Objects, so we can get a fine-grained level of insight into how our system is performing. So just to recap, working with software in context can make it difficult to test. So basically, we have our piece done, but it's going to interact with other systems, even if we're just doing unit testing. And if we can't get to those other systems, we need to be able to fake it, and test doubles are a way of faking it. And Mockito is a concrete framework for faking it in Java. So the thing that we're going to use is something called Mockito. And Mockito, which is available at this website, site.mackito.org, is a mocking framework that's specifically constructed for creating unit tests in Java. And 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. And 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. And we're running in Eclipse, so much like you've seen Kevin run Eclipse in previous exercises, 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. If we do that, we find this thing called Buildship Gradle Integration 2.0. And 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 we that we want to create a Gradle project, and so that's what I've done in the example that you see here. And 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. Click Next. And I'll say "Example" and Finish. And 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. And 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 and so if we look at this new example thing, if we look at the Gradle file here. There's a dependency section, and already we're using JUnit. And 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.
