Annyce Davis

Davis Technology Consulting

Testing Tricks #2: Finding UI Views

by

When you’re writing Espresso tests for your Android applications, you will often need to reference the resource id of a particular view in order to make your assertions. Instead of digging through code you can take advantage of the UIAutomatorViewer tool. It’s very simple to use and helps you to visualize the hierarchy of the views in your application. 


Here it is in action:

Espresso Test

@Test
public void clickOnDetailItemShouldDisplayPlayer() {
    onView(withId(R.id.container_list)).check(matches(isDisplayed()));
    onView(withId(R.id.browse_headers))
        .perform(pressKey(KeyEvent.KEYCODE_DPAD_RIGHT));

    onView(allOf(isDescendantOfA(
                     withRecyclerView(R.id.row_content).atPosition(0)),
           withId(R.id.info_field)))
              .perform(pressKey(KeyEvent.KEYCODE_DPAD_CENTER));

    onView(withId(R.id.wapo_player_view))
        .check(matches(isDisplayed()));
}
 
This test is for an AndroidTV application. It makes sure that the D-Pad navigation from the main header to the nested RecyclerView is functioning as expected. All of the ids for the views were found using uiautomatorviewer.


Hope you found this useful, until next time!

Learning RxJava for Android Devs

by

One of my goals this year was to learn RxJava. Similar to my goal of going to the gym, I procrastinated a bit.


However, I have recently been digging deep into RxJava, especially as it’s used in Android applications. Figured I’d share some of the resources I’ve come upon to help others in their reactive journeys.

Resources:

What have you found useful? Share in the comments. Thanks!

Testing Tricks #1: Dealing with “new”

by

As I continue my efforts to get my Android applications under unit and integration tests, I have come across a few tips/tricks to successfully deal with troublesome code. So I decided to start a new blog post series, “Testing Tricks”. I will try to post a new trick each week. So let’s get started…

Problem Code

I wanted to test this code:

public void readDeepLink(String path) {
    new DeepLinkReader().readDeepLink(path);
}
 
Just wanted to make sure the readDeepLink method was being called. The troublesome part is that I didn’t want to create a actual DeepLinkReader because the real readDeepLink method made calls to the network. So what’s the fix?

Solution

Wrap the call to the “new” creation in a separate method. That way I could override the newly created method with a mock. This would avoid creating a real DeepLinkReader object and would allow me to use Mockito to verify the mock’s interactions.

Fixed Code

// in the MainPresenter.java
public void readDeepLink(String path) {
    getDeepLinkReader().readDeepLink(path);
}

DeepLinkReader getDeepLinkReader() {
    return new DeepLinkReader(currentData, events);
}
// in the MainPresenterTest.java
@Mock private DeepLinkReader deepLinkReader;

@Test
public void shouldReadDeepLink() throws Exception {
    MainPresenter mainPresenter = new MainPresenter() {

        DeepLinkReader getDeepLinkReader() {
            return deepLinkReader;
        }
    };

    mainPresenter.readDeepLink("washingtonpost.com");

    verify(deepLinkReader).readDeepLink("washingtonpost.com");
}

Hope you found this useful, until next time!

Talk: Static Code Analysis

by

Studies show that for every 7 to 10 lines of code we write, we introduce one defect. Now often times we can spot these errors before they ever see the light of day, however that is not true in all cases. So what can we use to assist us in leveling the playing field? Well, we can take advantage of Static Code Analysis tools!

Tools

  • Checkstyle
  • Lint
  • PMD
  • FindBugs

Resources

Follow Me