Bonnes pratiques en matière de tests

Lorsque vous utilisez les fonctionnalités de test fournies par CodeCatalyst, nous vous recommandons de suivre ces meilleures pratiques.

Découverte automatique

Lorsque vous configurez des actions dans CodeCatalyst, la découverte automatique vous permet de découvrir automatiquement les résultats de divers outils, tels que les rapports de JUnit test, et de générer des CodeCatalyst rapports pertinents à partir de ceux-ci. La découverte automatique permet de garantir que les rapports continuent d'être générés même si les noms ou les chemins des sorties découvertes changent. Lorsque de nouveaux fichiers sont ajoutés, il les découvre CodeCatalyst automatiquement et produit des rapports pertinents. Toutefois, si vous utilisez la détection automatique, il est important de prendre en compte certains des aspects suivants de cette fonctionnalité :

• Lorsque vous activez la détection automatique dans votre action, tous les rapports découverts automatiquement du même type partagent les mêmes critères de réussite. Par exemple, un critère partagé tel que le taux de réussite minimum s'appliquerait à tous les rapports de test découverts automatiquement. Si vous avez besoin de critères différents pour les rapports du même type, vous devez configurer explicitement chacun de ces rapports.

• La détection automatique peut également détecter les rapports produits par vos dépendances et, si des critères de réussite sont configurés, l'action sur ces rapports risque d'échouer. Ce problème peut être résolu en mettant à jour la configuration du chemin d'exclusion.

• Il n'est pas garanti que la découverte automatique produise la même liste de rapports à chaque fois, car elle analyse l'action au moment de l'exécution. Dans le cas où vous souhaitez qu'un rapport particulier soit toujours produit, vous devez configurer les rapports de manière explicite. Par exemple, si les tests cessaient de s'exécuter dans le cadre de votre build, le framework de test ne produirait aucun résultat et, par conséquent, aucun rapport de test ne serait produit et l'action pourrait réussir. Si vous souhaitez que le succès de votre action dépende de ce test en particulier, vous devez configurer explicitement ce rapport.

Astuce

Lorsque vous commencez à travailler sur un projet nouveau ou existant, utilisez la détection automatique pour l'ensemble du répertoire du projet (y compris**/*). Cela implique la génération de rapports pour tous les fichiers de votre projet, y compris ceux des sous-répertoires.

Pour plus d’informations, consultez Configuration des rapports de qualité dans une action.

Critères de réussite

Vous pouvez appliquer des seuils de qualité à vos rapports en configurant des critères de réussite. Par exemple, si deux rapports de couverture de code ont été découverts automatiquement, l'un avec une couverture de ligne de 80 % et l'autre avec une couverture de ligne de 60 %, les options suivantes s'offrent à vous :

• Définissez les critères de réussite de la détection automatique pour la couverture des lignes à 80 %. Cela entraînerait l'adoption du premier rapport et l'échec du second rapport, ce qui entraînerait l'échec de l'action globale. Pour débloquer le flux de travail, ajoutez de nouveaux tests à votre projet jusqu'à ce que la couverture linéaire du deuxième rapport dépasse 80 %.

• Définissez les critères de réussite de la détection automatique pour la couverture des lignes à 60 %. Cela entraînerait la transmission des deux rapports, ce qui se traduirait par le succès de l'action. Vous pourriez ensuite travailler à augmenter la couverture du code dans le deuxième rapport. Toutefois, avec cette approche, vous ne pouvez pas garantir que le taux de couverture indiqué dans le premier rapport ne descendra pas en dessous de 80 %.

• Configurez explicitement l'un des rapports ou les deux à l'aide de l'éditeur visuel ou en ajoutant une YAML section et un chemin explicites pour chaque rapport. Cela vous permettra de configurer des critères de réussite distincts et des noms personnalisés pour chaque rapport. Toutefois, avec cette approche, l'action peut échouer si les chemins des rapports changent.

Pour plus d’informations, consultez Configuration des critères de réussite pour les rapports.

Inclure/exclure des chemins

Lorsque vous examinez les résultats des actions, vous pouvez ajuster la liste des rapports générés CodeCatalyst par en configurant IncludePaths etExcludePaths.

• Permet IncludePaths de spécifier les fichiers et les chemins de fichiers que vous CodeCatalyst souhaitez inclure lors de la recherche de rapports. Par exemple, si vous le spécifiez"/test/report/*", CodeCatalyst recherche l'intégralité de l'image de construction utilisée par l'action à la recherche du /test/report/ répertoire. Lorsqu'il trouve ce répertoire, CodeCatalyst il recherche des rapports dans ce répertoire.

  Note

  Pour les rapports configurés manuellement, IncludePaths il doit s'agir d'un modèle global correspondant à un seul fichier.

• Permet ExcludePaths de spécifier les fichiers et les chemins de fichiers que vous CodeCatalyst souhaitez exclure lors de la recherche de rapports. Par exemple, si vous le spécifiez"/test/reports/**/*", ne CodeCatalyst recherchera pas de fichiers dans le /test/reports/ répertoire. Pour ignorer tous les fichiers d'un répertoire, utilisez le modèle **/* glob.

Vous trouverez ci-dessous des exemples de modèles globaux possibles.

Modèle	Description
*.*	Correspond à tous les noms d'objets du répertoire actuel contenant un point
*.xml	Correspond à tous les noms d'objets du répertoire actuel se terminant par .xml
*.{xml,txt}	Correspond à tous les noms d'objets du répertoire actuel se terminant par .xml ou .txt
**/*.xml	Fait correspondre les noms d'objets dans tous les répertoires se terminant par .xml
testFolder	Correspond à un objet appelétestFolder, en le traitant comme un fichier
testFolder/*	Fait correspondre les objets d'un niveau du sous-dossier à partir detestFolder, tels que testFolder/file.xml
testFolder/*/*	Fait correspondre les objets situés à deux niveaux du sous-dossier à partir detestFolder, tels que testFolder/reportsFolder/file.xml
testFolder/**	Correspond au sous-dossier testFolder, ainsi qu'aux fichiers sous testFolder, tels que testFolder/file.xml et testFolder/otherFolder/file.xml

CodeCatalyst interprète les modèles globulaires comme suit :

• Le caractère slash (/) sépare les répertoires dans les chemins de fichiers.

• L'astérisque (*) correspond à zéro ou plusieurs caractères d'un composant de nom sans dépasser les limites d'un dossier.

• Un double astérisque (**) correspond à zéro ou plusieurs caractères d'un composant de nom dans tous les répertoires.

Note

ExcludePathsa la priorité sur. IncludePaths Si IncludePaths les deux ExcludePaths incluent le même dossier, ce dossier n'est pas scanné pour les rapports.