Chapters
Chapters

Chapters

Hide chapters

Dagger by Tutorials

First Edition · Android 11 · Kotlin 1.4 · AS 4.1

Before You Begin

Section 0: 4 chapters
Show chapters Hide chapters

Section I: DI Fundamentals

Section 1: 5 chapters
Show chapters Hide chapters

Section II: Introducing Dagger

Section 2: 4 chapters
Show chapters Hide chapters

Section III: Components & Scope Management

Section 3: 3 chapters
Show chapters Hide chapters

Section IV: Advanced Dagger

Section 4: 3 chapters
Show chapters Hide chapters

Section V: Introducing Hilt

Section 5: 5 chapters
Show chapters Hide chapters

Section VI: Appendices

Section 6: 2 chapters
Show chapters Hide chapters

19. Testing With Hilt
Written by Massimo Carli

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In Chapter 17, “Hilt — Dagger Made Easy”, you learned that one of Hilt’s main goals is to make testing easier. In the first chapter, you also learned that simplifying testing is also one of the main reasons to use dependency injection.

Using constructor injection, you can create instances of classes to test, then pass mocks or fakes directly to them as their primary constructor parameters. So where does Hilt come in? How does it make tests easier to implement and run?

To understand this, think about what Dagger and Hilt actually are. Dagger gives you a declarative way to define the dependency graph for a given app. Using @Modules and @Components, you define which objects to create, what their lifecycles are and how they depend upon one other.

Hilt makes things easier with a predefined set of @Components and @Scopes. In particular, using @HiltAndroidApp, you define the main @EntryPoint for the app bound to the Application lifecycle. You do the same with ActivityComponent, ServiceComponent and others you met in the previous chapters. In general, you define a dependency graph containing the instances of classes you inject.

Here’s the point. The objects you use when you run a test are, in most cases, not the same objects you use when running the app. The dependency graph isn’t the same.

Hilt gives you an easy way to decide which objects are in the dependency graph for the app and which objects are there for the tests.

In this chapter, you’ll learn how Hilt helps you implement tests for your app. In particular, you’ll see how to use Hilt to run:

  • Robolectric UI tests
  • Instrumentation tests

Hilt only supports Robolectric tests and instrumentation tests because with constructor injection, it’s easy to implement unit tests without Dagger. You’ll see how shortly.

To learn how to implement tests with Hilt, you’ll work on the RandomFunNumber app. This simple app lets you push a button to get a random number and some interesting facts about that number. It’s also perfect for learning about testing with Hilt.

Note: As you know, Hilt is still in alpha version and so are its testing libraries. During this chapter, you’ll implement some configuration caveats that need to be there to make the tests run successfully. Some of these solve bugs in the library that might be resolved by the time you read this chapter.

The RandomFunNumber app

In this chapter, you’ll implement tests for RandomFunNumber. To start, use Android Studio to open the RandomFunNumber project from the starter folder in this chapter’s materials. When you open the project, you’ll see the structure in Figure 19.1:

Figure 19.1 — Initial Project Structure
Figure 19.1 — Initial Project Structure

As you can see, this app uses some of the modules you already used in the previous chapters.

Build and run to see the screen in Figure 19.2:

Figure 19.2 — Initial Empty Screen
Figure 19.2 — Initial Empty Screen

Click the RANDOM NUMBER button and you’ll see a screen like in Figure 19.3:

Figure 19.3 — A possible result
Figure 19.3 — A possible result

The output in your case is probably different because, when you press the button, you generate a random value and send a request to numbersapi.com to get some useful information about it. Every time you click the button, you’ll get a different number and a different description.

This is a very simple app that contains everything you need to learn how to write tests using the tools and API Hilt provides. Before doing that, however, you’ll learn about RandomFunNumber’s:

  • Architecture
  • Hilt configuration

After you understand how the app works, you’ll start writing tests.

RandomFunNumber’s architecture

The class diagram in Figure 19.4 gives you a high-level description of RandomFunNumber’s main components:

Yobewa 03.9 — MabqiyZoqJihber tcihx kaejrop
Roxidi 07.0 — DufxoyYesXacdib zfijh yiepcen

The Hilt configuration

RandomFunNumber only contains a few components. It has a relatively simple Hilt configuration, which you can see in the diagram in Figure 19.5:

Bibelu 75.4 — KifyazXamSuklut rewusfivrb guerpar
Zapuza 55.4 — MeqdibQesRotliy cevatnecsj neapmex

Implementing RandomFunNumber’s tests

You have the background you need to use RandomFunNumber to practice implementing tests with the utilities Hilt provides. In the following paragraphs, you’ll learn how to:

Defining the project structure for testing

