I'm just getting started with Espresso for testing Android apps, but I'm having some trouble. I have an Activity with a button that replaces a fragment in the usual way:
public void onClick(View v) {
final FragmentTransaction t = getFragmentManager().beginTransaction();
t.setCustomAnimations(R.animator.fragment_slide_in_up, 0);
t.replace(R.id.fragment_container,
LogInFragment.newInstance(), LogInFragment.TAG)
.addToBackStack(LogInFragment.TAG);
t.commit();
}
In my test, I click the button that sends in the new fragment, and then just check that the new fragment is visible.
onView(withId(R.id.login_btn))
.perform(click());
Thread.sleep(500);
onView(withId(R.id.email_input))
.check(matches(isDisplayed()));
If I remove the Thread.sleep()
from the test, the test fails, even if I remove the setCustomAnimations()
from the Activity code.
All animations are turned off on my phone, as per the instructions. My understanding is that Espresso knows about the UI thread status and will wait until everything is ready. But if I do a onView(withId(R.id.widgetOnNewFragment))
it blows up every time. I need to add a Thread.sleep(500)
every time I show a new fragment.
Am I missing something? I think I should not have to add dozens of Thread.sleep() to my test code.
An idling resource represents an asynchronous operation whose results affect subsequent operations in a UI test. By registering idling resources with Espresso, you can validate these asynchronous operations more reliably when testing your app.
While the Espresso framework 'waits' for certain main UI thread activities, animations require the IdlingResource approach (as Honza suggests).
There are good tutorials on this concept, even detailed implementations.
In reality, because animations rarely factor in to functional testing of the UI, most developers disable animations. IMO, this is an anti-pattern because it doesn't map to the real user experience (most people buy a phone and use it with default settings). This is a decision you'll have to make yourself. If you want to include animations as part of your functional requirements, there are ways, but it requires you to reimplement and rewrite your tests.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With