Hilt: Supporting module uninstallation across all tests

From https://developer.android.com/training/dependency-injection/hilt-testing:

This only replaces the binding for a single test class. If you want to replace the binding for all test classes, put the test binding in the test module for Robolectric tests, or in the androidTest module for instrumented tests.

This is in reference to providing modules within a test class vs at the top level. Moving it at the top level works, but it seems like every test is still required to annotate production modules to be uninstalled. The annotation is ignored if we try to use it in an abstract super class for all tests.

What is the approach here? Should we try to also add a hilt rule in the super class? Is there a workaround to avoid uninstalling the same module across all tests?

[Chang-Eric]

Closing this as the above commit should fix this issue.

[krgauthi]

@bcorso This could be a lengthy explanation, I might need to make an example.

Can you describe where your test vs test application live? Are you talking about a case where the test application is in a separate Gradle module from the test?

I’ve got two Gradle modules one for each app, I’ve got a third gradle module with a shared feature from both apps that’s a dependency for each app. I’ve currently got my Espresso tests in that feature gradle module. With Dagger I had two AppComponents for each app (4 total), one for normal builds the other for integration tests. The difference between the components was just one dagger module one had real implementations the other had stubbed implementations for the integration tests.

My issue with adding @UninstallModules to the test in the feature gradle module is that I’d be referring to a dagger module in one / both of the app gradle modules - which I don’t want the feature to have a dependency on. In a multi-module app a lot of the implementation decisions happen at that application layer, dagger could accommodate and I don’t think Hilt is currently - I’m still investigating though.

I think that this is a similar issue