Test-Driven Development in Android

Download the starter project attached to this episode and wait until gradle finishes synching your project. Then run your app.

You’ll see that there is no UI just yet because thats what we are going to be building with our UI tests. Remember that this is Test Driven Development so we’ll create the tests for the UI and then we’ll create the UI.

So dont worry about this, close the app and since espresso is wo widely used we dont need to add the dependencies to our project. Every time a new project is created espresso dependencies are already added to the module dependencies.

So, if you open the project panel and open the build.gradle file you’ll see that in our testing dependencies espresso is alrady here. So, thats totally ok we dont need to add anything.

And we’ll beworking on creating our new tests so we’ll need to create the test class. Switch back to the project view. Inside the app package, under source, click on new directory, androidTest. Here new directory, java, and in here new package structure com.ranweyderlich.androidpunchline.

And inside our new package create a new test class MainActivityTest.

And we’ll make our MainActivityTest inherint from KoinTest. And since this is a test make it run with AndroidJUnit4::class

You should be familiar with AndroidJUnit4 already and you inherit from KointTest because this project uses the Koin dependency injection framework.

Dont worry if you havent used Koin before you just need to know that it is a dependency injection framrwork and it gives us a lot of power to inject dependencies to our tests.

And basically, not just for tests but all of our class in android projects.

So, where are we using KoinTest for dependency injection in this episodes, well in previous chapters we only needed to use mockit mocks to create our mocks and test our different functionalities. For example, when we didnt want to hit the network layer. In many of these cases we can introduce the mocked classes to our real objects by passing them through the constructor. But how would we do that for an activity we dont have access to the source code so we cannot just pass anything to hte constructor we dont have the same luxury beause the android framework instantiates the class for us so this is where dependency injection is helpful when it comes to testing. In this test you can mock the repository so you are not hitting the network layer. This helps with the speed and stability.

In your Koinmodules.kt right here. KoinModules.kt. A retrofit service is defined which we need to overrride. We’ll use a koin test rule for that. Inside our class type:

@get:Rule
val mockProvider = MockProviderRule.create { clazz ->
  Mockito.mock(clazz.java)
}

Why is it giving an error? Oh class is a reserved keyboard: class. That’ll work fine. so the error dissappears.

By using declare mock you are overriding the provided dependency injection repository with a mockito mock. Then we’ll need a reference to this repository so you can stub methods into it later. luckily Koin can do that for us.

private val mockRepository: Repository by inject()

Here by delagating the property instantiation to inject this sets the mock repository to the mock that koin passes to the viewmodel in the activity.

So, one last thing to set up before writing any tests, we’ll use the faker library that we learned in the previous section.

Create another property for faker:

private var faker = Faker()

Great, we are ready to start creating our tests. Amazing!