DEV Community

Cover image for Testing in Android. Better return value.
Tristan Elliott
Tristan Elliott

Posted on

3 1

Testing in Android. Better return value.

Introduction

  • Now that I have officially released my first app, which can be found HERE on the Google Play store. I want to add more features to my app, however, I think the next best step is to add some tests. So, this series is going to be a practical series dedicated to understanding testing in the Android framework.

Source code

  • You can find my source code HERE

Better return value

  • So inside the best practices section of the Android architecture guide it recommends adding a Resource class to wrap around our return values to encapsulate both the returned data and its state. Which is great, however, the the only problem is that the example is in Kotlin. So here is my example of converting the class displayed HERE into a Java class
public class Resource<T>{
    private  T data;
    private  String message;

    public Resource( T data, @Nullable String message){
        this.data = data;
        this.message = message;
    }

    public static <T> Resource<T> success( T data){
        return new Resource<>(data,null);
    }

    public static <T> Resource<T> loading(T data){
        return new Resource<>(data,null);
    }

    public static <T> Resource<T> error(T data, String message){
        return new Resource<>(data,message);
    }


    //GETTERS
    public T getData(){
        return this.data;
    }
    public String getMessage(){
        return this.message;
    }

}
Enter fullscreen mode Exit fullscreen mode
  • The code above is a pretty straight forward class. The only thing that might seem a little off is all the T which are called type parameters and allows us to use this class with multiple data types.

  • The main benefit of this class is to wrap the return values from the DAO in this Resource class. This allows us to provide our UI with more info. Especially when an error occurs.

  • This code might not seem relevant now but I will be using it to unit test the repository layer of my app.

Conclusion

  • Thank you for taking the time out of your day to read this blog post of mine. If you have any questions or concerns please comment below or reach out to me on Twitter.

Top comments (0)

Great read:

Is it Time to go Back to the Monolith?

History repeats itself. Everything old is new again and I’ve been around long enough to see ideas discarded, rediscovered and return triumphantly to overtake the fad. In recent years SQL has made a tremendous comeback from the dead. We love relational databases all over again. I think the Monolith will have its space odyssey moment again. Microservices and serverless are trends pushed by the cloud vendors, designed to sell us more cloud computing resources.

Microservices make very little sense financially for most use cases. Yes, they can ramp down. But when they scale up, they pay the costs in dividends. The increased observability costs alone line the pockets of the “big cloud” vendors.

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay