Tutoriel pour apprendre à tester son application Android avec MockK

Partons du principe que vous écrivez un code dont la fonctionnalité consiste à récupérer des utilisateurs stockés sur un serveur puis de les afficher dans une liste. Comment s’assurer que le code que vous avez écrit fonctionne bien ?

Ci-dessous un exemple d’une telle fonctionnalité.

Note : à la fin de cet article dans les liens externes, vous pourrez télécharger le modèle d’application dont cet exemple est issu.

class UserViewModel(application: Application,
                   private val networkService: NetworkService): ViewModel(application)
{
   @get:Bindable
   var user: List<User> by Delegates.observable(listOf()) { _, _, _ ->  notifyPropertyChanged(BR.user) }
   fun requestData()
   {
       networkService.getUsers {
           when (it)
           {
               is NetworkService.UserError.UserFetched -> user = it.user
               else ->{}
           }
       }
   }
}

Comme vous pouvez le voir dans l’exemple précédent, la classe UserViewModel possède une méthode requestData. Lors de l’appel à celle-ci, elle demande au NetworkService de récupérer la liste de tous les utilisateurs via la méthode getUsers. Cette méthode ne retourne rien, mais reçoit en paramètre une lambda qui contiendra les résultats.

Il y a deux possibilités pour tester ce code :

1. Installer et lancer l’application sur un téléphone (ou un émulateur) puis appuyer sur l’élément graphique permettant de lancer la fonctionnalité ;
2. Écrire un programme pour tester spécifiquement la fonctionnalité.

Dans cet article, nous allons nous intéresser à cette deuxième possibilité. Elle consiste à écrire un test unitaire en simulant le comportement des objets dont on dépend.

Comme le mentionne cette page du site, les mocks permettent d’isoler la classe que vous souhaitez tester unitairement en contrôlant le comportement de vos dépendances.

De ce fait vous isolez complètement votre classe et ne testez que son comportement.

II-A. MockK : une bibliothèque de mock pour Kotlin▲

II-B. Comment installer MockK dans votre projet Android▲

// Dans le fichier build.gradle de votre projet

buildscript {
    // Ajoutez la variable : mockkVersion
    ext {
        // Version actuelle de mockK lors de l’écriture de cet article
        mockkVersion = '1.9.3'
    }
}

// Dans le fichier build.gradle de votre module Android Studio

dependencies {
    // Ajoutez la dépendance à mockK
    testImplementation "io.mockk:mockk:$mockkVersion"
}

II-C. UserViewModelTest : la classe testant unitairement le UserViewModel▲

class UserViewModelTest {
   //Annotation de MockK permettant de créer automatiquement un mock
   @MockK
   private lateinit var application: Application
   @MockK
   private lateinit var networkService: NetworkService

   //Annotation de MockK permettant d’injecter automatiquement le mock à notre viewModel
   @InjectMockKs
   private lateinit var viewModel: UserViewModel

   //Annotation de JUnit permettant d’appeler la méthode setUp() avant chaque test
   @Before
   fun setUp() = MockKAnnotations.init(this)

   //Annotation permettant d’indiquer à JUnit que la méthode est un cas de test
   @Test
   fun `requestData() doit transmettre la requête au networkService`() {
       //On définit le comportement de notre mock. Ici on spécifie : “qu’à chaque fois que la méthode getUser() sera appelée avec n’importe quoi en paramètre ? on ne fera rien”
       every { networkService.getUsers(any()) } just Runs

       //On appelle la méthode de notre viewModel
       viewModel.requestData()

       //On vérifie que la méthode getUser() a bien été appelée
       verify { networkService.getUsers(any()) }
   }
}

II-D. Résultats des tests de UserViewModelTest ▲

Lors de l’exécution de UserViewModelTest, volontairement j’ai fait échouer puis réussir les tests unitaires. Les deux images suivantes vous montrent cela :

Cet article vous a donné un aperçu des possibilités de mockK. Elles sont nombreuses et je ne pouvais pas tout énumérer ici.

Je vous invite donc à parcourir la documentation pour avoir une idée de la puissance cette bibliothèque.

Toutefois une liste non exhaustive des fonctionnalités les plus utilisées à mon sens serait :

• la possibilité de mocker des lambdas ;

• par défaut les mocks créés par MockK sont stricts. Cela signifie que toutes les méthodes doivent avoir été définies via every{…}. Pour éviter cela, MockK permet l’utilisation de RelaxedMock ;
• la possibilité de capturer les paramètres d’une fonction. Cette fonctionnalité est très utilisée dans le cas d’une fonction A ayant comme paramètre une autre fonction B. Les mots clefs MockK pour faire cela sont : capture et slot ;
• dans cet article nous avons pris un cas simple dans lequel on a vérifié que la méthode de notre mock a bien été appelée : networkService.getUsers().
  Toutefois Mockk permet des vérifications plus avancées telles que : vérifier le nombre de fois qu’une méthode a été appelée (verify {atLeast = … / atMost = … / exactly = … }, vérifier l’appel à une méthode en lui spécifiant un timeout : verify {timeout = … }.

Je tiens à remercier Mickael Baron pour sa relecture technique et la mise au gabarit ainsi que Claude Leloup pour sa relecture orthographique attentive de cet article.

Télécharger la structure de l’application Android dont sont issus ces exemples.

La documentation de MockK (en anglais).