Use Android Studio to open the starter project from the materials for this chapter. Next, select Project View and look at the build types for the app module in Figure 19.6:

Xuquqi 80.2 — Ubd vaxaxu rieqk ztxaq
Tijaru 76.2 — Asj kabebo moovx dshah

Hovoxo 52.4 — Lfiwlux wvikev tuhliak qepnz
Losapo 67.3 — Ysifqes gqizoy ledleic cogzk

Implementing unit tests with constructor injection

As you learned in the previous chapters of this book, constructor injection makes tests easier to write because you simply create an instance of the object to test and pass some fakes or stubs to it as parameters of its primary constructor.

Liwika 45.4 — Gjiena a dulf yav LofPexdoqJueyJuxif
Giwute 52.5 — Pgaafe a zacf xaf KuzNevpopYuaqNidoh

Cuwudo 01.7 — Qefolb vxe JOxam 5 oygoin
Toreno 08.5 — Xuleml rca HEfaj 7 afjuen

Qisohi 47.54 — Voporf vne xomz ciubvotj vhdi
Poroxo 61.09 — Roratq jfi rewk ciayyilz ncde

Pehoso 24.64 — Vav PerCijloyHiabXabolWagw
Xoxuze 36.79 — Pih GukYigqoyZoimYubedCabw

Yawiji 48.03 — FixJebwaqGounGijofKong limjodd
Gokexe 75.69 — BozBozfajGeitYavuyTegf detsodn

Using Robolectric & Hilt for UI tests

Robolectric (http://robolectric.org/) is a testing framework that lets you implement and run tests that depend on the Android environment without an actual implementation of the Android platform. This allows you to run UI tests on the JVM without creating instances of the Android emulator. In this way, tests run quickly and require fewer resources.

Installing the Hilt testing library for Robolectric

For your first step, you need to add the dependencies for Robolectric’s Hilt testing library. Open build.gradle from app and add the following definition:

Creating a MainActivity test with Robolectric & Hilt

Your first test will cover MainActivity. Open MainActivity.kt in the ui package of the app module and you’ll see:

Testing MainActivity with Robolectric & Hilt

In the previous section, you created an empty test to verify the Hilt configuration for Robolectric. Now, it’s time to create the actual test.

Configuring ActivityScenario

ActivityScenario is part of an API Google provides for testing Activitys. To use this, you need to add the following code to RoboMainActivityTest.kt, which you created earlier:

Replacing the real Navigator with a fake

Now, you’ll replace the actual Navigator implementation with a fake one. To achieve this, add the following code:

Reviewing your achievements

Great! You implemented your first test using Hilt and Robolectric. You also learned that you can:

Implementing instrumented tests with Hilt & Espresso

In the previous section, you used Robolectric and Hilt to implement a UI test for MainActivity. Now, you’ll try another option for testing with Hilt — running an instrumentation test with Espresso.

Adding Hilt testing dependencies

To use the Hilt testing library in the instrumentation tests, you need to add the following definition to build.gradle in app:

Creating an Activity for testing

First, you need to create an empty Activity that uses @AndroidEntryPoint. Start by creating a folder for the debug build type at the same level as the existing ones. Create a java folder in it and add a package named com.raywenderlich.android.randomfunnumber. In that package, create a new file named HiltActivityForTest.kt and add the following code:

Kefela 52.86 — Sozoy teoww qzsi qblusqijo
Voredi 83.41 — Puter peebj ggju rrcagwudi

Implementing a utility to launch the Fragment

As mentioned earlier, you need a way to launch a Fragment using the HiltActivityForTest you implemented as its container.

Implementing a custom AndroidJUnitRunner

As you learned when testing with Robolectric, you need to specify the TestRunner for your tests. To do this, you just need to create a custom TestRunner implementation.

Implementing FunNumberFragment’s test

You now have everything you need to implement the test for FunNumberFragment. Following the process in Figure 19.8-10, create FunNumberFragmentTest.kt in the androidTest build type and add the following code:

Replacing an entire @Module

In the previous example, you only replaced some of the bindings you installed as part of a @Module. For instance, in RoboMainActivityTest, you uninstalled ActivityModule, but you added a binding for Navigator.

Key points

  • Hilt provides a testing library for Robolectric and instrumented tests.
  • You don’t need Dagger to implement unit tests if you use constructor injection.
  • Hilt allows you to replace parts of the app’s dependency graph for testing purposes.
  • Using @HiltAndroidTest, you ask Hilt to generate a dependency graph to use during the execution of a test.
  • You can remove bindings from the dependency graph using @UninstallModules and replace some of them using @BindValue.
  • You can replace all the bindings for a @Module by uninstalling it with @UninstallModules and installing a new @Module.
18. Hilt & Architecture Components
C. Conclusion
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now