La fiabilité des interactions avec les sources de données est cruciale dans une architecture logicielle.
Sans tests adéquats, des erreurs peuvent survenir, compromettant la récupération et la transformation des données.
Cet article explore comment tester efficacement les repositories et les mappeurs pour garantir une couche data fiable.
Développez des applications Android solides, fiables et efficaces avec une approche TDD
La couche data est responsable de la récupération et du traitement des informations provenant de sources de données. Dans ce chapitre, nous allons examiner en détail les tests de la couche data, en particulier les tests des repositories et des mappeurs.
Comprendre la Couche Data
La couche data représente une partie cruciale de toute architecture logicielle. Elle est chargée de récupérer les données, généralement depuis une base de données ou une API externe, et de les transformer pour les rendre utilisables par les autres couches.
Cette figure présente l’organisation de la Couche Data dans une architecture en couches. Elle illustre deux composants principaux : les Repositories , qui sont responsables de la gestion des accès aux données, et les Mappeurs , qui s’occupent de la transformation des données entre différents formats ou objets.
Tester les Repositories
Le test des repositories consiste à vérifier que, lorsqu’une requête est effectuée pour obtenir des données, le repository renvoie les informations attendues. Pour ce faire, nous devons moquer les interactions avec les sources de données, telles que les bases de données.
Voici un exemple de code pour un test de repository :
Ce code en Kotlin utilise JUnit et Mockito pour tester la classe UserRepository , qui récupère les informations d’un utilisateur. Il crée des mocks pour les dépendances UserDataSource et UserDataToDomainMapper , simule les interactions avec ces composants et vérifie que la méthode getUserById de UserRepository renvoie bien l’utilisateur attendu.
- Le test configure Mockito pour simuler une réponse du dataSource (retournant un UserDataModel ) et une conversion du mapper (convertissant ce modèle en UserDomainModel ).
- Enfin, le test vérifie que le résultat obtenu correspond à l’utilisateur attendu via la méthode assertEquals .
@RunWith(MockitoJUnitRunner::class) class UserRepositoryTest {
@Mock lateinit var userDataSource : UserDataSource
@Mock lateinit var userMapper
: UserDataToDomainMapper lateinit var repository : UserRepository
@Before fun
setup() {
repository = UserRepository(userDataSource, userMapper)
}
@Test fun `test get user by ID returns expected user`() {
val userID = 1 val expectedUser =
UserDomainModel(userID, "John Doe")
// Simuler la réponse du dataSource
Mockito.`when`(userDataSource.getUserById(userID))
.thenReturn(UserDataModel(userID, "John Doe"))
// Simuler la conversion de DataModel en DomainModel
Mockito.`when`(userMapper.map(UserDataModel(userID, "John Doe")))
.thenReturn(expectedUser)
val result =
repository.getUserById(userID)
// Vérifier que le résultat correspond à l'utilisateur attendu
assertEquals(expectedUser, result)
}
}
Dans cet exemple, nous moquons la source de données (userDataSource) et le mappeur (userMapper). Le test vérifie que le repository renvoie l’utilisateur attendu lorsque nous passons un userID.
Élément | Description |
---|---|
Nom du test | Teste la récupération d’un utilisateur par ID dans le repository |
userDataSource (Mock) | Source de données simulée pour le test |
userMapper (Mock) | Conversion des données simulée pour le test |
Initialisation | Préparation du repository et des mocks avant le test |
Test principal | Vérifie si le repository renvoie l’utilisateur attendu |
Tester les Mappeurs
Le test des mappeurs est un autre aspect crucial du test de la couche data. Le mappeur doit transformer correctement un objet de type data en un objet de type domaine.
Exemple de test de mappeur :
Ce code Kotlin teste la classe UserDataToDomainMapper , qui est responsable de la conversion des objets de type UserDataModel (modèle de données) en UserDomainModel (modèle de domaine). Dans ce test, un objet UserDataModel est créé avec des valeurs spécifiques (ID et nom d’utilisateur), puis converti en un objet UserDomainModel à l’aide de la méthode map() du mapper. Le test compare ensuite le résultat de cette conversion avec un objet UserDomainModel attendu en utilisant assertEquals pour s’assurer que le mappage des données s’effectue correctement et que les deux objets sont équivalents.
class UserMapperTest {
private
val mapper =
UserDataToDomainMapper() @Test fun `test data to domain mapping`() {
val dataUser = UserDataModel(1, "John Doe") val expectedDomainUser =
UserDomainModel(1, "John Doe")
val result = mapper.map(dataUser)
assertEquals(expectedDomainUser, result)
}
}
Dans ce test, nous vérifions que le mappeur transforme correctement un UserDataModel en un UserDomainModel.
Cette figure présente un extrait de code dans un environnement de projet Android, illustrant un test unitaire pour la classe UtilisateurLiveRepository . Dans ce test, l’objectif est de vérifier si la méthode de récupération d’un utilisateur par ID fonctionne correctement en utilisant des mocks pour simuler les dépendances telles que UtilisateurDataSource et UtilisateurDataToDomainMapper .
Le test suit plusieurs étapes :
- La méthode setup() initialise une instance de la classe à tester ( classUnderTest ) avec les mocks correspondants.
- Le test, annoté avec @Test, simule un scénario où un userId est donné, et un utilisateur attendu est créé en tant qu’instance de UtilisateurDomain .
- La méthode given() (qui provient probablement de Mockito ou d’un autre outil de test) est utilisée pour définir le comportement attendu des mocks.
- Enfin, la méthode de la classe testée est appelée pour obtenir l’utilisateur, et le résultat est comparé à l’utilisateur attendu à l’aide de assertEquals .
Ce test garantit que la logique de récupération d’utilisateur dans UtilisateurLiveRepository fonctionne comme prévu, en vérifiant la cohérence entre les données simulées et les résultats de la méthode.
Formez-vous gratuitement avec Alphorm !
Maîtrisez les compétences clés en IT grâce à nos formations gratuites et accélérez votre carrière dès aujourd'hui.
FAQ
Pourquoi est-il essentiel de tester la couche data dans une architecture logicielle?
Comment les tests de repositories contribuent-ils à la fiabilité des applications?
Quel est le rôle des mappeurs dans la couche data?
Quels outils sont utilisés pour tester la couche data?
Comment le test des mappeurs est-il réalisé?
Conclusion
En conclusion, les tests de la couche data jouent un rôle crucial dans la fiabilité des applications. Quels autres aspects de la gestion des données aimeriez-vous explorer pour améliorer vos systèmes?