Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans le contexte de Microsoft.Testing.Platform, une fonctionnalité fait référence au potentiel d’effectuer une action spécifique ou de fournir des informations spécifiques. Il s’agit d’un moyen pour l’infrastructure de test et les extensions de déclarer leur capacité à fonctionner d’une certaine manière ou à fournir des informations spécifiques aux demandeurs.
Les demandeurs peuvent être n’importe quel composant impliqué dans une session de test, comme la plateforme, une extension ou l’infrastructure de test elle-même.
L’objectif principal du système de capacité est de faciliter la communication efficace entre les composants impliqués dans une session de test, ce qui leur permet de exchange des informations et de répondre avec précision à leurs besoins respectifs.
Exemple guidé
Prenons un exemple hypothétique pour illustrer la nécessité d’un système de capacité.
Remarque
Cet exemple est purement à des fins d’illustration et n’est actuellement pas implémenté dans Microsoft.Testing.Platform ou tout framework de test.
Imaginez une situation où vous disposez d’une extension qui nécessite que l’infrastructure de test n’exécute pas plus d’un test à la fois. En outre, après chaque test, l’extension doit connaître l’utilisation du processeur pour ce test spécifique.
Pour prendre en charge le scénario précédent, vous devez vous renseigner auprès de l’infrastructure de test si :
- Il a la possibilité d’exécuter un seul test à la fois.
- Il peut fournir des informations sur la quantité d’UC consommée par chaque test.
Comment l’extension peut-elle déterminer si l’infrastructure de test peut fonctionner dans ce mode et fournir des informations d’utilisation du processeur pour une session de test ? Dans Microsoft.Testing.Platform, cette fonctionnalité est représentée par une implémentation de l’interface Microsoft.Testing.Platform.Capabilities.ICapability :
// Base capabilities contracts
public interface ICapability
{
}
public interface ICapabilities<TCapability>
where TCapability : ICapability
{
IReadOnlyCollection<TCapability> Capabilities { get; }
}
// Specific testing framework capabilities
public interface ITestFrameworkCapabilities : ICapabilities<ITestFrameworkCapability>
{
}
public interface ITestFrameworkCapability : ICapability
{
}
Comme vous pouvez le voir, l’interface ICapability est une interface de marqueur , car elle peut représenter n’importe quelle fonctionnalité, et l’implémentation réelle dépend du contexte. Vous observerez également le ITestFrameworkCapability, qui hérite de ICapability pour classer la capacité. La nature générique du système de capacité permet un regroupement pratique par contexte. Le ITestFrameworkCapability groupe toutes les fonctionnalités implémentées par l’infrastructure de test. L’interface ICapabilities<TCapability> révèle l’ensemble de toutes les fonctionnalités implémentées par une extension. De même, pour la base, il existe un framework de test spécifique au contexte appelé ITestFrameworkCapabilities. Le ITestFrameworkCapabilities est fourni à la plateforme lors du processus d'enregistrement du framework de test.
Pour créer une fonctionnalité qui traite le scénario mentionné ci-dessus, vous la définissez comme suit :
public interface IDisableParallelismCapability : ITestFrameworkCapability
{
bool CanDisableParallelism { get; }
bool CanProvidePerTestCpuConsumption { get; }
void Enable();
}
Si l’infrastructure de test implémente cette interface, au moment de l’exécution, les requêtes suivantes peuvent être interrogées :
- Vérifiez si l’infrastructure de test a la possibilité de désactiver le parallélisme
CanDisableParallelism = true. - Déterminez si l’infrastructure de test peut fournir des données
CanProvidePerTestCPUConsumption = trued’utilisation du processeur. - Demandez à l’adaptateur de test d’activer ce mode en appelant la
Enable()méthode avant le début de la session de test.
Le fragment de code hypothétique à l’intérieur de l’extension peut ressembler à ceci :
IServiceProvider provider = null; // TODO: Get IServiceProvider.
var capabilities = serviceProvider.GetRequiredService<ITestFrameworkCapabilities>();
// Utilize the `GetCapability` API to search for the specific capability to query.
var capability = capabilities.GetCapability<IDisableParallelismCapability>();
if (capability is null)
{
// Capability not supported...
}
else
{
capability.Enable();
if (capability.CanDisableParallelism)
{
// Do something...
}
if (capability.CanProvidePerTestCpuConsumption)
{
// Do something...
}
}
L’exemple précédent montre comment l’infrastructure de capacité permet un mécanisme puissant pour communiquer les capacités entre les composants impliqués dans une session de test. Bien que l’exemple illustre une fonctionnalité spécifiquement conçue pour l’infrastructure de test, n’importe quel composant peut exposer et implémenter des extensions qui héritent de ICapability.
Il est évident que tous les détails ne peuvent pas être communiqués via une interface. Compte tenu de l’exemple précédent, que doit attendre l’extension si CanProvidePerTestCpuConsumption est pris en charge ? Quel type d’informations personnalisées est censé être transmis via iMessageBus par l’infrastructure de test ? La solution est la documentation de la fonctionnalité. Il incombe au propriétaire de la capacité de concevoir, d’expédier et de documenter le plus clairement possible pour aider les implémenteurs qui souhaitent collaborer efficacement avec l’extension qui nécessite la capacité spécifique.
Par exemple, l’extension de rapport TRX permet au framework de test d’implémenter la fonctionnalité nécessaire pour générer avec précision un rapport TRX. L'extension d'enregistrement est incluse dans le package NuGet https://www.nuget.org/packages/Microsoft.Testing.Extensions.TrxReport, mais la capacité à implémenter se trouve uniquement dans le package NuGet contrathttps://www.nuget.org/packages/Microsoft.Testing.Extensions.TrxReport.Abstractions.
En conclusion, récapitulons les principaux aspects du système de capacité :
- Il est essentiel de faciliter la communication claire et stable entre les composants.
- Toutes les capacités doivent hériter de
ICapabilityou d'une interface qui hérite de celle-ci et sont exposées via une collection avec l'interfaceICapabilities. - Il contribue à l'évolution des fonctionnalités sans provoquer de changements incompatibles. Si une certaine fonctionnalité n’est pas prise en charge, une action appropriée peut être effectuée.
- La responsabilité de la conception, de l’expédition et de la documentation de l’utilisation d’une fonctionnalité réside avec le propriétaire de la fonctionnalité. Microsoft.Testing.Platform peut également posséder une fonctionnalité de la même façon que toute autre extension.
Capacités du cadre
La plateforme expose une interface spécialisée nommée ITestFrameworkCapability qui est la base de toutes les fonctionnalités exposées pour les frameworks de test. Ces fonctionnalités sont fournies lors de l’inscription de l’infrastructure de test à la plateforme.
IBannerMessageOwnerCapability
Fonctionnalité facultative de l’infrastructure de test qui permet au framework de test de fournir le message de bannière à la plateforme. Si le message est null ou si la fonctionnalité n’est pas présente, la plateforme utilisera son message de bannière par défaut.
Cette implémentation de fonctionnalité vous permet d’extraire les différentes conditions que l’infrastructure de test peut avoir à prendre en compte lorsque vous décidez si le message de bannière doit être affiché ou non.
La plateforme expose le IPlatformInformation service pour fournir des informations sur la plateforme qui peuvent être utiles lors de la création de votre message de bannière personnalisé.