QA thread

This post is about setting up android emulator for UI test automation. Properly configured emulator is the basis for reliable tests. Hundreds or thousands of professionally written test cases is great but if they become flaky because of the environment they are running on, their value reduces a lot. I will give you a couple of advices I'm following in my test automation projects. In general we will go through below topics: Managing emulator system animations Controlling soft keyboard appearance Changing emulator system locale Tweaking first and second points will reduce to minimum flakiness in our automated tests which can be caused by emulator. For those who are lazy to read the whole article at the bottom of the post I shared youtube video where I describe the same points with one more additional hint on top :) 1. There are three types of system animation we may control: window animation scale transition animation scale animator duration scale Emulator ...

Recently I had a need to adapt my Espresso tests to operate on RecyclerView after migration from ListViews. The current actions that are available for RecyclerView based on item position working fine but I don't like to be dependent on position since data in my tests is created dynamically. I've googled the ViewHolder matchers and found only this link without any practical examples -  RecyclerViewActions . Then based on already created Matcher<Object> used in onData(...) I've created Matcher<VH> which was not so difficult. Let's assume each item in RecyclerView adapter has subject, represented by TextView. The below matcher will search for item in RecylerView with unique subject which I provide into matcher. Feel free to use it: public static Matcher<RecyclerView.ViewHolder> withItemSubjectInViewHolder(final String itemSubject) { Checks.checkNotNull(itemSubject); return new BoundedMatcher (RecyclerView.ViewHolder, MyListRecyclerViewIt...

This time I would like to share with you solution for 'Class ref in pre-verified class resolved to unexpected implementation' issue I got while I was testing my multi-module project. Espresso tests were failing with below issue when I wanted to operate on RecyclerView from com.android.support:appcompat-v7. In my case RecyclerView dependency was defined not in the core-app module (the core module of the app) but in the other one which is set as a library. java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation at com.my.app.fragments.MyFragment.onCreateView(MyFragment.java:190) at android.support.v4.app.Fragment.performCreateView(Fragment.java:1786) at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:947) at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1126) at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:739) at android.support.v4.app.FragmentManagerImpl....

Currently I'm moving all my tests to Espresso 2.0 and Junit4. And today I was struggling with one nasty issue that you can face with as well and found the solution. So, the problem was noticed on pre-Lollipop devices/emulators. My app under test is configured to target the current latest API level 21. And after adapting some tests to Espresso 2.0 and JUnit4 I was able to successfully run it on emulator with Lollipop but trying to run it on devices/emulators lower then API 21 was failing with below issue: java.lang.NoClassDefFoundError: com.my.app.activities.MyActivity at com.my.app.test.instrumentation.TestMyActivity. (MyActivity.java:52) at java.lang.reflect.Constructor.constructNative(Native Method) at java.lang.reflect.Constructor.newInstance(Constructor.java:417) . . . And solution is to add below peace of code into your build.gradle: configurations { androidTestCompile.exclude group: 'com.android.support', module: 'support-v4' } :)

Hi, after a long pause I’d like to post an example how to use Espresso’s CountingIdlingResource using lazy getter and setter pattern. So, at first, what is the  CountingIdlingResource ? CountingIdlingResource - an implementation of IdlingResource that determines idleness by maintaining an internal counter. When the counter is 0 - it is considered to be idle, when it is non-zero it is not idle. This is very similar to the way a java.util.concurrent.Semaphore behaves.  The counter may be incremented or decremented from any thread. If it reaches an illogical state (like counter less than zero) it will throw an IllegalStateException. This class can then be used to wrap up operations that while in progress should block tests from accessing the UI. At second, why do I need it? Espresso developers claim that using their test framework you can “Leave your waits, syncs, sleeps, and polls behind and let Espresso gracefully manipulate and assert on the application UI when it ...

Just a small post from my recent experience - how to test that AlarmManager has an alarm set. The first approach is to do it programmatically - let's assume we registered our alarm as below: Intent intent = new Intent("com.my.package.MY_UNIQUE_ACTION"); PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT); Calendar calendar = Calendar.getInstance(); calendar.setTimeInMillis(System.currentTimeMillis()); calendar.add(Calendar.MINUTE, 1); AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE); alarmManager.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(), 1000 * 60, pendingIntent);  And now to check that registered above alarm is active we have to do the following: boolean alarmUp = (PendingIntent.getBroadcast(context, 0, new Intent("com.my.package.MY_UNIQUE_ACTION"), PendingIntent.FLAG_NO_...