Annyce Davis

Davis Technology Consulting

Realm Migrations Supercharged with Dagger

by

My current tech obsessions are: Realm, Dagger and Unit Testing. Therefore, I’m always looking for opportunities to improve my code in some way that involves one or more of the above. That being said, I realized that the recommended way of handling migrations in Realm could be improved significantly by means of Dagger 2.

We’re going to be refactoring the following Migration class:


With only two version updates, we already have a decent sized method to deal with. What’s more if you didn’t start out by creating tests for your migrations, once this method gets much longer you probably never will. But all is not lost, Dagger’s Multibinding Support is coming to the rescue. Let’s take a look!Continue Reading

Testing Tricks #4 – Improving Readability

by

Readability is one of the key components to creating high quality unit and integration tests. Yet, we may hinder the readability of our tests by bogging them down with needless information. Let’s take a look at an example.

Example


Here we have a simple test that is desiring to make sure the URL we used to create the Video object matches the result of calling the playCurrentVideo method in the VideoPlaybackService class. We have created a helper method that allows us to pass in the variables for the Video object creation. However, in most cases we don’t need to have all of the parameters set. In fact, the duration and displayDate have no impact on the current method under test. So we’ve added additional, needless information to the test that makes it more difficult to understand what’s going on.

Solution


We can fix this issue by updating the Video class to adhere more closely to the Builder Pattern so that the additional setting of fields is not needed. Here is the current setter used for the video’s URL.


We can update it to pass back the Video object (this) instead of just being void. Let’s see how this will help to make the test more readable and understandable.

With Builder Pattern


The end result is something much more readable and maintainable. Happy testing!

Testing Tricks #3: Third Party APIs

by



When you’re writing unit tests for your Android applications, you will often need to handle interactions with third party APIs. In the above image we’re using the Picasso Image Loading library in our classes. Picasso has a very clean API, so it’s relatively simple to work with; but with other libraries you may not be so fortunate. So what can we do to simplify our interactions with those APIs and also set ourselves up for more maintainable code in the future?

We can encapsulate the calls to Picasso (or whatever API) into another class that allows us to control the API and make assertions against it in our tests. So here’s an example:

Initial Code

// MyClass class

public void loadImageFromUrl(String imageUrl) {
    presenter.setCurrentPreviewImageUrl(imageUrl);
    if (showThumbImage) {
        Picasso.with(context)
               .load(imageUrl)
               .into(thumbImageView);
    }
}

So in this method, loadImageFromUrl, we want to make sure that our Presenter is being called and that when the showThumbImage variable is set to true, we call the method to load the image. We want to do this of course, without actually loading the image since we’re attempting to verify this behavior inside of a unit test.

For our use case we will need two new classes: ImageLoader and ImageLoaderImpl. The first will be an interface that we will use to expose the desired API, and the second will be a class that implements that interface and wraps the calls to the third party API.

Updated Code

// ImageLoader interface

public interface ImageLoader {

    void loadImage(String imageUrl, ImageView imageView);

}

// ImageLoaderImpl class

public class ImageLoaderImpl implements ImageLoader {
  
    // fields omitted

    @Override
    public void loadImage(String imageUrl, ImageView imageView) {
        Picasso.with(context).load(imageUrl).into(imageView);
    }
}

// loadImageFromUrl method

public void loadImageFromUrl(String imageUrl) {
    presenter.setCurrentPreviewImageUrl(imageUrl);
    if (showThumbImage) {
        imageLoader.loadImage(imageUrl, thumbImageView);
    }
}

Unit Test

// MyClass

@Mock private ImageLoader imageLoader;

@Test
public void shouldLoadImageWhenShowThumbIsTrue() throws Exception {
    myClass.setShowThumbImage(true);

    myClass.loadImageFromUrl("http://www.myimageurl.png");

    verify(imageLoader).loadImage(anyString(),
                                  any(ImageView.class));
}

@Test
public void shouldNotLoadImageWhenShowThumbIsFalse() throws Exception {
    myClass.setShowThumbImage(false);

    myClass.loadImageFromUrl("http://www.myimageurl.png");

    verifyZeroInteractions(imageLoader);
}
 
So in these two unit tests we are able to successfully verify the interactions with our Image Loader and we don’t have to be concerned with what’s going on inside our third party API. What’s more, if we decide in the future that we would like to use another Image Loading library, we’ve encapsulated those changes in one place!


How do you like to unit test third party APIs? Please leave a comment below.

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!

Follow Me