Avant de continuer nos tests d’intégration, nous avons remarqué que nous allions appeler un DataLayer dédié pour communiquer avec notre base de données et vérifier l’authentification de l’utilisateur. Or pour se connecter, nous allons utiliser le SignInManager d’Identity. Comment tester notre DataLayer avec cette classe ?
Identity existe déjà depuis de nombreuses années, sous .net. La communauté l’a bien évidemment porté sous .net core, puis l’a inclus dans asp.net core.
Ce package permet de gérer toute l’authentification dans une application :
Nous reviendrons dans un prochain article sur Identity, où nous le découvrirons dans sa totalité.
Nous souhaitons encapsuler notre appel à la base de données, avec une classe dédiée : UserDataLayer.
Or, si nous mettons en place le principe TDD, nous allons créer notre classe de Test avant notre classe UserDataLayer.
Dans la méthode de notre classe, nous souhaitons rechercher un utilisateur suivant son login (email) et son mot de passe.
Pour vérifier le login et le mot de passe, nous utiliserons la classe d’Identity dédiée : SignInManager.
Nous créerons donc une méthode de récupération de l’utilisateur : GetOneAsync.
Or, quand tout sera implémenté, notre classe utilisera un context EntityFramework, pour vérifier le login et mot de passe en base de données.
Or, nous ne voulons pas vérifier que le SignInManager fonctionne. Nous souhaitons prouver que notre future classe UserDataLayer fonctionne bien selon les attentes écrites dans nos Tests unitaires.
Nous allons donc simuler (Mocker) la classe SignInManager !
Nous allons arriver ainsi à simuler la classe SignInManager, qui sera transmise en principe IoC, à notre classe UserDatalayer.
Or, la classe SignInManager n’est pas simple à simuler !
Ainsi, nous allons arriver à un mix entre Fake et Mock.
Voici le résultat :
Vous noterez :
Nous allons ainsi pouvoir créer notre classe de Test pour prouver que le login fonctionne :
Vous noterez :
Et nous voilà prêt pour concevoir notre classe, notre réelle, pas la classe de Test.
En vrai, avec le principe TDD, nous aurions appliqué le principe Red Green Refactor, itératif.
Nous vous livrons ici le résultat de la classe :
A très vite pour d’autres astuces et tutoriaux, toujours avec curiosité !