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.

    // 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 relations

Model View Presenter (MVP) in Android, Part 3

Hello! In the conclusion of the Model View Presenter in Android series, we’ll talk about:

  • How to implement MVP using the library  simple-mvp to speed up your production process
  • Common hiccups when using MVP in Android

If you missed the anterior articles, or  want to understand the Model View Presenter concept in more detail, you can read it here:

Using the simple-mvp library

The simple-mvp library was implemented using Dr. Douglas C. Schmidt concept. The code follows the canonical form principles, hence it doesn’t use any library or resource from outside the Android SDK. There are some requirements that must be followed to the framework work properly.

Attention: simple-mvp is still an experimental library created for education purposes.
Some methods and operations may change until its maturity.

Quick setup

add build.gradle compile ‘com.tinmegali.mvp:mvp:0.0.7’ Create interfaces to communicate between MVP layers
  • interface RequiredViewOps extends ActivityView
    with VIEW methods to be accessed by PRESENTER
  • interface ProvidedPresenterOps extends PresenterOps
    Operations offered to VIEW to communicate with PRESENTER
  • interface RequiredPresenterOps
    with Required PRESENTER methods available to MODEL
  • interface ProvidedModelOps extends ModelOps
    Operations offered to MODEL to communicate with PRESENTER
Implement MVP objects extending its generics MODEL from Model View Presenter (MVP) pattern.
class MODEL extends GenericModel
      implements MVP_MainActivity.ProvidedModelOps
VIEW layer of MVP pattern
class VIEW_Activity extends GenericMVPActivity<MVP_MainActivity.RequiredViewOps, MVP_MainActivity.ProvidedPresenterOps, MainPresenter>
implements MVP_MainActivity.RequiredViewOps
Could also extend GenericMVPFragment PRESENTER from Model View Presenter (MVP) Pattern.
class MainPresenter extends GenericPresenter<MVP_MainActivity.RequiredPresenterOps, MVP_MainActivity.ProvidedModelOps, MVP_MainActivity.RequiredViewOps, MainModel>

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″]


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

relações do Model View Presenter

Model View Presenter (MVP) in Android, Part 1

Architecture Pattern is a fundamental part of computer science. It’s the only way to maintain a project clean, expansible and testable. The patterns are recognized solutions that have been developed over the years and are considered industry standards. They’re constantly evolving, and in the Android SDK, the reliable Model View Controller pattern is steadily being dropped for the Model View Presenter.

In the first part of this article we’ll discuss the main differences between MVC (Model View Controller) and MVP (Model View Presenter), why MVC is being dropped, how MVP adjusts  to Android SDK and its greatest advantages.

leia mais