Dagger in Multi-Module Clean Applications

In this tutorial, you’ll learn how to integrate Dagger in an Android multi-module project built using the clean architecture paradigm. By Pablo L. Sordo Martinez.

Leave a rating/review
Download materials
Save for later
Share
You are currently viewing page 4 of 4 of this article. Click here to view the first page.

Testing

There’s one minor thing you have to do to complete this tutorial: Fix the tests that were failing at the beginning.

There are three test files in the project, one per module: MainPresenterTest, FetchNumberFactUcTest and NumberDataRepositoryTest. All of them comprise unit tests of certain functionalities.

Note: If you’re interested in refreshing what you know about unit tests in Android, check out Android Unit Testing with Mockito.

Testing the Presenter

If you open MainPresenterTest.kt and run the tests, you’ll see one is failing. Scroll down and you’ll find a // TODO: which tells you what the problem is: The use case variable isn’t accessible. But after the changes you made in this tutorial, this should no longer be a problem. Go to the @Before section and replace the mainPresenter initialization with this one:

mainPresenter = MainPresenter(view = mockView, fetchNumberFactUc = mockUsecase)

That’s all! Now, since the presenter receives all the dependencies in the constructor, you can mock anything you want. Note that you haven’t even initialized Dagger whatsoever.

Now that you’ve fixed the main presenter tests, it’s time to fix up the FetchNumberFactUcTest you looked at earlier.

Testing the Use Case

To fix the use case test that was failing — FetchNumberFactUcTest — you only need to make a few changes. First, you’ll see there’s an error when instantiating the use case in the @Before section. Change it to the following:

usecase = FetchNumberFactUc(numberDataRepository = mockRepository)

After that, scroll down to the failing test and stub the repository so that it returns a known value that can be assessed. Place the following below rightParams, in the // given subsection:

whenever(mockRepository.fetchNumberFact(request = rightParams)).doReturn(NumberFactResponse("None").right())

Easy peasy, isn’t it? Now you can run the tests and you’ll see them all pass. This means that the use case is doing what you expect, i.e. validating your logic.

Testing the Repository

Open NumberDataRepositoryTest.kt and run the tests. As you can see, all of them pass. :] You might have not seen it when you started the tutorial, but this file contained two errors (lines 36 and 53). The problem occurred when trying to initialize the repository and passing a value for numberFactDataSource, which was immutable at that time. The changes you made solved these issues.

Where to Go From Here?

You can download the final version of the project using the Download Materials button at the top or bottom of the tutorial.

There are several good references for the main topics addressed in this article:

  • In addition to the links further up, this Clean Architecture Tutorial for Android: Getting Started tutorial is a great primer to this topic.
  • When it comes to dependency injection using Dagger, don’t hesitate to look at the official site. It’s updated often.
  • Implementing multi-module apps isn’t a paradigm, but it’s a good practice if you want a proper separation of concerns. You can read this article for more about it, and don’t forget to look at dynamic features if you feel brave. :]

Recently, Android added Dagger to the official documentation, so there are a good number of references.

Perhaps the best thing you can do after reading this article and completing the exercise is to migrate one of your own projects. In doing so, you’ll see which difficulties and challenges may arise in a real application. Have a look at the tips provided and use them to make your apps more flexible and reusable.

We hope you enjoyed this tutorial. If you have any questions or comments, please join the forum discussion below!