Test des appels de firebase database C #

Tout d’abord, abordons la terminologie ici. Tout ce que je recherche indique: “Les tests unitaires ne touchent pas la firebase database!” Je ne veux pas d’un test unitaire. Je veux un test qui, lorsque j’envoie des données à une firebase database, sache que celle-ci est correctement sauvegardée (et que d’autres opérations sont testées). J’ai une couche de référentiel qui accepte essentiellement un DTO, puis mappe ce DTO vers un modèle de structure d’entité, puis enregistre ce modèle dans la firebase database.

Je dois pouvoir vérifier que l’envoi d’un DTO à ces méthodes est effectivement enregistré dans la firebase database.

Un exemple de signature de méthode sur le référentiel est:

public bool Save(SomeObjectDTO someObject)

J’ai juste besoin de tester si cette méthode renvoie ou non la valeur true.

Quelle est la meilleure façon de configurer des tests lorsque mes méthodes appelées sont celles qui sont enregistrées dans la firebase database?

En outre, existe-t-il un moyen standard de configurer une firebase database de test vierge? Ce serait bien si, lorsque je clique sur “Exécuter les tests”, il construit une firebase database vide, la remplit avec les données initiales nécessaires, puis effectue toutes les opérations CRUD (tous mes appels dans le référentiel) pour vérifier qu’elles sont toutes enregistrées comme elles le sont. devrait être.

Je m’excuse si cela a déjà été répondu, mais dans tout ce que j’ai cherché, quelqu’un a dit que vous ne devriez pas tester les appels de firebase database, ou des personnes qui se moquaient de ce qui se moque, ce qui n’est pas vraiment utile ici.

Je veux juste un exemple et / ou une pratique standard sur la manière dont ces types de tests doivent être configurés.

Ce que vous recherchez s’appelle des tests d’intégration et est tout aussi important que d’écrire des tests unitaires. De nombreux bogues potentiels exposés par votre fournisseur de données sous-jacent ne risquent pas de se moquer de votre référentiel (clés étrangères non valides, données nulles pour quelque chose marqué comme non nul, etc.).

Je pense qu’il est également important de tester le même fournisseur de firebase database que votre système de production, sinon vous risquez de manquer un comportement spécifique à l’implémentation. J’utilise Azure SQL pour un projet et au lieu de créer une instance SQL CE en mémoire, je dispose d’une firebase database distincte sur Azure utilisée uniquement pour mes tests d’intégration.

Si vous utilisez XUnit (et je suis sûr qu’il existe pour d’autres frameworks de test), il existe un atsortingbut pratique [AutoRollback] qui [AutoRollback] automatiquement votre transaction après chaque test.

 [Fact] [AutoRollback] public void AddProductTest_AddsProductAndResortingevesItFromTheDatabase() { // connect to your test db YourDbContext dbContext = new YourDbContext("TestConnectionSsortingng") dbContext.Products.Add(new Product(...)); // get the recently added product (or whatever your query is) var result = dbContext.Single(); // assert everything saved correctly Assert.Equals(...); }

Une fois le test terminé, votre firebase database sera à nouveau vierge (ou quoi que ce soit avant que vous ayez exécuté le test).

Pour tester une firebase database lors de l’utilisation d’EntityFramework, voici comment je lance:

Tout d’abord, je définis la classe qui ObjectContext à ObjectContext avec une fabrique pour ObjectContext si nécessaire: dans mon cas, je travaille dans un service NT, le contexte ne vit donc pas pendant une requête, ou dans un autre domaine: YMMV mais Si vous testez un composant, vous pouvez travailler en totale isolation sans trop de problèmes, car votre usine pour le contexte Web recherchera certainement le contexte dans la demande: ne l’initialisez / ne le fermez pas dans votre classe DAL.

 public DataAccessClass: IWorkOnStuff { public Func DataAccessFactory { get; internal set; } private ssortingng ConnectionSsortingng; public PortailPatientManagerImplementation(ssortingng connectionSsortingng) { ConnectionSsortingng = connectionSsortingng; DataAccessFactory = () => { return new DataEntities(ConnectionSsortingng); }; } /* interface methods */ public IEnumerable GetTheStuff(SomeParameters params) { using (var context = DataAccessFactory()) { return context.Stuff.Where(stuff => params.Match(stuff)); } } }

Ce qui est intéressant, c’est que lorsque vous voulez tester cela, vous pouvez utiliser une bibliothèque appelée Effort , qui vous permet de mapper une firebase database en mémoire. Pour ce faire, créez simplement votre classe et, dans la configuration de test, indiquez à Effort de le prendre à partir d’ici:

 public class TestDataAccessClass { public DataAccessClass Target { get; set; } protected int Calls = 0; protected DataEntities DE; [SetUp] public void before_each_test() { Target = new DataAccessClass(ssortingng.Empty); Calls = 0; FullAccessCalls = 0; var fakeConnection = "metadata=res://*/bla.csdl|res://*/bla.ssdl|res://*/bla.msl;provider=System.Data.SqlClient"; DE = Effort.ObjectContextFactory.CreateTransient(fakeConnection); Target.DataAccessFactory = () => { Calls++; return DE; }; SetupSomeTestData(DE); } }

Dans SetupSomeTestData ajoutez simplement les entités souhaitées (références, etc.) et vous pouvez maintenant appeler vos méthodes pour vous assurer que vos données proviennent du ObjectContext tel que défini dans votre configuration.

Curieusement, comme le note mfanto, il s’agit d’un test d’intégration, pas d’un test unitaire, mais comme il le dit lui-même :

Cela ne sonne pas comme une unité mais comme des tests d’intégration pour moi!

Vous avez raison, j’utilise le terme “tests unitaires” dans le titre pour des raisons de référencement 🙂 De plus, la plupart des gens ne semblent pas connaître les différences qui les séparent.

Je ne sais pas si c’est le meilleur moyen de tester par rapport à un DAL Entity Framework; Il m’a fallu un certain temps pour arriver à cette solution et je trouve que ce n’est pas sans fondement, mais je vais suivre cette question afin de voir quelles autres solutions sont proposées.