Join Chiu-Ki Chan for an in-depth discussion in this video Mockito: Setup, part of Effective Android Testing for Mobile Developers.
- [Narrator] To use Mockito, go to app slash build dot gradle to include it as a dependency. Inside the dependencies block, after line 26, we are going to add another testCompile line. How do you decide testCompile versus androidTestCompile? Remember, in the test folder is where we put jvm tests; and in the androidTest folder is where we put instrumentation tests. TestCompile and androidTestCompile correspond directly to that.
In our case, RecipePresenterTest was created under the folder Test, so we would need to add a testCompile. After line 26, add testCompile, and then org dot mockito colon mockito hyphen core colon two point eight point 47, or whatever is the latest version of Mockito. You can find it out on Maven Central.
After that, click on Sync Now to perform a gradle sync. You can also click OK if there is some error about the indendation. Now that we have the dependency, let's go back to the test. Go to RecipePresenterTest dot java. We will create private fields for RecipeStore, favorites, and RecipeContract dot view. Private RecipeStore, we will call it Store, and then, next line is for the favorites.
Private Favorites favorites. We will also need the view contract. Private RecipeContract dot view, and we'll call it view. Finally, we will be testing the presenter, so we are also going to have a field for that. Private RecipePresenter presenter. Right now, we just have the variable, and we need to instantiate them. To do that, we are going to add a set-up method.
Annotate this method with at before, so that it will always be run before each test method. Then, public void setup. Inside, we will be creating store, favorites, view, and presenter. Store equal Mockito dot mock, and then RecipeStore dot class. What does this mean? This tells Mockito to create an object with the same function signatures as RecipeStore, plus, hooks to specify its behavior when the functions are called.
We will see how that works in the test methods. For now, let's set up the favorites and view in the same way, as well. Favorites equal Mockito dot mock and then Favorites dot class, and also view equal Mockito dot mock and then RecipeContract dot View dot class. Next, we will be instantiating the presenter.
This time, for the presenter, we are not going to use Mockito, because we do not want a stop. Instead, we want to test the actual presenter. To do that, you can do presenter equals newPresenter to create a real presenter, rather than a mock one. In the constructor, we will need a store, a view, and then favorites. These are stops. The reason why we're using stops to create a real object is so that we can test the behavior of the presenter without depending on the fact that store or favorite or view are doing the right thing.
If they are all real objects, when we find a bug, we don't know whether it's from the presenter, or from all these other dependencies. This way, because they are stops, we can specify their behavior exactly when we are testing, and when we have a bug, we know that it's the presenter that is causing trouble. Now that we have set up all these objects, next, we are going to test the RecipeNotFound functionality.
- Why test?
- Local vs. on-device
- Code coverage
- UI testing
- Hermetic environment
- Dependency injection
- Testing with MVP