{"id":1400,"date":"2021-12-01T12:14:07","date_gmt":"2021-12-01T11:14:07","guid":{"rendered":"https:\/\/www.thomaskeller.biz\/blog\/?p=1400"},"modified":"2021-12-02T16:39:07","modified_gmt":"2021-12-02T15:39:07","slug":"dagger-hilt-learnings","status":"publish","type":"post","link":"https:\/\/www.thomaskeller.biz\/blog\/2021\/12\/01\/dagger-hilt-learnings\/","title":{"rendered":"Dagger Hilt Learnings"},"content":{"rendered":"\n

This is a loose list of learnings I had when I first came in contact with Dagger Hilt<\/a>, especially in regards to testing. So, without further ado, let’s get into it.<\/p>\n\n\n\n

Documentation<\/h2>\n\n\n\n

While the documentation on Dagger Hilt on developer.android.com is already quite exhaustive<\/a>, I figured I missed a couple of important information and gotchas that I only got from the official Hilt documentation<\/a>. So be sure you read through both<\/em> thoroughly.<\/p>\n\n\n\n

Scoping<\/h2>\n\n\n\n

It’s buried a bit in the documentation, but it should be remembered that predefined components won’t mean that all dependencies in the particular component are single instances. Remember that there is a corresponding scope for each and every component type that ensures that there is only one specific<\/em> instance of your thing. This is particularly useful if your thing holds some kind of shared state:<\/p>\n\n\n\n

@Module\n@InstallIn(ActivityRetainedComponent::class)\nobject<\/strong> RetainedModule {\n    @Provides\n    @ActivityRetainedScope\n    fun<\/strong> provideFlow() = \n        MutableStateFlow<@JvmSuppressWildcards SomeState>(SomeState.Empty)\n}<\/code><\/pre>\n\n\n\n
Communication between different Android ViewModel<\/code> instances come into my mind where this is handy.<\/p>\n\n\n\n
Since scoping comes with an overhead, also remember that you can use @Reusable<\/code> in any<\/em> component in case you only want to ensure that there is some<\/em> instance of your otherwise stateless dependency at a time:<\/p>\n\n\n\n
@Module\n@InstallIn(SingletonComponent::class)\nobject<\/strong> SingletonModule {\n    @Provides\n    @Reusable\n    fun<\/strong> provideHttpClient() = OkHttpClient.Builder()...\n}<\/code><\/pre>\n\n\n\n
Dagger Hilt Debugging<\/h2>\n\n\n\n
Dagger Hilt is – under the hood – a beefed up Dagger that comes with a couple of interesting features, like isolated dependency graphs for tests. But after all, it’s still just Dagger and implemented in Java. Which means your usual rules for making Dagger work apply here (@JvmSuppressWildcards<\/code> for the rescue when dealing with generics, etc.), just with an extra level of complexity that hides the usual unreadable errors.<\/p>\n\n\n\n
Since most of my issues resolved around understanding the removal \/ replace of test dependencies, I figured the entry point for Hilt’s generated test sources is build\/generated\/hilt\/component_sources<\/code>. This directory is split into two parts, one that contains the generated test components for your tests, one for each test class, underneath component_sources\/{variant}UnitTest\/dagger\/hilt\/android\/internal\/testing\/root<\/code> and one that collects an injector implementation, again, for each of your tests, residing in component_sources\/{variant}UnitTest\/package\/path\/to\/your\/tests<\/code>.<\/p>\n\n\n\n
The former directory is definitely the more interesting one, because you can check each generated test component if it carries the correct modules you want your test to provide, i.e. you can check if your modules are properly replaced via @TestInstallIn<\/code> or removed via @UninstallModules<\/code>.<\/p>\n\n\n\n
Component Tests have to be Android Tests<\/h2>\n\n\n\n
I like to write blackbox component tests on the JVM for REST or DAO implementations. Sometimes this requires a complex dependency setup (mappers, libraries, parsers, …) where I’d like to use Dagger to create instances of my subject under test.<\/p>\n\n\n\n
Dagger Hilt supports this, kind of, as long as you don’t care that you rewrite your JUnit 5 component test in JUnit 4 (including all Extension<\/code>s you might have written). Reason is that even though your test doesn’t need a single Android Framework dependency, you still need to run it with Robolectric<\/a> because this is the only supported way of using Hilt in JVM tests as of now:<\/p>\n\n\n\n
Even though we have plans in the future for Hilt without Android, right now Android is a requirement so it isn’t possible to run the Hilt Dagger graph without either an instrumentation test or Robolectric.<\/em><\/p>Eric Chang<\/cite><\/blockquote>\n\n\n\n
UI Testing : Activity<\/h2>\n\n\n\n
Using Dagger Hilt for an Activity test is straight forward, you basically follow the documentation:<\/p>\n\n\n\n
@HiltAndroidTest\n@RunWith(RobolectricTestRunner::class)\n@Config(application = HiltTestApplication::class)\ninternal class <\/strong>SomeActivityTest {\n    \n    @get:Rule(order = 0)\n    val<\/strong> hiltRule = HiltAndroidRule(this)\n    \n    @get:Rule(order = 1)\n    val<\/strong> activityScenarioRule = ActivityScenarioRule(SomeActivity::class)\n    \n    @Inject lateinit var<\/strong> dep: SomeDep\n    \n    @Before\n    fun<\/strong> init() {\n        hiltRule.inject()\n    }\n    \n    @Test\n    fun<\/strong> someTest() {\n         \/\/ stub dep\n         ...\n         \/\/ launch\n         activityScenarioRule.launchActivity()\n    }\n}<\/code><\/pre>\n\n\n\n
This works nicely in case your dependency is in Singleton<\/code> scope, because your test instance itself cannot inject anything else but Singleton<\/code>-scoped dependencies, but what if not and we have to stub the aforementioend MutableStateFlow<\/code>?<\/p>\n\n\n\n
Now, Hilt has a concept called EntryPoint<\/code>s that we can define in a test-local manner. The entry point then targets a specific component and can fetch dependencies from that. To find the right component for your entry point it helps looking at the component hiearchy<\/a>. If our dependency lives in the ActivityRetainedComponent<\/code>, its as easy as creating a new entry point into this for our test, right?<\/p>\n\n\n\n
    ...\n    \n    @get:Rule(order = 0)\n    val<\/strong> hiltRule = HiltAndroidRule(this)\n    \n    @EntryPoint\n    @InstallIn(ActivityRetainedComponent::class)\n    internal interface <\/strong>ActivityRetainedEntryPoint {\n       val flow<\/strong>: MutableStateFlow<@JvmSuppressWildcards SomeState>\n    }\n    \n    @Before\n    fun<\/strong> init() {\n        hiltRule<\/strong>.inject()\n    }\n    ...<\/code><\/pre>\n\n\n\n
Wrong. To get an instance of the entry point, you have to call EntryPoints.get(component, ActivityRetainedEntryPoint::class)<\/code>, where the component<\/code> is the instance of the thing the component is owned, i.e. an Application<\/code> instance for SingletonComponent<\/code> entry points, an Activity<\/code> instance for ActivityComponent<\/code> entry points, aso. But what is the thing that owns the ActivityRetainedComponent<\/code> and where to we get access to it?<\/p>\n\n\n\n
Turns out we don’t need it. Looking at the component hiearchy<\/a> again we see that ActivityComponent<\/code>,  FragmentComponent<\/code> and a few others are direct or indirect child components of the ActivityRetainedComponent<\/code> and therefor see all of it’s dependencies. So we “just” need an Activity<\/code> or Fragment<\/code> instance to get our dependency.<\/p>\n\n\n\n
The Hilt docs state<\/a> that the easiest way is to define a custom static activity class in your code, like this<\/p>\n\n\n\n
@AndroidEntryPoint\nclass<\/strong> TestActivity : AppCompatActivity() {\n    val<\/strong> flow: MutableStateFlow<SomeState>\n}<\/code><\/pre>\n\n\n\n
but that Activity needs to go through the lifecycle at first to be usable. Can’t we just use the Activity<\/code> instance we launch anyways for this? Turns out we can, we just need to “extract” the actual Activity<\/code> instance from the ActivityScenario<\/code>:<\/p>\n\n\n\n
fun <\/strong><T : Activity> ActivityScenario<T>.getActivity(): T? {\n    val <\/strong>field = this<\/strong>::class<\/strong>.java<\/em>.getDeclaredField(\"currentActivity\"<\/strong>)\n    field.isAccessible <\/em>= true\n    <\/strong>@Suppress(\"UNCHECKED_CAST\"<\/strong>)\n    return <\/strong>field.get(this<\/strong>) as? <\/strong>T?\n}\n\ninline fun <\/strong><reified <\/strong>E : Any> ActivityScenarioRule<*>.getActivityEntryPoint(): E =\n    EntryPoints.get(\n        getScenario(<\/strong>).getActivity<\/em>() ?: error<\/em>(\"activity not started\"<\/strong>),\n        E::class<\/strong>.java\n    <\/em>)<\/code><\/pre>\n\n\n\n
so our complete test looks like this:<\/p>\n\n\n\n
@HiltAndroidTest\n@RunWith(RobolectricTestRunner::class)\n@Config(application = HiltTestApplication::class)\ninternal<\/strong> class<\/strong> SomeActivityTest {\n    \n    @get:Rule(order = 0)\n    val<\/strong> hiltRule = HiltAndroidRule(this)\n    \n    @get:Rule(order = 1)\n    val <\/strong>activityScenarioRule <\/strong>= ActivityScenarioRule(SomeActivity::class<\/strong>)\n    \n    @EntryPoint\n    @InstallIn(ActivityComponent::class)\n    internal interface <\/strong>EntryPoint {\n       val <\/strong>flow: MutableStateFlow<SomeState>\n    }\n    \n    @Before\n    fun<\/strong> init() {\n        hiltRule<\/strong>.inject()\n    }\n    \n    @Test\n    fun<\/strong> someTest() {\n         \/\/ launch\n         activityScenarioRule<\/strong>.launchActivity()\n         \/\/ get the flow and do things with it\n         val<\/strong> flow = activityScenarioRule<\/strong>.getActivityEntryPoint<EntryPoint>().flow\n    }        \n}<\/code><\/pre>\n\n\n\n
Downside is now, of course, that the Activity<\/code> must be launched (started even!) before one gets access to the dependency. Can we fix that? Unfortunately not without moving the Dependency up the component hierarchy and installing the original module that provided it. See Replacing Ad-hoc Dependencies<\/strong> for a way to do that.<\/p>\n\n\n\n
UI Testing : Fragments<\/h2>\n\n\n\n
The first issue with Hilt-enabled Fragment testing is that there is no support for Hilt-enabled Fragment testing<\/a>. The problem is that the regular androidx.fragment:fragment-testing<\/code> artifact comes with an internal TestActivity<\/code> that is not Hilt-enabled, so we have to write our own:<\/p>\n\n\n\n
@AndroidEntryPoint(AppCompatActivity::class)\nclass<\/strong> TestHiltActivity : Hilt_TestHiltActivity() {\n    override fun <\/strong>onCreate(savedInstanceState: Bundle?) {\n        val themeRes = intent.getIntExtra(THEME_EXTRAS_BUNDLE_KEY, 0)\n        require(themeRes != 0) { \"No theme configured for ${this.javaClass}\" }\n        setTheme(themeRes)\n        super.onCreate(savedInstanceState)\n    }\n\n    companion object <\/strong>{\n        private const val<\/strong> THEME_EXTRAS_BUNDLE_KEY = \"theme-extra-bundle-key\"\n\n        fun<\/strong> createIntent(context: Context, @StyleRes themeResId: Int): Intent {\n            val<\/strong> componentName = ComponentName(context, TestHiltActivity::class.java)\n            return<\/strong> Intent.makeMainActivity(componentName)\n                .putExtra(THEME_EXTRAS_BUNDLE_KEY, themeResId)\n        }\n    }\n}<\/code><\/pre>\n\n\n\n
This is basically copied from the original TestActivity<\/code> and adapted. I place this into a separate Gradle module, because like the original artifact, this has to become a debugImplementation<\/code> dependency.<\/p>\n\n\n\n
Now we need a separate FragmentScenario<\/code> and FragmentScenarioRule<\/code> as well, to use this new Activity. I’ll not paste the complete implementation for them here, but refer you to this gist<\/a> where I collected them.<\/p>\n\n\n\n
With FragmentScenario<\/code> we have more control over the Fragment<\/code>s state in which it is launched. My implementation by default launches a Fragment<\/code> in Lifecycle.State.INITIALIZED<\/code>, basically the state in which the Fragment<\/code> is right after it’s instantiation and – more importantly – after<\/em> Hilt injected its dependencies!<\/p>\n\n\n\n
So, we can now stub dependencies that are used during onCreate<\/code> like so:<\/p>\n\n\n\n
@EntryPoint\n@InstallIn(FragmentComponent::class)\ninternal interface <\/strong>FragmentEntryPoint {\n    val someFlow: MutableStateFlow<SomeState>\n}\n\nprivate val <\/strong>fragmentScenarioRule = HiltFragmentScenarioRule(SomeFragment::class)\nprivate val<\/strong> entryPoint by lazy {\n    fragmentScenarioRule.getFragmentEntryPoint<FragmentEntryPoint>()\n}\n\n...\nval<\/strong> fragmentScenario = fragmentScenarioRule.launchFragment(R.style.AppTheme)\nentryPoint.someFlow.tryEmit(SomeState.SomeValue)               \nfragmentScenario.moveToState(Lifecycle.State.RESUMED)<\/code><\/pre>\n\n\n\n
Replacing Ad-hoc Dependencies<\/h2>\n\n\n\n
There are times where you don’t provision dependencies through specific modules that you could, on the test side of things, replace via @TestInstallIn<\/code> or alike. A good example for this are UseCase<\/code> classes.<\/p>\n\n\n\n
I tend to test my View (Fragment or Activity)  together with my Android ViewModel implementation and the latter makes use of these UseCase<\/code> classes to interface to my domain layer. Naturally one wants to replace the UseCase<\/code> implementation with a fake implementation or a mock, but how can one accomplish this with Hilt?<\/p>\n\n\n\n
Turns out it’s quite easy – all you have to do is to @BindValue<\/code> your dependency in your test class. A dependency provisioned through this seems to take precendence over constructor-injected ad-hoc dependencies:<\/p>\n\n\n\n
@HiltAndroidTest\n@RunWith(RobolectricTestRunner::class)\n@Config(application = HiltTestApplication::class)\ninternal class<\/strong> SomeActivityTest {\n\n    @get:Rule(order = 0)\n    val<\/strong> hiltRule = HiltAndroidRule(this)\n\n    @get:Rule(order = 1)\n    val<\/strong> activityScenarioRule = ActivityScenarioRule(SomeActivity::class)\n\n    @BindValue\n    val<\/strong> useCase: MyUseCase = mockk()\n\n    @Before\n    fun<\/strong> init() {\n        hiltRule.inject()\n    }\n    ...\n}<\/code><\/pre>\n\n\n\n
Lifecycle and Scoping in Tests<\/h2>\n\n\n\n
More often than not you might stumble in weird test issues when you follow the “good citizen” rule and provision even your test dependencies (e.g. mocks) with @Reusable<\/code>. In some cases you might end up with two different instances, one in your test and one in your production code.<\/p>\n\n\n\n
So, spare yourself a few headaches and and just always annotate those test dependencies with the scope matching the component, e.g. @Singleton<\/code>.<\/p>\n\n\n\n
Module Size<\/h2>\n\n\n\n
The ability to uninstall certain modules per test has the nice “side-effect” of training yourself to make your modules smaller, because the larger a module is – and the more unrelated dependencies it provisions, the more work you have to do to provide the “other” dependencies you’re not interested in once you uninstall that module for a particular test case.<\/p>\n\n\n\n
Well, at least Dagger tells you that something is missing, by printing out it’s beloved compilation errors, right?!<\/p>\n\n\n\n
Global Test Modules<\/h2>\n\n\n\n
Sometimes you want to remove some dependency from your graph that would otherwise go havoc during testing, think of a Crashlytics module suddenly sending crash reports on test failures or a Logging module that prints garbage to your stdout. Usually you’d do something like this then:<\/p>\n\n\n\n
@Module\n@TestInstallIn(\n    components = [SingletonComponent::class],\n    replaces = [LoggingModule::class]\n)\ninternal object <\/strong>TestLoggingModule {\n    @Provides\n    @Singleton\n    fun<\/strong> provideLogger(): Logger = Logger { \/* no-op * \/ }\n}<\/code><\/pre>\n\n\n\n
All fine, but what if you now have a single test case where you want to check the log output? Well, you can’t uninstall a module installed via @TestInstallIn<\/code>, but you can do a workaround: Install a module that removes<\/em> the dependency, then add another regular module that adds your no-op implementation:<\/p>\n\n\n\n
@Module\n@TestInstallIn(\n    components = [SingletonComponent::class],\n    replaces = [LoggingModule::class]\n)\ninternal object <\/strong>TestLoggingRemovalModule\n\n@Module\n@InstallIn(SingletonComponent::class)\ninternal object <\/strong>TestLoggingModule {\n    @Provides\n    @Singleton\n    fun<\/strong> provideLogger(): Logger = Logger { \/* no-op * \/ }\n}<\/code><\/pre>\n\n\n\n
Now, in your test you can remove that module and have a custom implementation that you can verify against:<\/p>\n\n\n\n
@HiltAndroidTest\n@RunWith(RobolectricTestRunner::class)\n@UninstallModules(TestLoggingModule::class)\n@Config(application = HiltTestApplication::class)\ninternal class <\/strong>SomeLoggingTest {\n    @BindValue\n    val<\/strong> logger: Logger = MyFakeLogger()\n    ...\n}<\/code><\/pre>\n\n\n\n
Code Coverage<\/h2>\n\n\n\n
If your @AndroidEntryPoint<\/code>s don’t show up in Jacoco’s code coverage reports as covered, even though you have tests for them, follow this excellent post<\/a> and choose whether you want to keep using the Hilt Gradle plugin or not.<\/p>\n\n\n\n
Wrap-up<\/h2>\n\n\n\n
Dagger Hilt makes testing a lot easier; the ability to replace dependencies for each test separately is a real game changer. <\/p>\n\n\n\n
What’s also true is that it is still Dagger, i.e. the configuration is complex, the error messages cryptic at best and – this is new (at least for me) – Hilt compilation issues have occasionally to be fixed by cleaning your module, because there seem to be issues with incremental compilation. Not neccessarily confidence-inspiring, but at least you know how to fix things.<\/p>\n\n\n\n
I hope I could help you out with some my learnings, let me know what you think! <\/p>\n","protected":false},"excerpt":{"rendered":"
This is a loose list of learnings I had when I first came in contact with Dagger Hilt, especially in regards to testing. So, without further ado, let’s get into it. Documentation While the documentation on Dagger Hilt on developer.android.com is already quite exhaustive, I figured I missed a couple of important information and gotchas … Continue reading Dagger Hilt Learnings<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1400","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/posts\/1400","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/comments?post=1400"}],"version-history":[{"count":15,"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/posts\/1400\/revisions"}],"predecessor-version":[{"id":1430,"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/posts\/1400\/revisions\/1430"}],"wp:attachment":[{"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/media?parent=1400"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/categories?post=1400"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thomaskeller.biz\/blog\/wp-json\/wp\/v2\/tags?post=1400"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}