Annyce Davis

Davis Technology Consulting

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: Developing Maintainable Apps

by

Great Android apps only include what’s needed to achieve the goals of the product, not enhance the resume of the developer. What’s more, the more maintainable an application is, the more likely it will have increased user satisfaction and decreased time to market.


So how can you do it?  Keep these four factors in mind:

  1. Choose your 3rd Party Components Wisely
  2. Keep your Code Simple
  3. Use Static Code Analysis Tools
  4. Write Unit Tests

Resources:

Testing Your Apps with AWS Device Farm

by

Recently, I’ve been on a mission to enhance the quality of the tests in the Android applications that I work on.  To that end, I was introduced to the AWS Device Farm, a cloud based app testing platform.

It was very simple to set up and like most AWS products comes with free tier usage. You move through five steps (at most) and then your app will be tested on the devices you choose.  To get an idea of how it works, just follow the screenshots below.

1. Choose Your Application

2. Configure a test

3. Select Devices

Then you are presented with some additional device configuration options (bluetooth, NFC, GPS, etc.). Finally, you have the ability to review and submit your run configuration. Once all of the devices have completed running your tests you can then drill down and view the individual results of each test.

Test Results


If you try it out, leave me your thoughts below.

Updated: Mocking Hibernate Create Criteria in Grails’ Unit Test with GMock

by

Using the GMock Library I have updated my unit tests to mock out the create criteria methods the following way: 

void testSomeFunction() {
    def results = []

    def mockCriteria = mock() {
      list(instanceOf(Closure)).returns(results)
    }

    mock(Book).static.createCriteria().returns(mockCriteria)

    play {
      assertEquals null, bookService.getDefaultBook(null)
    }
  }

You need to add the following to the top of the unit test file with the import statements:

import org.gmock.*
import static org.hamcrest.Matchers.*

@WithGMock

Also add the following to your BuildConfig.groovy:

dependencies {
    test "org.gmock:gmock:0.8.0"
    test "org.hamcrest:hamcrest-all:1.0"
}

I learned this from the following blog post: http://adhockery.blogspot.com/2010/01/using-gmock-to-complement-grails.html

Follow Me

  • Bluesky