Il vous arrivera fréquemment de devoir tester des services web, que ce soient des services que vous avez développés, des services développés par une autre équipe et que vous consommez directement dans votre application, ou encore des services d’un fournisseur tiers.
Dans ces différents cas, il vous faut des solutions pour tester tout cela.
Si vous développez une API web avec ASP.NET Core (ou ASP.NET Web API 2), il existe des outils pour vous aider à tester automatiquement vos API.
Si vous utilisez une API web dont l’état est maîtrisable, voire mieux, où il n’y a pas d’état, alors vous pouvez requêter directement l’API et cela vous permettra de réaliser un test d’intégration complet du système.
Enfin, si l’état de l’API n’est pas maîtrisable, alors il vous faudra bouchonner les appels à l’API.
Nous allons regarder un peu plus en détail ces différents cas.
API dont l’état n’est pas maîtrisable
Nous allons commencer par cette dernière option, car finalement, c’est la plus facile. Si l’appel à un service web menace l’idempotence de vos tests et l’état non maîtrisable du web service, alors il n’y a pas 36 solutions, il faut bouchonner.
Vous devrez construire une façade, un repository, peu importe comment vous l’appelez, qui va permettre d’encapsuler l’appel au service web. Il faudra ensuite extraire une interface de cette façade, ainsi vous pourrez en bouchonner le fonctionnement ou également utiliser un simulacre.
Concrètement, si vous avez besoin de faire appel à un service tiers qui renvoie la météo, alors il faudra l’encapsuler dans une façade de ce genre :
public class FournisseurMeteoWebService : IFournisseurMeteo
{
private readonly IHttpClientFactory _httpClientFactory;
public FournisseurMeteoWebService(IHttpClientFactory httpClientFactory)
{
_httpClientFactory = httpClientFactory;
}
public Meteo QuelTempsFaitIl(DateTime dateSouhaitee)
{
var client = _httpClientFactory.CreateClient();
client.BaseAddress = new Uri("http://mon/super/fournisseur/de/meteo");
string result = await client.GetStringAsync($"/meteo/{dateSouhaitee}");
// ...
}
}Ainsi, grâce à l’abstraction IFournisseurMeteo , il est possible de fournir une fausse implémentation du web service qui viendra s’intégrer parfaitement dans vos tests.
Cas n°1 : API dont l’état est maîtrisable
En imaginant que nous ayons développé un système qui prédit la météo, avec tout un système complexe de calculs et de capteurs…
Qui a dit "Météo France" ? 🙂
Alors il serait sans doute pertinent de fournir une API qui puisse être consommée par des applications tierces, moyennant finances, pourquoi pas.
Qui a dit "vénal" ? 🙂
Et le résultat de tous ces calculs, cela tombe bien, finit dans notre table [dbo].InfosMeteo . Nous pouvons donc mettre à disposition la prévision de la météo, sous la forme d’une API web.
Puis notre application va la consommer, et pour pouvoir tester correctement son fonctionnement, nos tests pourront utiliser un script qui insérera la bonne valeur dans la base de tests automatiques.
En fait, c’est exactement pareil que précédemment, sauf que nous avons séparé le service et l’application. Le service de météo est une application API web indépendante.
Qui a dit microservices ? 🙂
Du coup, nos tests resteront les mêmes, c’est seulement l’implémentation de MeteoRepository qui va changer et qui va utiliser un HttpClient pour aller lire les données sur l’API web.
API développée par nos soins
Lorsque nous développons une API web, alors celle-ci devient une application à tester à part entière. Il existe une manière très simple de réaliser des tests d’intégration sur une application ASP.NET Core Web API ou ASP.NET Web API 2.
En effet, la capacité à pouvoir self-hoster son API web la rend de facto très simple à tester.
Pour l’exemple, nous allons réaliser une toute petite API web dont le but sera de mettre à disposition la valeur que l’on trouve en base de données.
Ajoutons un nouveau projet à la solution de type application web ASP.NET Core :
Puis choisissons une web API :
Renommons le contrôleur ValuesController qui a été généré en MeteoController .
Nous pouvons déplacer la classe MeteoRepository dans le projet d’API web et même supprimer l’implémentation de l’interface. La méthode QuelTempsFaitIl renverra par contre une chaîne de caractères :
public string QuelTempsFaitIl(DateTime dateSouhaitee)
{
using (var connection = new SqlConnection(_connectionstring))
{
var ligne = connection.QueryFirst("select Valeur from [dbo].InfosMeteo where DATE = Convert(date, @date)", new { date = dateSouhaitee });
return ligne.Valeur;
}
}Puis nous passons au contrôleur, mais pour plus de simplicité, je n’utilise pas le container IOC d’ASP.NET Core (ce qui est bien dommage, car il est très pratique 😜) ce qui donne :
[Route("api/[controller]")]
[ApiController]
public class MeteoController : ControllerBase
{
private const string _connectionstring = @"Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=Jeu5;Integrated Security=True;";
[HttpGet]
public ActionResult<string> Get()
{
var repository = new MeteoRepository(_connectionstring);
var resultat = repository.QuelTempsFaitIl(DateTime.Now);
return Ok(resultat);
}
}En conséquence, si vous démarrez votre API web - par exemple en appuyant sur F5 -, et que vous naviguez sur https://localhost:44361/api/meteo, alors vous aurez Soleil comme réponse.
Cette vérification fait que notre API web fonctionne, nous allons pouvoir passer à son test automatique.
Créez un nouveau "Projet de tests MSTests (.Net Core)" et nommez-le Meteo.IntegrationTest :
Ajoutez ensuite le package Nuget Microsoft.AspNetCore.TestHost.
Créez une classe de test avec le test suivant :
[TestClass]
public class MeteoTests
{
[TestMethod]
public async Task ObtientLeTempsQuilFait()
{
var webHostBuilder = new WebHostBuilder().UseStartup<Startup>();
using (var server = new TestServer(webHostBuilder))
using (var client = server.CreateClient())
{
string result = await client.GetStringAsync("/api/meteo");
Assert.AreEqual("Soleil", result);
}
}
}Grâce à ce test, qui appelle directement une URL sur le serveur web en mémoire, nous sommes capables de vérifier le comportement de notre API web.
Résumé de la partie
Il est possible de mesurer la couverture de code, c'est-à-dire la proportion de code testée, grâce à des outils qui s'intègrent à Visual Studio.
Attention, la mesure de couverture de code n'est qu'un indicateur et ne garantit pas que les tests sont utiles ou bien faits.
Lorsque l'on réalise un test qui lit ou écrit en base de données, il s'agit d'un test d'intégration.
Un test d'intégration permet de vérifier que tout ce qui a été testé unitairement fonctionne bien ensemble.
Il faut maîtriser l'état de la base de données afin de pouvoir écrire des tests idempotents.
Les frameworks de test fournissent des outils pour tester des services web.
Ce cours touche à sa fin, merci de l'avoir suivi. 😎
J'espère qu'il vous a convaincu de l'intérêt des tests et notamment de l'intérêt de créer des tests automatisés pour vérifier que votre application fonctionne correctement. Avec vos tests, vos serez sereins et vous pourrez développer des nouvelles fonctionnalités sans avoir peur d'introduire de régression.
Vous avez à présent toutes les clé en main pour :
Décrire le principe, l'intérêt et les types de tests automatiques
Lister les éléments qui apportent de la valeur à un test automatique
Utiliser un test unitaire en C#
Ecrire un test unitaire permettant de trouver une régression dans un code en C#
Lister les indicateurs de couverture de code
Expliquer le principe des tests d'intégration
N'oubliez pas de réalisez les exercices de fin de partie pour valider ces compétences.
N'hésitez pas à pratiquer et à créer régulièrement des tests car c'est avec l'expérience que vous arriverez à créer des tests qui apportent de la valeur, qui sont utiles et pragmatiques.
Je vous souhaite bon courage pour la suite de votre parcours. Gardez à l'esprit ce que vous venez d'apprendre, vous vous en remercierez sans aucun doute plus tard. 😃
