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
Limitation of ActivityScenario's Launch Method #143
Comments
…med in ActivityScenario. Update moveToState javadoc for the corresponding behavior changes. (Fixes #143) PiperOrigin-RevId: 224897301
Thanks for reporting the issue with the detailed explanation. This behavior was by design because moveToState method doesn't work otherwise. However, given the example you explained there are valid use cases certainly. I updated launch method to accept any of steady states and moveToState's javadoc by my latest commit. |
Thank you @yuuki3655 ! This will be very helpful. |
This appears to still be an issue in It seems the build/test logs for this repository are not public. Is the |
Can this issue be reopened? I am still able to reproduce it with Edit: If you need a live example of the reproductibility, here is the repository. The tests pass on the branch The relevant test class is Strangely, this does not reproduce througout all the tests. For instance, |
It also happens with 1.4.0 |
yes, also same problem here with 1.4.0 |
…med in ActivityScenario. Update moveToState javadoc for the corresponding behavior changes. (Fixes android/android-test#143) PiperOrigin-RevId: 224915071
I have run into this same issue when updating AGP to 7.2.0 |
- Comment out tests that are failing due to AGP 7.2.0 issue: android/android-test#143 - Fix application id - Add a unit test which turns a partially covered line (yellow) to fully covered (green) Need to run: ./gradlew createDebugCoverageReport
Why waitForActivityToBecomeAnyOf is private? it could be useful in tests |
I had the same problem here, using the AGP 8.2.1... |
Description
As referenced in my original AndroidX Discuss Post and my Stack Overflow post and this new stack overflow post about FragmentScenario, there seems to be a limitation of the ActivityScenario API when using
ActivityScenario.launch()
method because it only waits for two possibleLifecycle.State
sRESUMED
andDESTROYED
.Claim:
There is a limitation within the
launch(Intent startActivityIntent)
method of the ActivityScenario API. It waits for the Activity to beLifecycle.STATE.RESUMED
orDESTROYED
and if it isn't within 4.5 seconds then it throws this error.Context:
My application uses an
IndexActivity
to load a config which instructs the application on certain API calls to make. However, immediately after it loads aDialogActivity
and theIndexActivity
goes intoSTOPPED
. On accepting terms within theDialogActivity
theIndexActivity
goes back intoRESUMED
and then ActivityScenario works properly. With my tests, there was a race condition on whether Espresso could click through the terms within 4.5 seconds to get theIndexActivity
to beRESUMED
or whether this error would throw before that. It would take major refactoring to enable another Activity to be launched with ActivityScenario so that was not an option.The Fix
Within
public static <A extends Activity> ActivityScenario<A> launch(Intent startActivityIntent)
of Activity Scenario, check the logicscenario.waitForActivityToBecomeAnyOf(State.RESUMED, State.DESTROYED);
If you can create your own custom Activity Scenario and adjust this line of code to be something like
scenario.waitForActivityToBecomeAnyOf(State.STOPPED, State.DESTROYED);
then it will theoretically work for you. You can then use ActivityScenario again to move the Activity into whatever Lifecycle State you want.OR just use the old https://developer.android.com/reference/androidx/test/rule/ActivityTestRule
TL;DR
This is happening because the Lifecycle.State of your Activity is not either of the two specific lifecycle states
ActivityScenario.Launch()
waits for,RESUMED
orDESTROYED
. Your activity is probably in the background of a dialog or another edge-case situation that was not thought about when creating the API.Full StackTrace for Test here:
Steps to Reproduce
RESUMED
state, due to pop-up modal or dialogExpected Results
It seems this is not a bug but is rather a restriction of the API
But, the expected behavior would be to either allow
STOPPED
to be waited for within the launch() method, or to allow the user to specify which states they want to wait for.Actual Results
ActivityScenario wants your activity to be either
RESUMED
orDESTROYED
, and if it isn't after 45000 milliseconds then it throws the error above.AndroidX Test and Android OS Versions
Link to a public git repo demonstrating the problem:
None right now.
The text was updated successfully, but these errors were encountered: