Ca y est tous nos tests unitaires sont mis en place, et tout passe au vert : Hiha ! Et on lance l’application, et paf l’éléphant ! (en fait paf la voiture, mais bon c’est un autre sujet).
Comment faire pour que nos tests unitaires de nos controllers, de notre business, ne perdent pas toute valeur lors de la mise en production ? Découvrons ensemble les tests d’intégration, avec asp.net core.
Des tests unitaires qui ne testent pas tout
Quand on parle de test, souvent, du point de vue des développeurs et développeuses, on entend : TU (test unitaire) et TDD (Test Driven Development).
Certains, certaines se sont aventurés sur les traces du BDD (Behavior Driven Development).
Et pourtant, avec tous ces tests, pensez-vous vraiment que tout est ok ? Que tout va fonctionner une fois en PROD ?
Les TUs ne testent pas tout, ils testent des composants, ils ne testent pas un fonctionnement de bout en bout (e2e).
Comment alors s’assurer que tout va, à priori, bien fonctionner en Production ?
Il existe de nombreux moyens, et nous allons en voir un :
Notre premier test d’intégration
L’idée ici c’est de simuler un comportement en production, de bout en bout.
Nous allons ainsi pouvoir les mettre en place du côté code, et donc les automatiser ! Oui, oui, vous avez bien lu ! Plus besoin d’y penser (ou presque).
Avant tout, créez un projet de Test asp.net core, en xUnit.
Première étape : Ajout des packages nécessaires (Microsoft.AspNetCore.Mvc.Testing)
Ajoutez la référence NuGet : Microsoft.AspNetCore.Mvc.Testing.
Pensez aussi à référencer : Microsoft.AspNetCore.App, pour pouvoir lancer et tester votre application asp.net core.
Seconde étape : créer votre premier test d’intégration
Démarrez comme si vous souhaitiez faire un test unitaire : créez une classe et une méthode dédiée pour tester un accès, tester une url donnée.
Point très important : vous devez décorer votre classe
La décoration va se faire avec une interface proposée par xUnit : IClassFixture.
Or, vous avez noté que cette interface est une interface générique : elle attend un type qu’elle va tester.
Nous allons tester notre application. Qui est notre démarreur de l’application : la classe Startup.
En fait, plus précisément, notre moteur de Test ne va pas charger directement la classe Startup : il va charger une classe dédiée pour les tests d’intégration : WebApplicationFactory.
Et ca sera elle qui appellera notre classe Startup. 
Elle va s’occuper de charger en mémoire notre application pour nos tests : yes !
Vous obtenez une classe de ce style :
Note : en fait, si on veut être très précis ici, le fait d’utiliser IClassFixture est utile pour éviter de charger et décharger pour chaque méthode des actions demandant du temps et des ressources.
Ainsi, dans notre exemple : cela va permettre de charger la classe Startup une fois à l’instanciation de la classe de test, et au besoin, appeler le Dispose pour libérer les ressources (accès base de données par exemple).
Puis, créez votre première méthode de test
Ici, vous souhaitez tester une url en particulier. Rappelons notre cas : nous souhaitons tester notre api.
Nous aurons donc tout intérêt à nous assurer que le retour de notre api fonctionne et surtout renvoi les données souhaitées, et dans le bon type (json).
Vous allez, pour y arriver :
- Créer un client HTTP grâce à notre factory (la classe WebApplicationFactory)
- Faire une requête Post vers notre url à tester
- Récupérer le retour de la requête HTTP
- Vérifier le type de retour, le contenu, …
On reviendra très vite sur les possibilités extra-ordinaires qu’offrent les tests d’intégration !
Et vous, vous avez testé ? Êtes-vous allé-e jusqu’à les inclure dans votre intégration continue ?