Tag Archives: Tutorial

Testing on Android part 1: Unit testing

Hello fellas! The last article received a lot of positive feedbacks and questions. I noticed that most of the questions was related to tests, specially about unit testing on Android. I admit that testing could be tricky at first. There are too many option and approaches to choose from and one could get lost trying to pick the right one.

In this series we’ll talk about:

  • Different kinds of tests and when to use then
    • Unit tests
    • Integration tests
    The most common frameworks available on Android
    • JUnit4, Robolectric, Espresso, Mockito and Hamcrest Matchers
    How to setup the test environment How to create unit and instrumental tests How to run the tests =&0=&
    dependencies {
        //...
        testCompile 'junit:junit:4.12'
        testCompile 'org.hamcrest:hamcrest-library:1.1'
        testCompile "org.robolectric:robolectric:3.0"
        testCompile 'org.mockito:mockito-core:1.10.19'
    }

    2. Create this folder structure: /src/test/java/ [package-name]

    3. Click on “Build Variants” and in “Test Artifacts” select “Unit Tests

    Selection Unit Tests
    Selecting Unit Tests in Android Studio

    Creating a Test configuration

    1. Click “Edit Configurations…”
    Click on "Edit Configurations"
    Click on “Edit Configurations…”

    2. Click on “+” and select JUnit

     Click on "+" and select JUnit
    Click on “+” and select JUnit

    3. Give it a name and in “Tesk Kind” select “All in Package”

    Give it a nem and In "Test Kind" select "All in Package"
    Give it a nem and In “Test Kind” select “All in Package”

    4. To run Robolectric you need to select “$MODULE_DIR$” in “Working Directory”

    in "Working Directory" select "$MODULE_DIR$"
    To run Robolectric you need to select “$MODULE_DIR$” in “Working Directory”

    Building our Unit Tests

    In our tests we’ll use a app developed using MVP architecture pattern. It consists of a basic note taker with only one Activity working as a passive View, a Presenter working as a middle man and a Model containing all data business logic. We’ll consider that you domains all concepts adopted on the application, so we’ll concentrate only on the tests. Fell free to clone the repository

    Testing the database

    Let’s consider that we just created our SQLiteOpenHelper class. Now we want to test it to see if it is working correctly before proceeding.

    Our test class should be inserted in the test package created earlier.

    @RunWith(RobolectricGradleTestRunner.class)
    // To use Robolectric you'll need to setup some constants.
    // Change it according to your needs.
    @Config(constants = BuildConfig.class, sdk = 21, manifest = "/src/main/AndroidManifest.xml")
    public class DBSchemaTest {
    
        private Context context;
        private DBSchema helper;
    }

    leia mais

Model View Presenter Class Diagram

Model View Presenter (MVP) in Android, Part 2

In the last article we talked about Model View Presenter (MVP) concepts, and its advantages concerning Android development. In the second part of this series we’ll get the hands dirty and implement our own version of MVP, using canonical form without any libraries from outside Android SDK/Java.

We’ll develop a simple code, but it could look a little bit complex, due to the amount of objects involved. Although, once you get the handle of it, you’ll see how this kind of pattern could help you in your projects. If you prefer to learn directly from code reading, you could check out the final project.

Planning Model View Presenter (MVP)

[expand title=”click to visualize MVP main concepts in Android” tag=”h5″]

=&0=&

Implementing Model View Presenter on Android

Without further ado, let’s get to work! We’ll start defining the app operations. In the name of a better organization, we’ll use an “umbrella” class, containing all interfaces responsible to manage the communication between the layers.

Note: Since MVP implementation is complex enough, no function outside the pattern scope will be developed. I suppose that the readers have a more advanced understanding of the Android SDK, therefore such things shouldn’t be a concern.

Interface MainMVP

/*
 * Aggregates all communication operations between MVP pattern layer: 
 * Model, View and Presenter
 */
public interface MainMVP {

    /**
     * View mandatory methods. Available to Presenter
     *      Presenter -> View
     */
    interface RequiredViewOps {
        void showToast(String msg);
        void showAlert(String msg);
        // any other ops
    }

    /**
     * Operations offered from Presenter to View
     *      View -> Presenter
     */
    interface PresenterOps{
        void onConfigurationChanged(RequiredViewOps view);
        void onDestroy(boolean isChangingConfig);
        void novaNota(String textoNota);
        void deletaNota(Nota nota);
        // any other ops to be called from View
    }

    /**
     * Operations offered from Presenter to Model
     *      Model -> Presenter
     */
    interface RequiredPresenterOps {
        void onNotaInserida(Nota novaNota);
        void onNotaRemovida(Nota notaRemovida);
        void onError(String errorMsg);
        // Any other returning operation Model -> Presenter
    }

    /**
     * Model operations offered to Presenter
     *      Presenter -> Model
     */
    interface ModelOps {
        void insereNota(Nota nota);
        void removeNota(Nota nota);
        void onDestroy();
        // Any other data operation
    }
}

leia mais