Unit Tests

💁‍♂️ Unit tests makes it possible to test all the objects of the architecture which does not require to have a context of the application. Each test is specific to a single class. If other classes are used within this same class they will be mocked to ensure that the test results are focused on the tested class.

Type	Name
Unit Test	JUnit / Mockito (mockito-inline, mockito-kotlin)

Presentation:

Unit tests of the presentation module are focused on the Presenter. The objective is to test all the actions specified by the intents of each scene and make sure that the right ViewModel is sent to the View.

Example:

• loadData: load data successfully
• loadDataWhenUseCaseReturnException: loads data with error (without network connection for example)
• refresh: refresh data
• retry: retry to load data after error

👀 You can check a full example here: RepoPresenterTest.kt

🚀 To run all presentation unit tests from terminal: ./gradlew :presentation:testDebugTestUnitTest

Domain:

There are many types of UseCases possible. Here are the main ones:

• Get: If connected, get data from network, save it and get cache data. If not, get data from cache or return an error if is empty.
• GetCache: Get data from cache or return an error if is empty.
• Refresh: If connected, get data from network, save it and get cache data. If not, return an error.

For each of them, you must test the use case under optimal conditions and test the usecase when it returns an error.

👀 You can check a full example here: GetRepoTest.kt

🚀 To run all domain unit tests from terminal: ./gradlew :domain:test

Data:

This module is the most important and requires a lot of testing.

ℹ️ Here we assume that your application retrieves data from web services (Net) and saves it in a database (Persistence). If not, simply delete the Net or Persistence block and remove the associated tests.

1. Mapper

There is a mapper for each data model in your application. It is essential to test them to avoid data loss during their transformation:

• dtoToModel: object from webservice to model
• modelToEntity: model to object from database
• entityToModel: object from database to model
• collectionToList: same thing on all conditions with collections

👀 You can check a full example here: RepoMapperTest.kt

2. Processor

For each Entity there are a DAO and a Processor. The processor is a bridge between the DAO to return the data in the desired format. It is essential to check that for each method of the processor the correct methods of the DAO are called.

ℹ️ The DAO is not unit tested because it is essential to have a context to write to the database. We will therefore use the Instrumental Tests to test them.

👀 You can check a full example here: RepoProcessorTest.kt

3. Api

Testing that web services we use in the app is important. It is also very practical to quickly identify a problem with the server when running tests. However, this test is to be discussed since its result does not depend exclusively on the application code.

👀 You can check a full example here: GitHubApiTest.kt

4. Repository

The Repository is the object of data layer which will be called by the application usecases in the domain module. It is the bridge between all the classes that we have just tested previously. This object can seem complex because it can quickly contain a lot of methods. However, once we have tested all the classes it uses, tests are fairly simple.

👀 You can check a full example here: RepoDataRepositoryTest.kt

🚀 To run all data unit tests from terminal: ./gradlew :data:testDebugTestUnitTest