Je cherchais la même réponse, et pour le moment la documentation de xUnit est très utile en ce qui concerne la façon d'implémenter les Class Fixtures et les Collection Fixtures qui donnent aux développeurs une large gamme de fonctionnalités de mise en place/arrêt au niveau de la classe ou du groupe de classes. Ceci est en accord avec la réponse de Geir Sagberg, et donne une bonne implémentation squelette pour illustrer ce à quoi cela devrait ressembler.
https://xunit.net/docs/shared-context
Luminaires de collection Quand l'utiliser : lorsque vous voulez créer un contexte de test unique et le partager entre les tests de plusieurs classes de test, et le faire nettoyer après la fin de tous les tests des classes de test.
Parfois, vous voudrez partager un objet fixe entre plusieurs classes de test. L'exemple de la base de données utilisée pour les fixtures de classe est un excellent exemple : vous pouvez vouloir initialiser une base de données avec un ensemble de données de test, puis laisser ces données de test en place pour qu'elles soient utilisées par plusieurs classes de test. Vous pouvez utiliser la fonction de fixation de collection de xUnit.net pour partager une instance d'objet unique entre les tests de plusieurs classes de test.
Pour utiliser les dispositifs de collecte, vous devez suivre les étapes suivantes :
Créez la classe d'appareils, et placez le code de démarrage dans le constructeur de la classe d'appareils. Si la classe d'objets fixes doit effectuer un nettoyage, implémentez IDisposable sur la classe d'objets fixes et placez le code de nettoyage dans la méthode Dispose(). Créez la classe de définition de collection, en la décorant avec l'attribut [CollectionDefinition], en lui donnant un nom unique qui identifiera la collection de test. Ajoutez ICollectionFixture<> à la classe de définition de collection. Ajoutez l'attribut [Collection] à toutes les classes de test qui feront partie de la collection, en utilisant le nom unique que vous avez fourni à l'attribut [CollectionDefinition] de la classe de définition de collection de test. Si les classes de test ont besoin d'accéder à l'instance du dispositif, ajoutez-la en tant qu'argument du constructeur, et elle sera fournie automatiquement. Voici un exemple simple :
public class DatabaseFixture : IDisposable
{
public DatabaseFixture()
{
Db = new SqlConnection("MyConnectionString");
// ... initialize data in the test database ...
}
public void Dispose()
{
// ... clean up test data from the database ...
}
public SqlConnection Db { get; private set; }
}
[CollectionDefinition("Database collection")]
public class DatabaseCollection : ICollectionFixture<DatabaseFixture>
{
// This class has no code, and is never created. Its purpose is simply
// to be the place to apply [CollectionDefinition] and all the
// ICollectionFixture<> interfaces.
}
[Collection("Database collection")]
public class DatabaseTestClass1
{
DatabaseFixture fixture;
public DatabaseTestClass1(DatabaseFixture fixture)
{
this.fixture = fixture;
}
}
[Collection("Database collection")]
public class DatabaseTestClass2
{
// ...
}
xUnit.net traite les objets fixes de collection de la même manière que les objets fixes de classe, sauf que la durée de vie d'un objet fixe de collection est plus longue : il est créé avant que les tests ne soient exécutés dans l'une des classes de test de la collection, et il ne sera pas nettoyé avant que toutes les classes de test de la collection aient fini de s'exécuter.
Les collections de tests peuvent également être décorées avec IClassFixture<>. xUnit.net traite cela comme si chaque classe de test individuelle dans la collection de tests était décorée avec le fixage de classe.
Les collections de tests influencent également la manière dont xUnit.net exécute les tests lorsqu'ils sont exécutés en parallèle. Pour plus d'informations, voir Exécution de tests en parallèle.
Remarque importante : les accessoires doivent se trouver dans le même montage que l'essai qui les utilise.
