Développement d'une équipe pour interroger les données de la base de données

Actuellement, je suis engagé dans la mise en œuvre de l'interaction avec le fournisseur de services KYC. Comme d'habitude, rien de cosmique. Il vous suffit de sélectionner dans votre base de données un ensemble assez important de copies de divers enregistrements, de les télécharger vers le fournisseur de services et de demander au fournisseur d'enregistrements de les vérifier.

L'étape initiale du traitement contient une douzaine d'opérations identiques avec l'envoi de demandes de récupération de données d'un utilisateur spécifique à partir de diverses tables de base de données. On suppose que dans ce cas, une partie assez importante du code peut être réutilisée comme abstraction de Request . Je vais essayer de suggérer comment cela pourrait être utilisé. J'écrirai le premier test:

 describe('Request', () => { const Request = require('./Request'); it('execute should return promise', () => { const request = new Request(); request.execute().then((result) => { expect(result).toBeNull(); }); }); }); 

Ça a l'air bien? Peut-être imparfait, mais à première vue, il semble que Request soit essentiellement une qui renvoie Promise avec le résultat? De cela, il est tout à fait possible de commencer. Je vais esquisser le code pour que le test puisse être exécuté.

 class Request { constructor(){} execute(){ return new Promise((resolve, reject) => { resolve(null); }); } } module.exports = Request; 

npm test et observe le point vert du test terminé dans la console.

Alors. J'ai une demande, et elle peut être exécutée. En réalité, cependant, je devrai en quelque sorte informer ma demande du tableau dans lequel il devrait rechercher les données nécessaires et des critères auxquels ces données devraient répondre. Je vais essayer d'écrire un nouveau test:

 it('should configure request', () => { const options = { tableName: 'users', query: { id: 1 } }; request.configure(options); expect(request.options).toEqual(options); }); 

Ok? À mon avis, tout à fait. Étant donné que j'ai déjà deux tests qui utilisent une instance de la variable de request , je vais initialiser cette variable dans une méthode spéciale qui est exécutée avant le début de chaque test. Ainsi, dans chaque test, j'aurai une nouvelle instance de l'objet de requête:

 let request = null; beforeEach(() => { request = new Request(); }); 

J'implémente cette fonctionnalité dans la classe de demande, j'y ajoute une méthode qui enregistre les paramètres dans la variable d'instance de classe, comme le montre le test.

 configure(options){ this.options = options; } 

Je lance les tests et maintenant je vois deux points verts. Deux de mes tests ont réussi. Cependant. Il est supposé, cependant, que mes requêtes seront adressées à la base de données. Maintenant, il vaut probablement la peine d'essayer de voir de quel côté la demande recevra des informations sur la base de données. Je vais revenir aux tests et écrire du code:

 const DbMock = require('./DbMock'); let db = null; beforeEach(() => { db = new DbMock(); request = new Request(db); }); 

Il me semble qu'une telle version classique de l'initialisation via le constructeur satisfait pleinement mes exigences actuelles.

Naturellement, je ne vais pas utiliser les tests unitaires pour utiliser l'interface avec la vraie base de données MySQL avec laquelle notre projet fonctionne. Pourquoi? Parce que:

1. Si, à ma place, un de mes collègues doit travailler sur cette partie du projet et effectuer des tests unitaires, alors avant de pouvoir faire quoi que ce soit, il devra consacrer du temps et des efforts à installer et configurer sa propre instance du serveur MySQL.
2. Le succès des tests unitaires dépendra de l'exactitude du remplissage préliminaire des données utilisé par la base de données du serveur MySQL.
3. Le temps d'exécution des tests à l'aide de la base de données MySQL sera considérablement plus long.

D'accord. Et pourquoi, par exemple, ne pas utiliser de base de données en mémoire dans les tests unitaires? Il fonctionnera rapidement et le processus de configuration et d'initialisation peut être automatisé. C'est vrai, mais pour le moment je ne vois aucun avantage à utiliser cet outil supplémentaire. Il me semble que mes besoins actuels sont plus rapides et moins chers (pas besoin de passer du temps à étudier) en utilisant des classes et des méthodes de stubs et de objets, qui ne feront que simuler le comportement d'interfaces censées être utilisées dans des conditions de combat.

Au fait. Au combat, je suggère d'utiliser la bibliothèque en conjonction avec knex . Pourquoi? Parce que suite à la documentation sur l'installation, la configuration et l'utilisation de ces deux outils, j'ai réussi à créer et exécuter une requête dans la base de données en quelques minutes.

Qu'est-ce qui en découle? Il en résulte que je devrais modifier le code de la classe Request pour que l'exécution de la requête corresponde aux interfaces exportées par mes outils de combat. Alors maintenant, le code devrait ressembler à ceci:

 class Request { constructor(db){ this.db = db; } configure(options){ this.options = options; } execute(){ const table = this.db.Model.extend({ tableName: this.options.tableName }); return table.where(this.options.query).fetch(); } } module.exports = Request; 

Je vais exécuter les tests et voir ce qui se passe. Ouais. DbMock sûr, je n'ai pas le module DbMock , donc la première chose que je fais est d'implémenter un stub pour lui:

 class DbMock { constructor(){} } module.exports = DbMock; 

Je vais relancer les tests. Et maintenant La princesse Jasmine me dit Jasmine que mon DbMock pas la propriété Model . Je vais essayer de trouver quelque chose:

 class DbMock { constructor(){ this.Model = { extend: () => {} }; } } module.exports = DbMock; 

Relancer les tests. Maintenant, l'erreur est que dans mon test unitaire, j'exécute la requête sans d'abord définir ses paramètres à l'aide de la méthode configure . Je corrige ceci:

 const options = { tableName: 'users', query: { id: 1 } }; it('execute should return promise', () => { request.configure(options); request.execute().then((result) => { expect(result).toBeNull(); }); }); 

Comme j'ai déjà utilisé une instance de la variable options dans deux tests, je l'ai placée dans le code d'initialisation de la suite de tests entière et réexécute les tests.

Comme prévu, la méthode extend , les propriétés du Model , de la classe DbMock nous a renvoyé undefined , donc, naturellement, notre requête n'a aucun moyen d'appeler la méthode where .

Je comprends déjà que la propriété Model de la classe DbMock doit être implémentée en dehors de la classe DbMock - DbMock . Tout d'abord, étant donné que l'implémentation des nécessaire pour que les tests existants s'exécutent, il faudra trop d'étendues imbriquées lors de l'initialisation de la propriété Model directement dans la classe DbMock . Ce sera complètement impossible à lire et à comprendre ... Et cela, cependant, ne m'empêchera pas de faire une telle tentative, car je veux m'assurer d'avoir encore la possibilité d'écrire quelques lignes de code et de réussir les tests.

Alors. Inspirez, expirez, les faibles de cœur quittent la pièce. Compléter l'implémentation du constructeur DbMock . Ta-daaaammmmm ....

 class DbMock { constructor(){ this.Model = { extend: () => { return { where: () => { return { fetch: () => { return new Promise((resolve, reject) => { resolve(null); }); } }; } }; } }; } } module.exports = DbMock; 

Tin! Cependant, avec une main ferme, exécutez les tests et assurez-vous que Jasmine nous montre à nouveau les points verts. Et cela signifie que nous sommes toujours sur la bonne voie, bien que quelque chose ait gonflé de manière inappropriée.

Et ensuite? On peut voir à l'œil nu que la propriété Model d'une pseudo-base de données doit être implémentée comme quelque chose de complètement séparé. Bien qu'inadapté, il n'est pas clair comment il devrait être mis en œuvre.

Mais je sais avec certitude que je vais stocker les enregistrements dans cette pseudo-base de données en ce moment dans les tableaux les plus ordinaires. Et comme pour les tests existants, je n'ai besoin que de simuler la table des users , pour commencer je vais implémenter un tableau d'utilisateurs, avec un enregistrement. Mais d'abord, je vais écrire un test:

 describe('Users', () => { const users = require('./Users'); it('should contain one user', () => { expect(Array.isArray(users)).toBeTruthy(); expect(users.length).toEqual(1); const user = users[0]; expect(user.Id).toEqual(1); expect(user.Name).toEqual('Jack'); }); }); 

Je lance des tests. Je m'assure qu'ils ne passent pas, et j'implémente mon simple container avec l'utilisateur:

 const Users = [ { Id: 1, Name: 'Jack' } ]; module.exports = Users; 

Maintenant, les tests sont effectués, et il me semble que sémantiquement le Model , dans le package de la bookshell , est le fournisseur de l'interface pour accéder au contenu de la table dans la base de données. Ce n'est pas pour rien que nous passons un objet avec un nom de table à la méthode extend . Pourquoi on l'appelle extend , et non par exemple get , je ne sais pas. C'est peut-être juste un manque de connaissances sur l'API de la bookshell .

Eh bien, que Dieu le bénisse, pour l'instant j'ai une idée en tête sur le sujet du test suivant:

 describe('TableMock', () => { const container = require('./Users'); const Table = require('./TableMock'); const users = new Table(container); it('should return first item', () => { users.fetch({ Id: 1 }).then((item) => { expect(item.Id).toEqual(1); expect(item.Name).toEqual('Jack'); }); }); }); 

Étant donné que pour le moment j'ai besoin d'une implémentation qui simule uniquement la fonctionnalité d'un véritable pilote de stockage, je nomme les classes en conséquence, en ajoutant le suffixe Mock :

 class TableMock { constructor(container){ this.container = container; } fetch() { return new Promise((resolve, reject) => { resolve(this.container[0]); }); } } module.exports = TableMock; 

Mais le fetch pas la seule méthode que j'ai l'intention d'utiliser dans la version combat, alors j'ajoute un autre test:

 it('where-fetch chain should return first item', () => { users.where({ Id: 1 }).fetch().then((item)=> { expect(item.Id).toEqual(1); expect(item.Name).toEqual('Jack'); }); }); 

Le lancement dont, comme prévu, affiche un message d'erreur pour moi. Je complète donc l'implémentation de TableMock avec la méthode where :

 where(){ return this; } 

Maintenant, les tests sont en cours d'exécution et vous pouvez passer à la rubrique de l'implémentation de la propriété Model dans la classe DbMock . Comme je l'ai déjà suggéré, ce sera un certain fournisseur d'instances d'objet de type TableMock :

 describe('TableMockMap', () => { const TableMock = require('./TableMock'); const TableMockMap = require('./TableMockMap'); const map = new TableMockMap(); it('extend should return existent TableMock', () => { const users = map.extend({tableName: 'users'}); expect(users instanceof TableMock).toBeTruthy(); }); }); 

Pourquoi TableMockMap , car sémantiquement c'est tout. Juste au lieu du nom de la méthode get , le nom de la méthode d' extend est utilisé.

Depuis que le test plante, nous faisons une implémentation:

 const Users = require('./Users'); const TableMock = require('./TableMock'); class TableMockMap extends Map{ constructor(){ super(); this.set('users', Users); } extend(options){ const container = this.get(options.tableName); return new TableMock(container); } } module.exports = TableMockMap; 

Exécutez les tests et voyez six points verts dans la console. La vie est belle.

Il me semble en ce moment que vous pouvez déjà vous débarrasser de la initialisation dans le constructeur de la classe DbMock , en utilisant le merveilleux TableMockMap . Nous ne la repousserons pas, d'autant plus qu'il serait bien d'avoir déjà du thé. La nouvelle implémentation est délicieusement élégante:

 const TableMockMap = require('./TableMockMap'); class DbMock { constructor(){ this.Model = new TableMockMap(); } } module.exports = DbMock; 

Exécutez les tests ... et oups! Notre test le plus important tombe. Mais c'est même bien, car c'était un talon de test et maintenant nous devons juste le corriger:

 it('execute should return promise', () => { request.configure(options); request.execute().then((result) => { expect(result.Id).toEqual(1); expect(result.Name).toEqual('Jack'); }); }); 

Les tests ont réussi. Et maintenant, vous pouvez faire une pause, puis revenir à la finalisation du code de requête résultant, car il est encore très, très loin d'être parfait, mais même à partir d'une interface simple à utiliser, malgré le fait que les données l'utilisant proviennent de les bases peuvent déjà être reçues.