![\"VedaVersum](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild1-3.png\")
VedaVersum card entity<\/p><\/div>\r\n
Im Moment sind diese Mutation und die 3 Abfragen noch nicht implementiert und f\u00fchren keine relevanten Aktionen mit unserer Entit\u00e4t durch. Nun ist es an der Zeit, die Datenbank zu w\u00e4hlen, in der unsere Kartenliste gespeichert werden soll. Wir haben hier viele M\u00f6glichkeiten. Wir k\u00f6nnen eine relationale Datenbank wie Oracle oder MS SQL Server verwenden. Aber das sind Industriegiganten, die unter hoher Last arbeiten und Hunderte von Transaktionen pro Sekunde durchf\u00fchren. Das leichtgewichtige SQLite<\/a> ist eher f\u00fcr kleine Anwendungen geeignet. Die wichtigsten Vorteile von SQLite sind folgende:<\/p>\r\n Andererseits erfordert SQLite, wie jede relationale Datenbank, die Definition eines stark typisierten Datenbankschemas. Zum Beispiel k\u00f6nnen wir in unserer VedaVersum-Entit\u00e4t in Zukunft einige andere Eigenschaften wie das Flag „Archiviert“ definieren. Im Falle einer relationalen Datenbank ist dies eine einschneidende \u00c4nderung, die einige Anstrengungen erfordert, um Schemamigrationen mit bereits bestehenden Datenbanken zu erm\u00f6glichen. Sie sind gerechtfertigt, wenn wir ein reichhaltiges, gut strukturiertes, denormalisiertes Datenmodell haben, das sich nicht allzu oft \u00e4ndert. Aber in unserem Fall sind die VedaVersum-Entit\u00e4ten nur eine Liste von Dokumenten. NoSQL-Datenbanken sind die perfekte Datenbank, um Listen von Dokumenten zu speichern. Aus diesem Grund werden wir MongoDB<\/a> verwenden. Dies ist der Hauptakteur in der Welt der NoSQL-Datenbanken. Sie ist kostenlos und Open-Source. Sie speichert Daten als Liste von JSON-Dokumenten und ben\u00f6tigt kein stark typisiertes Datenbankschema. Au\u00dferdem bietet sie wie alle seri\u00f6sen Datenbanken hohe Leistung, Skalierung und Backup-Tools.<\/p>\r\n Wenn Sie noch nie Mongo in Ihrem Entwicklungssystem verwendet haben, sollten Sie zuerst die Datenbank-Engine installieren. Hier sind einige Anweisungen, wie Sie dies tun k\u00f6nnen<\/a>. Ich verwende Docker Desktop<\/a> auf meinem Rechner und habe MongoDB als Docker-Container gestartet.<\/p>\r\n Sobald wir die MongoDB-Engine zum Laufen gebracht haben, k\u00f6nnen wir sie in unserem Projekt verwenden. Es gibt einen MongoDB-Treiber f\u00fcr DotNet<\/a>, den wir in unserem Projekt verwenden werden, also sollten wir zuerst ein Nuget-Paket<\/a> zu unserem Projekt hinzuf\u00fcgen. \u00a0<\/p>\r\n Zweitens sollten wir einen neuen Parameter zu unserer appsettings.json <\/em>mit der Verbindungszeichenfolge<\/a> hinzuf\u00fcgen.<\/p>\r\n Und drittens sollten wir eine neue Schnittstelle IVedaVersumDataAccess <\/em><\/strong>und einen VedaVersumDataAccess-Dienst definieren, der diese Schnittstelle implementiert.<\/p>\r\n Wir haben die Datenzugriffsschnittstelle mit CRUD-Operationen definiert. Wir werden diese Schnittstelle in unseren Mutationen und Abfragen verwenden. Und hier beschreibe ich kurz die Implementierung des Datenzugriffs selbst.<\/p>\r\n VedaVersumDataAccess.cs<\/a><\/p>\r\n\r\n\r\n startup.cs<\/p>\r\n\r\n\r\n Den vollst\u00e4ndigen Code finden Sie im GitHub<\/a>-Repository. Wie Sie sehen k\u00f6nnen, ist es ziemlich einfach, MongoDB in ASP.Net Core-Anwendungen zu verwenden. Und hier sind unsere API-Methoden in Betrieb:<\/p>\r\n\r\n\r\n\r\n Create Card:<\/p>\r\n\r\n\r\n\r\n Read All Cards:<\/p>\r\n\r\n\r\n\r\n Update card:<\/p>\r\n\r\n\r\n\r\n Wir haben die Datenpersistenz in unserer Anwendung implementiert! Juhu!\u00a0<\/p>\r\n\r\n\r\n\r\n Nun ist es an der Zeit, ein wenig \u00fcber die Querverweise zwischen Datenobjekten und die Leistung zu sprechen. Wie Sie bereits bemerkt haben, verf\u00fcgt jede knowledge card \u00fcber eine Liste von zugeh\u00f6rigen card Ids. Die Karten werden in der Datenbank mit dieser Struktur gespeichert:<\/p>\r\n\r\n\r\n\r\n So verweist „card two“ auf „card on“, „card three“ auf „card two und one“ und so weiter. Wenn wir alle Karten abrufen, ist das vielleicht kein gro\u00dfes Problem. Aber was ist, wenn die Client-Anwendung nur die „card three“ und alle ihre Abh\u00e4ngigkeiten abrufen m\u00f6chte, sieht unsere Abfrage wie folgt aus:<\/p>\r\n\r\n\r\n\r\n F\u00fcr verwandte Karten haben wir nur Ids, und um deren Inhalt zu erhalten, muss der Client dieselbe Abfrage zwei weitere Male aufrufen. Und wenn es mehr als zwei verwandte Karten gibt, steigt die Anzahl der Anfragen vom Client an den Server dramatisch an. Diese Situation ist bei REST-API \u00fcblich und wird als „n+1-Problem“ bezeichnet.<\/p>\r\n Gl\u00fccklicherweise ist eine der Aufgaben von GraphQL, dieses n+1 Problem zu beseitigen. Wir k\u00f6nnen einen Abfrage-Hook namens Resolver <\/em><\/strong>definieren. Dieser Resolver erm\u00f6glicht es dem Client, alle verwandten Objekte mit einer Anfrage abzurufen. F\u00fcgen wir diesen Resolver<\/a> zu unserer GraphQL-API f\u00fcr verwandte Karten hinzu:<\/p>\r\n\r\n\r\n Dieser Objekttyp erweitert unser VedaVersumCard-Objekt und f\u00fcgt ihm ein neues Feld hinzu. Und implementiert die Logik zum F\u00fcllen dieses Feldes. Nun m\u00fcssen wir diese neue Objekttyp-Definition zu unserem GraphQL-Server-Setup in startup.cs <\/strong>hinzuf\u00fcgen.<\/p>\r\n\r\n\r\n\r\n <\/p>\r\n\r\n\r\n\r\n Und wir k\u00f6nnen unsere Abfrage erneut ausf\u00fchren:<\/p>\r\n\r\n\r\n\r\n Wie Sie feststellen konnten, gibt es ein zus\u00e4tzliches Feld in der Abfrage namens „relatedCards“, und wir k\u00f6nnen alle Informationen zu verwandten Karten mit einer einzigen Anfrage an den GraphQL-Server abrufen. Wir sind also unser n+1 Problem losgeworden. Bingo!<\/p>\r\n\r\n\r\n\r\n Es gibt noch einen weiteren Punkt. GraphQL erm\u00f6glicht sowohl die Abfrage zusammengeh\u00f6riger Daten durch eine einzige Anfrage als auch die Konstruktion der Anfrage so, dass dieselbe API-Methode mehrfach mit unterschiedlichen Parametern, aber mit nur einer Anfrage aufgerufen werden kann. Ein Beispiel: Die Client-Anwendung hat die IDs von drei Karten. Der Kunde kann die Abfrage so konstruieren, dass er die Details aller 3 Karten mit dieser Abfrage erh\u00e4lt:<\/p>\r\n\r\n\r\n\r\n Es funktioniert perfekt. Ich kann alle Daten abrufen, die ich will, ohne das oben erw\u00e4hnte n+1-Problem. Aber wenn ich neugierig w\u00e4re und einen Logger an den MongoDB-Client anh\u00e4ngen w\u00fcrde, k\u00f6nnte ich sehen, dass der GraphQL-Server mit dieser einen Anfrage 3 nachfolgende Anfragen an die Datenbank gestellt hat.<\/p>\r\n\r\n\r\n\r\n Werfen wir noch einmal einen Blick auf unsere Abfragemethode:<\/p>\r\n\r\n\r\n Trotz der einzigen Abfrage an GraphQL wird der Resolver jedes Mal f\u00fcr jede ID ausgef\u00fchrt. Und jedes Mal verwendet er den Datenzugriff, um eine Karte aus der DB zu holen. Das n+1-Problem besteht also immer noch, aber innerhalb unseres Backend-Servers.<\/p>\r\n Gl\u00fccklicherweise kann GraphQL auch dieses Problem l\u00f6sen. Es gibt ein weiteres Konzept namens DataLoader<\/strong>. Und hier k\u00f6nnen wir es implementieren<\/a>:<\/p>\r\n\r\n\r\n Im Hintergrund kann der GraphQL-Query-Parser also alle CardIds w\u00e4hrend einer einzelnen GraphQL-Query erhalten und diesen DataLoader <\/strong>verwenden, um eine Batch-Datenbankabfrage auszuf\u00fchren. Wenden wir diesen DataLoader auf unseren Abfrageaufl\u00f6ser an:<\/p>\r\n\r\n\r\n Jetzt k\u00f6nnen wir diese GraphQL-Abfrage noch einmal ausf\u00fchren:<\/p>\r\n\r\n\r\n\r\n Und uns die Protokolle anschauen:<\/p>\r\n\r\n\r\n\r\n Es gibt nur eine einzige Batch-Abfrage. Cool, wir haben das n+1-Problem auf allen Ebenen beseitigt und der Kunde kann unsere GraphQL-API mit verschiedenen Abfragekombinationen mit optimaler Leistung nutzen.<\/p>\r\n\r\n\r\n\r\n Zu diesem Zeitpunkt hat der Backend-Service bereits seine Arbeit aufgenommen. Das ist gro\u00dfartig! Und w\u00e4hrend wir alles entwickelt haben, haben wir die Anwendung gestartet und gepr\u00fcft, ob die Autorisierung funktioniert, ob die Persistenz funktioniert, ob Abfragen, Mutationen und Abonnements funktionieren. Und nat\u00fcrlich mussten wir sicherstellen, dass alle Dienste und ihre Abh\u00e4ngigkeiten richtig eingerichtet waren. Wir haben all diese Aktivit\u00e4ten mit „Strawberry Shake“ IDE f\u00fcr GraphQL-Abfragen durchgef\u00fchrt. Wenn wir die Benutzeroberfl\u00e4che entwickeln, \u00fcberpr\u00fcfen wir einige UI-Aktivit\u00e4ten, Benutzerszenarien und wie alles mit dem laufenden Backend zusammenarbeitet. In der Entwicklungsphase machen wir das manuell und „gelegentlich“. Wir decken nicht jedes Szenario und jeden Anwendungsfall ab. Dies wird „Smoke Testing“ genannt – nur um zu pr\u00fcfen, ob die Anwendung zumindest startet und das Hauptszenario ohne gruselige Laufzeitfehler durchlaufen kann. Diese Tests garantieren jedoch nicht, dass unsere Anwendung ordnungsgem\u00e4\u00df funktioniert und f\u00fcr den Produktionseinsatz bereit ist.<\/p>\r\n Bei gro\u00dfen Anwendungen empfiehlt es sich in der Regel, Integrationstestszenarien zu erstellen, die die gesamte Anwendungsfunktionalit\u00e4t abdecken. Diese Integrationstests sollten von einer anderen Person erstellt werden, nicht von demjenigen, der die Anwendung entwickelt hat. In der Regel gibt es im Team eine Rolle namens Quality Assurance Engineer, die f\u00fcr die Testszenarien verantwortlich ist. Integrationstests k\u00f6nnen automatisiert oder manuell f\u00fcr jede Entwicklungsphase durchgef\u00fchrt werden. Integrationstests und Qualit\u00e4tssicherung sind ein gro\u00dfer und wichtiger Teil des Entwicklungsprozesses. Aber das ist eine andere, lange Geschichte.<\/p>\r\n Es gibt jedoch noch einen weiteren wichtigen Teil des Entwicklungsprozesses, den Unit-Test. Dieser Teil liegt in der Verantwortung der Entwickler und sollte eng mit der Entwicklung der Hauptfunktionalit\u00e4t der Anwendung verbunden sein. Es ist g\u00e4ngige Praxis, den Prozess der testgetriebenen Entwicklung<\/a> zu befolgen. Zum Beispiel haben wir in unserer Anwendung die Schnittstelle IVedaVersumDataAccess <\/em><\/strong>mit einigen Methoden zur Bearbeitung der Datenbank definiert. Wir haben diese Schnittstelle mit der Klasse VedaVersumDataAccess<\/em><\/strong> implementiert. Au\u00dferdem haben wir diese Schnittstelle in die Abfrage- und Mutationsaufl\u00f6ser injiziert. Wenn der Client eine Abfrage oder Mutation aufruft, wird der entsprechende Resolver eingeschaltet. Dieser Resolver sollte dann die entsprechende Datenzugriffsmethode aufrufen, die ein vorhersehbares Ergebnis zur\u00fcckliefern sollte. Wir haben das Szenario f\u00fcr den Unit-Test bereits beschrieben. Wir k\u00f6nnen die Testmethoden schreiben, die eine Instanz der Klasse Mutation erzeugen und IVedaVersumDataAccess <\/em><\/strong>in diese Klasse injizieren. Aber im Unit-Test m\u00fcssen wir nicht die echte Datenbank aufrufen. Wir k\u00f6nnen die reale Implementierungsklasse f\u00fcr den Datenzugriff durch eine Mock-Implementierung ersetzen. Und wir k\u00f6nnen diese Mock-Implementierung in der Testmethode manipulieren und pr\u00fcfen, ob eine Methode mit einigen erwarteten Parametern aufgerufen wurde usw.<\/p>\r\n Daher kann ich einen Teil des Programms „abtrennen“ und ein Testszenario schreiben, das diesen bestimmten Zwischenteil unserer Anwendung \u00fcberpr\u00fcft. Und ich kann so viele Szenarien schreiben, wie ich brauche, um die Logik aller Klassen (oder Einheiten) abzudecken, ohne die ganzen komplizierten Abh\u00e4ngigkeiten zwischen verschiedenen Anwendungsmodulen zu konstruieren.<\/p>\r\n Wir haben zum Beispiel die Klasse VedaVersumMutation<\/em><\/strong>. Und die Datenmutationsmethode hat diesen Algorithmus:<\/p>\r\n\r\n\r\n\r\n Und um sicher zu sein, dass dieser Algorithmus richtig funktioniert, sollten wir f\u00fcr jeden Block in diesem Algorithmus ein Testszenario schreiben. Wie Sie sehen k\u00f6nnen, verwendet die Methode eine Datenbank und einen Abo-Senderdienst. Diese beiden Abh\u00e4ngigkeiten werden durch den Konstruktor in die Klasse injiziert:<\/p>\r\n\r\n\r\n Um die Mutationsmethode CardAction <\/em><\/strong>zu testen, sollten wir ein Objekt der Klasse VedaVersumMutation<\/em><\/strong> erstellen und diese Methode aufrufen. Wir k\u00f6nnen aber auch Mock-Objekte von DataAccess <\/em>und EventSeder anstelle <\/em>von echten Objekten in die Tests einf\u00fcgen, die verwendet werden, wenn das Programm im „Produktionsmodus“ l\u00e4uft. Mit diesen Mock-Objekten k\u00f6nnen wir \u00fcberpr\u00fcfen, ob die entsprechenden Methoden mit den entsprechenden Parametern aufgerufen wurden. Daher k\u00f6nnen wir nur diesen speziellen Algorithmus testen und m\u00fcssen uns nicht um die Datenbank und andere Abh\u00e4ngigkeiten k\u00fcmmern.<\/p>\r\n Dazu habe ich ein Testprojekt erstellt, das das NUnit<\/a>-Testframework und die Moq<\/a>-Bibliothek zum Einrichten von Mock-Objekten verwendet. Dies kann Ihnen zeigen, wie Sie diese Methode testen k\u00f6nnen:<\/p>\r\n\r\n\r\n\r\n
2.1. MongoDB einrichten<\/h3>\r\n
![\"IVedaVersumDataAccess](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild2-3.png\")
<\/p>\r\n2.2. Implementierung des Datenzugriffs<\/h3>\r\n
\r\n "ConnectionStrings": {\r\n "mongo": "mongodb:\/\/localhost:27017"\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n public class VedaVersumDataAccess : IVedaVersumDataAccess\r\n {\r\n private const string DatabaseName = "VedaVersum";\r\n private const string VedaVersumCardsCollectionName = "Cards";\r\n private readonly IMongoDatabase _database;\r\n public VedaVersumDataAccess(string mongoDbConnectionString, ILogger<VedaVersumDataAccess> logger)\r\n {\r\n var mongoConnectionUrl = new MongoUrl(mongoDbConnectionString);\r\n var mongoClientSettings = MongoClientSettings.FromUrl(mongoConnectionUrl);\r\n mongoClientSettings.ClusterConfigurator = cb => {\r\n cb.Subscribe<CommandStartedEvent>(e => {\r\n logger.LogDebug($"{e.CommandName} - {e.Command.ToJson()}");\r\n });\r\n };\r\n var client = new MongoClient(mongoClientSettings);\r\n _database = client.GetDatabase(DatabaseName);\r\n }\r\n\r\n \/\/\/ <inheritdoc \/>\r\n public async Task DeleteCard(string cardId)\r\n {\r\n var cardsCollection = _database.GetCollection<VedaVersumCard>(VedaVersumCardsCollectionName);\r\n await cardsCollection.DeleteOneAsync(Builders<VedaVersumCard>.Filter.Where(c => c.Id == cardId));\r\n }\r\n\r\n \/\/\/ <inheritdoc \/>\r\n public async Task<IEnumerable<VedaVersumCard>> GetAll()\r\n {\r\n var cardsCollection = _database.GetCollection<VedaVersumCard>(VedaVersumCardsCollectionName);\r\n var allCards = await cardsCollection.FindAsync(Builders<VedaVersumCard>.Filter.Empty);\r\n return allCards.ToList();\r\n }\r\n \/\/ Code omitted for brevity\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n \/\/ DataAccess\r\n var connectionString = Configuration.GetConnectionString("mongo");\r\n services.AddTransient<IVedaVersumDataAccess, VedaVersumDataAccess>((p) => new VedaVersumDataAccess(\r\n connectionString, \r\n p.GetService<ILogger<VedaVersumDataAccess>>()!));\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n![\"Create](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild3-3.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"Read](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild4-3.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"Update](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild5-2.png\")
<\/figure>\r\n\r\n\r\n\r\n3. GraphQL resolvers und data loaders<\/h2>\r\n\r\n\r\n\r\n
![\"Stored](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild6-2.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"card](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild7-2.png\")
<\/figure>\r\n\r\n\r\n\r\n\r\n public class VedaVersumCardObjectType: ObjectType<VedaVersumCard>\r\n {\r\n protected override void Configure(IObjectTypeDescriptor<VedaVersumCard> descriptor)\r\n {\r\n descriptor\r\n .Field("relatedCards") \/\/ Name of the additional field\r\n .Type<ListType<VedaVersumCardObjectType>>()\r\n .Resolve(async context =>\r\n {\r\n var parent = context.Parent<VedaVersumCard>();\r\n\r\n if(parent.RelatedCardIds == null || parent.RelatedCardIds.Count == 0)\r\n {\r\n return new List<VedaVersumCard>();\r\n }\r\n\r\n var dataAccess = context.Service<IVedaVersumDataAccess>();\r\n return await dataAccess.GetCardsById(parent.RelatedCardIds);\r\n });\r\n }\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n![\"extend](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild8-2.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"Run](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild9-2.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"construct](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild10-1.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"database](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild11-1.png\")
<\/figure>\r\n\r\n\r\n\r\n\r\n \/\/\/ <summary>\r\n \/\/\/ Returns card by ID\r\n \/\/\/ <\/summary>\r\n public async Task<VedaVersumCard?> GetCardById(string cardId)\r\n {\r\n return _dataAccess.GetCardById(cardId);\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n public class VedaVersumCardDataLoader : BatchDataLoader<string, VedaVersumCard>\r\n {\r\n private readonly IVedaVersumDataAccess _vedaVersumDataAccess;\r\n\r\n public VedaVersumCardDataLoader(\r\n IVedaVersumDataAccess vedaVersumDataAccess,\r\n IBatchScheduler batchScheduler,\r\n DataLoaderOptions<string>? options = null) : base(batchScheduler, options)\r\n {\r\n _vedaVersumDataAccess = vedaVersumDataAccess;\r\n }\r\n\r\n \/\/ This method collects all CardIds during the single GraphQL query and executes database query once far all CardIds\r\n protected override async Task<IReadOnlyDictionary<string, VedaVersumCard>> LoadBatchAsync(\r\n IReadOnlyList<string> keys, CancellationToken cancellationToken)\r\n {\r\n var allCardsByIds = await _vedaVersumDataAccess.GetCardsById(keys);\r\n return allCardsByIds.ToDictionary(c => c.Id);\r\n }\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n \/\/\/ <summary>\r\n \/\/\/ Returns card by ID\r\n \/\/\/ <\/summary>\r\n public async Task<VedaVersumCard?> GetCard(string cardId, VedaVersumCardDataLoader dataLoader)\r\n {\r\n return await dataLoader.LoadAsync(cardId, CancellationToken.None);\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n![\"Execute](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild12-1.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"Execute](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild13-1.png\")
<\/figure>\r\n\r\n\r\n\r\n4. Unit testing<\/h2>\r\n\r\n\r\n\r\n
![\"the](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild14-1.png\")
<\/figure>\r\n\r\n\r\n\r\n\r\n public class VedaVersumMutation\r\n {\r\n private readonly ITopicEventSender _eventSender;\r\n private readonly IVedaVersumDataAccess _dataAccess;\r\n\r\n\r\n public VedaVersumMutation(ITopicEventSender eventSender, IVedaVersumDataAccess dataAccess)\r\n {\r\n _eventSender = eventSender;\r\n _dataAccess = dataAccess;\r\n }\r\n \/\/ Code omitted for brevity\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n public class VedaVersumMutationTests\r\n {\r\n \/\/\/ <summary>\r\n \/\/\/ Event sender mock object\r\n \/\/\/ <\/summary>\r\n private Mock<ITopicEventSender> _eventsSenderMock = new Mock<ITopicEventSender>();\r\n \/\/\/ <summary>\r\n \/\/\/ DataAccess mock object\r\n \/\/\/ <\/summary>\r\n private Mock<IVedaVersumDataAccess> _dataAccessMock = new Mock<IVedaVersumDataAccess>();\r\n private VedaVersumMutation MutationClassToTest;\r\n\r\n [SetUp]\r\n public void Setup()\r\n {\r\n MutationClassToTest = new VedaVersumMutation(_eventsSenderMock.Object, _dataAccessMock.Object);\r\n }\r\n\r\n [Test]\r\n public async Task ShouldCallInsertNewCardDataAccessMethodOnCardCreate()\r\n {\r\n \/\/ Arrange. Mocking dataAccess behavior\r\n _dataAccessMock.Setup(d=> d.InsertNewCard(It.IsAny<string>(), It.IsAny<string>(), null, It.IsAny<User>()))\r\n .ReturnsAsync(ExpectedCardData);\r\n\r\n \/\/ Action\r\n var resultCard = await MutationClassToTest.CardAction(\r\n VedaVersumCardAction.Create, \r\n ExpectedCardData.Title,\r\n ExpectedCardData.Content,\r\n relatedCards: null,\r\n cardId: null,\r\n TestUser);\r\n\r\n \/\/ Assert\r\n Assert.NotNull(resultCard);\r\n Assert.IsNotEmpty(resultCard.Id);\r\n Assert.AreEqual(ExpectedCardData.Title, resultCard.Title);\r\n \/\/ Check if data accessor's InsertNewCard method has been called only once and with appropriate parameters\r\n _dataAccessMock.Verify(d => d.InsertNewCard(\r\n ExpectedCardData.Title, \r\n ExpectedCardData.Content,\r\n null,\r\n It.IsAny<User>()\r\n ), Times.Once);\r\n \/\/ Check if EventSender's method SendAsync has been called only once\r\n _eventsSenderMock.Verify(s => s.SendAsync<string, CardActionMessage>(\r\n nameof(VedaVersumSubscription.CardChanged), \r\n It.Is<CardActionMessage>(m => m.Action == VedaVersumCardAction.Create),\r\n It.IsAny<CancellationToken>()),\r\n Times.Once);\r\n }\r\n\r\n [TestCase(VedaVersumCardAction.Update)]\r\n [TestCase(VedaVersumCardAction.Delete)]\r\n public void ShouldThrowExceptionIfActionIsNotCreateAndCardIdIsNull(VedaVersumCardAction action)\r\n {\r\n Assert.ThrowsAsync<ArgumentNullException>(() => MutationClassToTest.CardAction(\r\n action, \r\n ExpectedCardData.Title,\r\n ExpectedCardData.Content,\r\n relatedCards: null,\r\n cardId: null,\r\n TestUser));\r\n }\r\n\r\n \/\/ Other test scenarios are omitted\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n