Les tests automatisés jouent un rôle central pour assurer la qualité et la fiabilité des livraisons. Pourtant, l’automatisation des tests d’APIs dans les workflows CI/CD reste un défi pour de nombreuses équipes. Le client (CLI) Bruno se présente comme une solution innovante pour simplifier cette tâche. Cet outil accessible en open-source permet d’exécuter des tests d’APIs rapidement, de manière efficace et intégrée. Dans cet article, nous allons explorer comment configurer un pipeline CI/CD dans Azure DevOps pour automatiser ces tests.
L’automatisation des tests est une solution intéressante pour éviter les régressions et garantir le bon fonctionnement des APIs. Voici les principaux défis qui se posent lors de l’intégration de ces tests dans un workflow CI/CD :
Bruno, une alternative à Postman, est un outil open-source spécialement conçu pour tester les APIs REST. Il se distingue par sa performance et sa simplicité, offrant une expérience fluide et efficace. Son interface graphique regroupe toutes les fonctionnalités essentielles d’un client HTTP, garantissant une utilisation intuitive. De plus, grâce à son onglet Tests, il permet de définir très facilement les assertions attendues, optimisant ainsi le processus de validation des requêtes.
De plus, son principal atout réside dans la possibilité d’intégrer les requêtes directement dans le code, sous forme de fichiers stockés dans un projet. Cette approche permet un contrôle total sur les requêtes et les tests API, en facilitant leur partage, le suivi des modifications et la gestion collaborative au sein des équipes techniques, notamment grâce à une intégration naturelle avec Git.
Pour en savoir plus, voir la documentation en ligne.
Bruno se distingue par sa simplicité d’utilisation, avec une syntaxe intuitive et des commandes faciles à intégrer via son CLI. En effet, il offre également une grande flexibilité en s’intégrant aisément dans des scripts PowerShell et des pipelines CI/CD, ce qui en fait un outil adapté aux workflows de développement.
Cependant, son utilisation peut nécessiter une certaine adaptation, notamment en raison de la structure spécifique de ses collections de tests, qui demande un temps d’apprentissage pour les nouveaux utilisateurs.
Dans Azure DevOps nous avons créé le Task Group Bruno Test (BT) qui nous permet d’exécuter des opérations d’API avec Bruno CLI. En outre, les paramètres du Task Group incluent des informations essentielles telles que l’API Key, le scope utilisé pour l’authentification, ainsi que le chemin de la racine du projet Bruno et les requêtes de test.
Voici la structuration du Task group décomposées en quatre étapes.
La première étape consiste à récupérer les secrets stockés dans Azure Key Vault, notamment le clientID et le clientSecret, qui sont nécessaires pour authentifier les appels d’API. Pour cela, nous utilisons Azure CLI, ce qui permet d’accéder aux secrets directement en ligne de commande :
$Secret = az keyvault secret show --name "secret-key-name" --vault-name "key-vault-service-name" --query "value" -o tsv
Ensuite, une fois le secret récupéré, il est stocké dans une variable de pipeline Azure DevOps afin d’être utilisé dans les étapes suivantes :
Write-Host "##vso[task.setvariable variable=Secret]$Secret"
De même, il est important de noter que pour garantir un accès sécurisé aux secrets, il est préférable d’attribuer au Service Principal lié à Azure DevOps les droits nécessaires sur Azure Key Vault plutôt que d’exposer un Personal Access Token (PAT) en clair dans le pipeline. Cette approche permet d’éviter tout problème de permissions tout en maintenant un haut niveau de sécurité.
Avant d’exécuter les tests, il est nécessaire d’installer Node.js et Bruno CLI sur l’agent d’exécution avec la commande :
npm install -g @usebruno/cli
L’exécution sur le CLI Bruno se fait à partir de la racine du projet Bruno $path en indiquant le dossier dans lequel se trouve les opérations à tester $folder. Pour assurer le bon fonctionnement du pipeline Azure DevOps, gérez efficacement le fichier de configuration d’environnement $configFilePath et veillez à générer correctement les rapports de tests dans $destinationReport. Pour cela, nommez le fichier d’environnement en fonction de l’environnement d’exécution du pipeline $(Env_Maj), enregistré dans une bibliothèque de variables Azure DevOps.
Cela permet une configuration adaptable aux différents environnements de déploiement.
$folder="$(QueriesFolder)" $path="$(ProjectPath)" $configFilePath = "$path\environments\$(Env_Maj).bru" $destinationReport = "$path\Results\report.xml"
Avant d’exécuter les tests API, il est essentiel d’injecter dynamiquement les valeurs des variables récupérées dans le fichier de configuration <ENV>.bru. Ce script PowerShell automatise cette mise à jour en lisant le fichier existant, en modifiant ou en ajoutant la section vars contenant les informations nécessaires (hôte de l’API, clés d’authentification, client ID, etc.), puis en sauvegardant le fichier mis à jour.
L’approche adoptée permet de garantir la cohérence des tests en s’assurant que les valeurs utilisées correspondent aux paramètres définis dans le pipeline. De plus, si le fichier de configuration n’existe pas encore, le script génère automatiquement un fichier de base, évitant ainsi tout risque d’erreur bloquante.
Enfin, une gestion des erreurs est intégrée pour assurer la fiabilité du processus, notamment en vérifiant l’accès au fichier et en contrôlant les permissions lors de l’écriture des nouvelles valeurs. Cette méthode permet d’adapter dynamiquement la configuration sans intervention manuelle, garantissant ainsi une exécution fluide et automatisée des tests API dans les différents environnements.
# Lire, modifier et sauvegarder le fichier de configuration
Write-Host "Mise à jour du fichier de configuration : $configFilePath"
if (Test-Path $configFilePath) {
# Lire le contenu existant
$existingContent = Get-Content -Path $configFilePath -Raw
} else {
# Si le fichier n'existe pas, créer un contenu de base
$existingContent = ''
Write-Warning "Le fichier de configuration '$configFilePath' n'existe pas. Un nouveau fichier sera créé."
}
# Construire la nouvelle section `vars`
$newVarsSection = @"
vars {
apimHost: $(Common_Host_Name)
scope: $(Scope)
apiKeyExternal: $subscriptionValue
client_id: $clientIdValue
client_secret: $clientSecretValue
}
"@
# Supprimer la section `vars:secret [...]`
$updatedContent = $existingContent -replace '(?s)vars:secret\s*\[.*?\]', ''
# Rechercher et remplacer la section `vars {}` ou ajouter une nouvelle section
if ($existingContent -match '(?s)vars\s*{.*?}') {
# Remplacer la section existante par la nouvelle
$updatedContent = $updatedContent -replace '(?s)vars\s*{.*?}', $newVarsSection
Write-Host "Section 'vars {}' existante remplacée dans le fichier de configuration."
} else {
# Ajouter la section `vars {}` à la fin du fichier
$updatedContent = $updatedContent + "`r`n" + $newVarsSection
Write-Host "Nouvelle section 'vars {}' ajoutée au fichier de configuration."
}
# Sauvegarder le fichier
try {
Set-Content -Path $configFilePath -Value $updatedContent -Force
Write-Host "Fichier de configuration sauvegardé avec succès : $configFilePath"
} catch {
Write-Error "Échec de la mise à jour du fichier de configuration. Vérifiez les permissions et le chemin."
exit 1
}
Une fois le fichier de configuration de l’environnement mis à jour, exécutez les tests avec la commande suivante en utilisant les options –output et –format pour générer le rapport au format JUnit.
bru run --env "$(Env_Maj)" --output "$destinationReport" --format junit $folder
Les fichiers XML contenant les résultats des tests sont publiés avec Publish Test Results depuis le chemin $destinationReport. En intégrant cette tâche au pipeline, l’équipe s’assure que les rapports de tests générés sont bien pris en compte et accessibles. Une fois cette étape ajoutée, les résultats apparaissent dans l’onglet Tests d’Azure DevOps, où chaque exécution est tracée avec des détails sur les éventuels tests échoués.
L’intégration de Bruno dans un pipeline d’Azure DevOps apporte de réels avantages en matière de test des APIs. En automatisant ces tests, nous réduisons considérablement le temps passé sur les validations manuelles tout en garantissant une meilleure fiabilité des déploiements. L’intégration native des requêtes dans le code simplifie le versionnement et l’intègre naturellement aux workflows des développeurs.
Pour assurer un pipeline efficace et sécurisé, plusieurs bonnes pratiques sont essentielles. La gestion des secrets doit être rigoureuse : l’utilisation d’Azure Key Vault permet de sécuriser les identifiants et clés API tout en contrôlant précisément les accès. Avant toute exécution, il est aussi crucial de valider les fichiers de configuration, en testant localement les assertions et la génération des rapports afin d’anticiper d’éventuelles erreurs. Par ailleurs, comme Bruno nécessite Node.js pour fonctionner, il faut configurer correctement l’environnement d’exécution afin d’éviter tout problème lié aux dépendances. Enfin, il est essentiel de renforcer la résilience du pipeline en gérant les erreurs de manière à prévenir les blocages en cas de problème mineur.
En pratique, cette approche a montré des gains de temps significatifs, en limitant les tâches répétitives et les risques d’erreur humaine. Les tests automatisés garantissent une meilleure fiabilité sur l’ensemble des environnements de déploiement. Toutefois, certaines améliorations restent possibles, notamment sur la gestion des jeux de données, afin d’assurer des tests reproductibles avec des données stables. De même, la personnalisation des rapports, en y intégrant des métadonnées spécifiques, pourrait faciliter encore davantage l’analyse des résultats.
Adopter Bruno dans un pipeline CI/CD, c’est donc faire un pas de plus vers une automatisation robuste et performante, tout en optimisant la qualité des tests API.