Heute fanden mehrdimensionale Tests des Datenanforderungsteams aus der Datenbank statt, deren Entwicklungsprozess hier und hier ausführlich und sehr ausführlich beschrieben wurde .
Was haben die Tests gezeigt? Das Team arbeitet, aber ... in dem Anwendungsfall, in dem Sie es verwenden müssen, ist es unpraktisch, es zu konfigurieren.
Wie bereits in der ersten Veröffentlichung erwähnt, sollten für jeden Datenaustausch mit dem KYC-Dienstanbieter so viele Datensätze wie möglich aus der Datenbank ausgewählt werden. Mehr als ein Dutzend. Das Verhalten des Algorithmus zum Extrahieren von Datensätzen aus der Datenbank im Rahmen jeder Anforderung ist identisch, nur die Einstellungen werden geändert. Wenn ich zuerst einen Integrationstest schreiben würde, der einen Anwendungsfall für den Kampf demonstriert, würde ich verstehen, welche wichtigen Details nicht übersehen werden sollten. Ein Integrationstest könnte folgendermaßen aussehen:
describe('configure and run database requests', () => { const context = require('../src/storage/requestContext'); const requestHandler = require('../src/storage/requestHandler'); it('should get full recordset from db', (done) => { for(let key of context.rules.keys()) { let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle); } const assert = checkDataIsReady.bind(context, [done]); context.store.subscribe(assert); const note = { Id: 1, UserId: 38 }; const start = { type: 'NOTE', note }; context.store.dispatch(start); }); function checkDataIsReady(args) { if(notAllDataIsHereYet()) return; checkUserRecord();
Die Kardinalität des Unterschieds besteht darin, dass wir die Regeln für die context.rules
im Voraus vorbereiten und im Wörterbuch context.rules
. Dieses Wörterbuch und andere Objekte, die zum Ausführen von Abfragen und zum Speichern der Ergebnisse erforderlich sind, sind in dem Kontext enthalten, den wir aus dem vorkonfigurierten Datenbankspeicher context.db
, dem vorkonfigurierten context.store
und dem oben genannten Wörterbuch context.store
.
Gleichzeitig können die Abfragekonfigurationsregeln sowohl normale Zeichenfolgendaten enthalten, z. B. den Namen der Tabelle, aus der die Daten angefordert werden sollen, als auch Factory-Methoden, die Abfragen an die Datenbank generieren, und Versandmethoden, die Aktionen an den Statuscontainer senden. In dieser Situation sieht die Konfiguration der erforderlichen Befehle völlig anders aus, als der vorhandene Code vorschlägt.
Eine solche Architekturlösung ermöglicht es uns unter anderem, verschiedene Ebenen von KYC-Prüfungen zu definieren, einfach in Form von Stringsätzen ( Set
), die beim Speichern von Abfragekonfigurationsregeln als Schlüssel verwendet werden. Wenn wir beispielsweise nur personenbezogene Daten und eine Adresse zur Überprüfung senden möchten, fügen wir einfach die entsprechenden Schlüssel in das Rowset ein: user
, person
und address
.
Der obige Test zeigt die maximale Konfigurationsoption, bei der das gesamte Regelwörterbuch umgangen und ein verallgemeinerter Abfragecode für bestimmte Tabellen eingerichtet wird. Wie Sie im folgenden Code sehen können, erfolgt der tatsächliche Start von Anforderungen als Reaktion auf die Ereignisse der Statuscontaineränderung:
let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle);
Es wird heute keine Beschreibung des Implementierungsprozesses in allen Details geben, da er noch nicht stattgefunden hat ...