I found that I was particularly lazy when it came to testing network requests, which is a pretty bad thing. So from the Model, View and Presenter : we’re done with Presenter. We’ve now added test coverage to our Presenter. One which deals with a successful response and one which deals with an error. These are sample two tests that can be written for the Presenter. There are a ton of other great libraries like Dagger which would help with testability too, but that is out of the scope for this post. I’m using RxJava2 and Retrofit, OkHttp for this example. Let’s take a simple example of a screen which shows a list of blogs that are fetched from a remote server. This separation of concerns is very friendly to writing unit tests since each layer can have mocked dependencies and we can test for happy-cases as well as disastrous ones! It will only intercept clicks/user events and ask the Presenter what to do and then just display whatever the Presenter tells it to display. View layer is supposed to be really dumb. The Data layer will contain all logic related to caching (if any), getting data from API if necessary, sanitizing API response (if required) etc. Data layer will expose an API which can be consumed by any Presenter and returns the data. Or limiting the amount of data to be shown. For example making calls to Data layer, getting a result and then setting it to the View. Each layer takes care of things that are specific to it : for example, Presentation layer will take care of things related to presentation logic. One of the great benefits of having MVP architecture/Clean architecture is the separation of concerns and the testability that each layer provides.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |