-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception when running instrumented tests with Hilt and App Startup #3356
Comments
Hi @ampeixoto, you'll want to use |
Thanks for your reply @bcorso. I just tried
Any suggestion? |
Sounds similar to #2016 (comment)? Does the advice there help? |
@bcorso it looks similar indeed, but there is a difference, they are trying to run the test using Robolectric. I am trying to run it on the device. On top of that, I already have the
My situation is very similar with this one #2016 (comment), with the usage of app-startup. |
It looks like the issue is that Androidx I think we could likely fix this by passing in the application manually here: https://github.com/google/dagger/blob/master/java/dagger/hilt/android/EarlyEntryPoints.java#L61 rather than trying to get the application instance via I'll test this out and report back. |
Hi @bcorso , any news on this? |
We have a workaround that should fix this particular issue. I plan on doing a release this week, so I'll try to get the commit into that release. We've also filed https://issuetracker.google.com/230844558 for the |
…ponent. This fixes cases where we need to create the component before `Application#attachBaseContext()` is called. For example. this seems to be the case for Androidx's startup library. Fixes #3356 RELNOTES=N/A PiperOrigin-RevId: 445182248
…ponent. This fixes cases where we need to create the component before `Application#attachBaseContext()` is called. For example. this seems to be the case for Androidx's startup library. Fixes #3356 RELNOTES=N/A PiperOrigin-RevId: 445182248
Hi @bcorso sorry for the late reply, but only now I got some time to go back to this. Could you clarify which workaround you are talking about? Are you talking about passing the application manually here as you suggested? Did this ended up in a new version? It doesn't look like. From what I read on the ticket open for the app startup library, it seems they wont do anything on their side... I find it hard to believe that no one else faced this issue as it is a basic setup with hilt, app-startup and instrumentation tests... |
The workaround is in d14a3d6, which was released in 2.42. Please update this post with a stacktrace or any new/additional information if you're still having issues after upgrading, thanks! |
@bcorso thanks for the clarification! When updating hilt to 2.42, I start getting the following compile time error:
Any idea? |
It sounds like it may be an issue with skewed versions. In particular, I would guess that maybe you've updated the API artifact ( |
I update both:
Do you spot any issue? (btw, what is the difference between the artifact Update |
Hmm, the method it's complaining about should be written here: If possible, can you post the the generated java source for the generated
It may also be worth double checking your dependencies to ensure you're getting 2.42
They are exactly the same. At some point we may remove |
@bcorso thanks for the info! Here is the content of the
Regarding the dependencies, it looks like it is using v2.42:
|
Hmm, that's weird, it's definitely generating the old implementation for some reason. If you have a sample project I can take a look. |
The version here needs to be upgraded to 2.42. |
@bcorso You are totally right! Completely forgot about it. I usually have the versions centralized, but for this sample project, I didn't... Thanks for the solution! Now the original issue is solved :) Now I'm facing another (unrelated issue) in my main project related to the ViewModels instantiation using Hilt:
The strange thing is that, when running the app, the ViewModel is properly instantiated. This only happens in instrumentation tests that run on the device. I know this is not related with the original issue, but if you have any suggestions for me to look into... It seems to me that I am missing some |
Ok, found the issue in my instrumentation test. I will let here my solution as I believe it might help others. Some context: I am using compose for the UI. Basically, the main problem was that I was using After I started using @RunWith(AndroidJUnit4::class)
@HiltAndroidTest
class MyScreenTest {
val hiltRule = HiltAndroidRule(this)
val composeTestRule = createAndroidComposeRule<MyActivity>()
@get:Rule
val rule: RuleChain = RuleChain.outerRule(hiltRule)
.around(composeTestRule)
// Tests....
} ( |
Caused by some ops in core's newly added initializers to happen before the DI componenet was setup. Based on google/dagger#3356 this issue is fixed in dagger / hilt 2.42. Such upgrade doesn't apply cleanly here, which lead to this workaround of removing the offending core initializers in the manifest to instead invoke them manually, so that they won't be initialized when runnign tests (as they use `HiltTestApplication` instead of `ProtonApplication`)
Hello,
I am starting to setup some instrumented tests on my project, but when I run them, I get the following exception on logcat:
My real codebase is much more complex, but I created a much simpler project where I am able to reproduce the issue HERE.
From what I understood, when running the instrumentation tests, the startup code is first executed, even before anything on the test class (Before and BeforeClass annotated methods).
What is the best way to handle this? Is this something that was already detected?
The text was updated successfully, but these errors were encountered: