Knex: Comment écrire des tests unitaires pour les méthodes qui utilisent Knex.

J'ai apparemment fait un mauvais travail de recherche sur Google la nuit dernière, parce que je viens de réessayer avec "comment écrire des tests unitaires atomiques avec knex.js", et j'obtiens des résultats intéressants. Je vais les lire maintenant. Je publierai à nouveau si j'apprends quelque chose.

Non - rien obtenu. Résumé par ordre chronologique des sources:

21/04/2016 https://medium.com/@jomaora/knex -bookshelf-mocks-and-unit-tests-cca627565d3

Stratégie: utilisez mock-knex . Je ne veux pas me moquer de la base de données - je veux tester mes méthodes par rapport à une base de données MySQL réelle pour garantir un comportement correct - mais j'ai quand même jeté un coup d'œil à mock-knex ... c'est peut-être la bibliothèque la moins bien conçue Je l'ai jamais rencontré. :(

28/04/2016 http://mherman.org/blog/2016/04/28/test-driven-development-with-node/

Stratégie: Rollback / remigrate / reseed DB après chaque test. Cela semble être une surcharge pour chaque test, et sera terriblement lent. La concurrence pourrait être obtenue en générant un UUID pour le nom de la base de données de chaque test, mais cela semble être une solution horrible par rapport à l'élégance des transactions ...

23/09/2015 http://stackoverflow.com/a/32749601/210867

Stratégie: utilisez sqlite pour les tests, créez / détruisez DB pour chaque test. J'ai couvert les deux raisons pour lesquelles je n'aime pas cette approche ci-dessus.

Donc ... toujours à la recherche de suggestions et de conseils supplémentaires sur le fonctionnement réel des transactions Knex, ainsi que sur la manière de les appliquer correctement à mon cas d'utilisation.

@odigity a bien résumé les mauvaises pratiques de test 👍

Nous faisons nos tests "unitaires" comme ceci:

1. Démarrez le système, initialisez la base de données et exécutez les migrations

2. Avant chaque test, nous tronquons toutes les tables et séquences (avec le package knex-db-manager)

3. Insérer les données requises pour le cas de test (nous utilisons l'ORM d'objection.js basé sur knex pour ce qui nous permet d'insérer des hiérarchies d'objets imbriqués avec une seule commande, il sait comment optimiser les insertions afin qu'il n'ait pas à faire d'insertion séparée pour chaque ligne dans le tableau, mais généralement un seul insert par tableau)

4. exécuter 1 test et passer à l'étape 2

Avec les tests e2e, nous avons implémenté les méthodes saveState / restoreState (avec pg_restore / pg_dump), ce qui nous permet de revenir à un certain état pendant le test, nous n'avons donc pas à redémarrer le test à chaque fois qu'un test échoue après l'exécution de 20 minutes de tests.

C'est similaire à ce que j'ai commencé à faire hier parce que c'est simple et direct et que j'avais besoin de progresser.

Avez-vous envisagé la stratégie d'encapsuler les tests dans les transactions et de revenir en arrière comme une alternative plus rapide à tronquer toutes les tables? Cela me semble être l'idéal, si je peux comprendre l'implémentation.

Je suppose que si vous exécutez db et le code d'application dans le même processus, vous pouvez créer une transaction dans le code de test, puis enregistrer cette transaction comme votre instance knex (l'instance et la transaction knex semblent un peu différentes dans certains cas, mais vous pouvez généralement utiliser transaction instance comme une instance knex normale).

Ensuite, vous démarrez le code de votre application, qui récupère la transaction au lieu de l'instance knex groupée normale et commencez à effectuer des requêtes à travers cela.

À peu près de la même manière que vous avez décrit dans OP. Comment vous avez décrit cela semble viable.

J'ai envisagé d'utiliser des transactions pour réinitialiser la base de données dans les tests il y a quelques années, mais je l'ai rejeté parce que je veux que le pool de connexions fonctionne dans les tests à peu près de la même manière que cela fonctionne dans app + truncate / init est assez rapide pour nous.

N'existe-t-il aucun moyen d'obtenir une affinité de connexion pour la durée de la transaction de sorte que toutes les requêtes exécutées dans un lot utilisent la même connexion et soient donc encapsulables dans une seule transaction?

La stratégie tronquée fonctionne, mais c'est une force très brute. J'ai actuellement un crochet test.after.always () dans chaque fichier de test qui tronque les tables affectées par les tests de ce fichier (généralement une table par fichier), mais je peux penser aux cas marginaux qui seraient foirés par cela.

Par exemple, si deux tests de différents fichiers de test qui touchent la même table s'exécutent à peu près au même moment, le crochet tronqué d'un fichier peut démarrer pendant que les tests du deuxième fichier sont en cours d'exécution, ce qui fausse ce test.

Enfin, je ne sais toujours pas exactement comment les transactions fonctionnent dans Knex. Si je crée un trx avec knex.transaction() , toutes les requêtes exécutées avec trx feront-elles automatiquement partie de la transaction? Dois-je valider / annuler manuellement? (En supposant qu'aucune erreur n'a été générée.)

N'existe-t-il aucun moyen d'obtenir une affinité de connexion pour la durée de la transaction de sorte que toutes les requêtes exécutées dans un lot utilisent la même connexion et soient donc encapsulables dans une seule transaction?

Je n'ai pas compris ça

La stratégie tronquée fonctionne, mais c'est une force très brute. J'ai actuellement un crochet test.after.always () dans chaque fichier de test qui tronque les tables affectées par les tests de ce fichier (généralement une table par fichier), mais je peux penser aux cas marginaux qui seraient foirés par cela.

Par exemple, si deux tests de différents fichiers de test qui touchent la même table s'exécutent à peu près au même moment, le crochet tronqué d'un fichier peut démarrer pendant que les tests du deuxième fichier sont en cours d'exécution, ce qui fausse ce test.

Même si vous utilisez des transactions pour réinitialiser vos données de test, vous ne pourrez pas exécuter plusieurs tests en parallèle dans le cas général. Les séquences d'identifiants seront différentes et les transactions peuvent se bloquer, etc.

Enfin, je ne sais toujours pas exactement comment les transactions fonctionnent dans Knex. Si je crée un trx avec knex.transaction (), toutes les requêtes exécutées à l'aide de trx feront-elles automatiquement partie de la transaction? Dois-je valider / annuler manuellement? (En supposant qu'aucune erreur n'a été générée.)

Celui-ci se trouve dans la documentation. Si vous ne renvoyez pas la promesse de rappel dans knex.transaction(callback) vous devez valider / annuler manuellement. Si le rappel renvoie la promesse, alors commit / rollback est appelé automatiquement. Dans votre cas, vous devrez probablement revenir en arrière manuellement.

Même si vous utilisez des transactions pour réinitialiser vos données de test, vous ne pourrez pas exécuter plusieurs tests en parallèle dans le cas général. Les séquences d'identifiants seront différentes et les transactions peuvent se bloquer, etc.

Je génère des identifiants au hasard pour chaque enregistrement que j'insère. Les collisions sont possibles, mais peu probables, et si cela se produit une fois un jour, ce n'est qu'un test - pas du code destiné au client.

En ce qui concerne la concurrence, je suppose que toutes les requêtes qui doivent être regroupées en une seule transaction doivent également utiliser la même connexion DB, ce que je peux réaliser en définissant la taille de mon pool Knex sur 1. Je devrais alors effectuer les tests dans un fichier serial avec le modificateur .serial . Cependant, j'aurais toujours la concurrence entre les fichiers de test (qui est le facteur le plus important pour les performances) car Ava exécute chaque fichier de test dans un processus enfant séparé.

Je suppose que je devrais juste essayer.

Je l'ai fait fonctionner!

https://gist.github.com/odigity/7f37077de74964051d45c4ca80ec3250

J'utilise Ava pour les tests unitaires dans mon projet, mais pour cet exemple, je viens de créer un scénario de test unitaire simulé avec des crochets avant / après pour démontrer le concept.

Avant le crochet

• Parce que l'obtention d'une transaction est une action asynchrone, je crée une nouvelle promesse à retourner du hook before et capture sa méthode resolve afin qu'elle puisse être appelée dans le rappel transaction() .
• J'ouvre une transaction. Dans le rappel, je ...
  
  
  
  • enregistrer le handle tx dans un endroit qui sera accessible au test et after hook
  
  
  • appelez la méthode resolve enregistrée pour informer le "cadre de test" que le hook before est terminé, et le test peut commencer
  
  

Test - J'exécute deux requêtes d'insertion en utilisant le handle tx enregistré.

After Hook - J'utilise le handle tx sauvegardé

Sur la concurrence

Knex

Knex vous permet de spécifier des options pour la taille du pool de connexions. Si vous devez vous assurer que toutes les requêtes d'une transaction s'exécutent sur la même connexion (je suppose que nous le faisons), vous pouvez y parvenir en définissant la taille du pool sur 1.

_Mais attendez ..._ consultez ce commentaire dans la source :

// We need to make a client object which always acquires the same
// connection and does not release back into the pool.
function makeTxClient(trx, client, connection) {

Si je comprends bien cela, cela signifie que Knex peut être invoqué pour garantir que toutes les requêtes d'une transaction passent par la même connexion, même si votre pool est supérieur à 1! Nous n'avons donc pas besoin de sacrifier ce degré particulier de concurrence pour notre scénario.

BTW - Les documents devraient probablement refléter ce fait essentiel et merveilleux.

Ava

_Je connais cela spécifique à Ava plutôt que spécifique à Knex, mais c'est un framework populaire, et les leçons sont largement applicables à la plupart des frameworks._

Ava exécute chaque fichier de test simultanément dans un processus distinct. Dans chaque processus, il exécute également tous les tests simultanément. Les deux formes de concurrence sont désactivables à l'aide de l'option CLI --serial (qui sérialise tout) ou du modificateur .serial sur la méthode test (qui sérialise les tests marqués avant d'exécuter le reste simultanément ).

Emballer

Quand je rassemble tous ces faits:

• Je peux envelopper chaque test dans une transaction, ce qui garantit (a) la non-collision des données de test (b) le nettoyage post-test automatique sans troncature ni remigration. En fait, en utilisant cette stratégie, ma base de données de test n'aura littéralement jamais un seul enregistrement persistant, à part peut-être des données de départ essentielles.

• Je peux continuer à bénéficier de la concurrence entre les fichiers de test d'Ava, puisque chaque fichier de test s'exécute dans un processus séparé, et aura donc son propre pool de connexions Knex.

• Je peux continuer à bénéficier de la concurrence intra-fichier de test d'Ava si je m'assure que mon pool de connexions est> = le nombre de tests dans le fichier. Cela ne devrait pas être un problème.Je ne mets pas un grand nombre de tests dans un seul fichier, ce que j'essaye d'éviter de toute façon. En outre, le pool peut être défini avec une plage telle que 1 à 10, vous ne créez donc pas de connexions dont vous n'avez pas besoin, mais vous n'avez pas à ajuster une constante dans chaque fichier de test à chaque fois que vous ajoutez ou supprimez un test.

Désireux de capter l'opinion des autres, car je barbote à l'intersection d'un grand nombre de technologies qui sont nouvelles pour moi à la fois ...

@odigity yup, la transaction dans knex n'est quasiment qu'un descripteur de connexion dédiée où knex ajoute automatiquement une requête BEGIN lors de la création d'une instance trx (en fait, la transaction en SQL est généralement juste des requêtes allant à la même connexion précédée de BEGIN).

Si knex n'allouait pas de connexion pour la transaction, alors les transactions ne fonctionneraient tout simplement pas.

Utiliser des clés uuid n'est pas mal non plus, le changement de collision est vraiment improbable à moins qu'il y ait vraiment beaucoup de lignes. ("Si vous utilisez un UUID de 128 bits, l '' effet anniversaire 'nous indique qu'une collision est probable après avoir généré environ 2 ^ 64 clés, à condition que vous ayez 128 bits d'entropie dans chaque clé.")

Je suppose que vous avez compris vos réponses, alors fermez ceci 👍

Désolé de rouvrir, mais j'observe maintenant un comportement inattendu. Plus précisément, cela fonctionne quand cela ne devrait pas être, ce qui signifie que ma compréhension doit être corrigée.

Si je règle la taille du pool sur 1, ouvre une transaction, puis exécute une requête sans l'utiliser, le délai expire car il ne peut pas obtenir de connexion - ce qui est logique, car cette connexion a déjà été verrouillée par la transaction.

Cependant, si je règle la taille du pool sur 1 et exécute quatre tests simultanément, chacun d'entre eux:

• ouvre une transaction
• exécute des requêtes
• appelle la restauration à la fin

Ils fonctionnent tous. Ils ne devraient pas fonctionner - au moins quelques-uns d'entre eux devraient être bloqués par la rareté des connexions - mais ils fonctionnent tous bien, à chaque fois.

Knex dispose-t-il d'une file d'attente intégrée pour les requêtes lorsqu'aucune connexion n'est disponible à ce moment-là? Si tel est le cas, pourquoi mon premier exemple échoue-t-il, au lieu d'attendre la fin de la transaction avant d'exécuter la requête non-tx?

Ou Knex multiplexe-t-il en quelque sorte plusieurs transactions simultanées sur une seule connexion?

Ou Knex crée-t-il réellement des sous-transactions lors des 2ème, 3ème et 4ème invocations? Si tel est le cas, cela entraînera probablement au hasard les résultats attendus ...

@odgity Dans le premier cas, vous avez un blocage côté application (votre application est bloquée dans l'attente de la connexion et des déclencheurs de délai d'expiration de connexion).

Dans le second cas, les tests sont en fait exécutés en série, puisque tout le monde sauf un attend la connexion. Si vous avez suffisamment de tests pour le faire en parallèle ou que vos cas de test sont vraiment lents, acquérezConnectionTimeout devrait également se déclencher dans le second cas.

Le multiplexage des transactions en connexion unique n'est pas possible. L'imbrication des transactions est prise en charge par knex à l'aide de points de sauvegarde dans la transaction. Si vous demandez une nouvelle transaction à partir du pool, cela ne se produira pas non plus.

Merci, c'est vraiment utile.

Bien que je sois encore un peu confus sur la raison pour laquelle l'exécution d'une requête se verrouille lorsque la connexion est prise par une transaction ouverte, mais la tentative d'ouvrir une deuxième nouvelle transaction attend patiemment, puis se termine.

Exécutez votre code avec la variable d'environnement DEBUG = knex: * et vous verrez ce que fait le pool. Knex devrait également attendre dans le premier cas jusqu'à ce que le délai "Je n'ai pas pu obtenir de connexion" se produise. Donc, si votre transaction attend jusqu'à ce que la deuxième connexion soit acquise, il s'agit d'un blocage au niveau de l'application car les deux connexions attendent l'une l'autre (je ne sais pas si c'est votre cas).

J'ai trouvé ce fil très utile. C'est agréable de voir que d'autres personnes se soucient également d'écrire des tests qui ne polluent pas l'état du système. J'ai lancé un projet qui permet aux gens d'écrire des tests pour du code qui utilise knex qui sera restauré une fois le test terminé.

https://github.com/bas080/knest

@ bas080 en général, cette approche limite les choses que vous pouvez tester (permettant au test d'utiliser une seule transaction). Cela empêchera de tester le code qui utilise plusieurs connexions / transactions simultanées. On ne peut pas non plus tester le code qui effectue des validations implicites (des cas peu courants cependant) de cette façon.

Je sais que l'utilisation de la transaction pour réinitialiser l'état après l'exécution du test est un modèle assez courant, ce que je veux souligner, c'est que l'utilisation de cette seule approche empêche de tester certaines choses.

J'ai toujours préféré tronquer et repeupler la base de données après chaque test qui modifie les données ou après un ensemble de tests qui dépendent les uns des autres (parfois je le fais pour des raisons de performances si le peuplement prend trop de temps, comme plus de 50 ms).

salut, désolé de rouvrir ce numéro mais j'ai commencé un nouveau projet qui est un cli pour que knex _seed plusieurs bases de données avec de fausses données, _ je voudrais que vous le voyiez et m'aidiez avec une contribution

Pour les tests unitaires, j'ai seulement vérifié que les requêtes exécutées par Knex à partir de mon wrapper SQL sont correctement formées, en utilisant toString() à la fin de la chaîne de requêtes. Pour les tests d'intégration, j'ai utilisé la stratégie déjà répertoriée ci-dessus - à savoir faire un cycle: rollback -> migrate -> seed, avant chaque test. Naturellement, cela peut être trop lent si vous ne pouvez pas garder vos données d'amorçage petites, mais peut convenir à d'autres.

c'est-à-dire faire un cycle: rollback -> migrate -> seed, avant chaque test.

C'est vraiment une mauvaise façon de le faire. L'exécution des migrations dans les deux sens prend facilement des centaines de millisecondes, ce qui est bien trop lent. Vous ne devez exécuter les migrations qu'une seule fois pour toute la suite de tests, puis avant le test, tronquez toutes les tables et remplissez les données de test appropriées. Cela peut être fait facilement 100 fois plus rapidement que de restaurer / recréer tout le schéma.

Vous pouvez utiliser knex-cleaner pour tronquer facilement toutes les tables:

knexCleaner
    .clean(knex, { ignoreTables: ['knex_migrations', 'knex_migrations_lock'] })
    .then(() => knex.seed.run())

Notez qu'il n'est pas nécessaire d'utiliser la partie ignoreTables si vous exécutez des migrations au début de chaque exécution de la suite de tests. Cela n'est nécessaire que si vous exécutez les migrations manuellement sur votre base de données de test.

@ricardograca Gère- t-il bien les cas avec des clés étrangères? (ce qui signifie que le nettoyage n'échouera pas car l'ordre de suppression est erroné)

Sinon, c'est facile à corriger (il suffit de tronquer toutes les tables avec une seule requête) :)

@elhigu Comment pouvez-vous faire ça?

Dépend de la base de données, mais par exemple comme ceci: https://github.com/Vincit/knex-db-manager/blob/master/lib/PostgresDatabaseManager.js#L95

@kibertoad Oui, il gère très bien les contraintes de clé étrangère et supprime tout.

@odigity et si on

// controller.js
const users = require('./usersModel.js');

module.exports.addUser = async ({ token, user }) => {
  // check token, or other logic
  return users.add(user);
};

// usersModel.js
const db = require('./db');

module.exports.add = async user => db('users').insert(user);

// db.js
module.exports = require('knex')({ /* config */});

À votre façon, toutes les fonctions doivent avoir un argument supplémentaire (par exemple trx ) pour passer la transaction aux générateurs de requêtes réels.
https://knexjs.org/#Builder -transacting

Je pense que la bonne manière doit être quelque chose comme ça:

1. Créez trx dans beforeEach .
2. Injectez-le d'une manière ou d'une autre. Dans mon exemple, require('./db') devrait renvoyer une valeur trx.
3. Faites des tests.
4. Rollback trx dans 'afterEach'.

Mais, je ne sais pas est-ce possible avec knex?
Et si le code utilise d'autres transactions?

Aussi une autre option: peut-être qu'il y a une fonction qui commence à exécuter la requête. Nous pouvons donc le remplacer pour forcer l'exécution dans la transaction de test.

Après une journée de lecture du code knex, j'essaye cette approche:

test.beforeEach(async t => {
    // if we use new 0.17 knex api knex.transaction().then - we can not handle rollback error
    // so we need to do it in old way
    // and add empty .catch to prevent unhandled rejection
    t.context.trx = await new Promise(resolve => db.transaction(trx => resolve(trx)).catch(() => {}));
    t.context.oldRunner = db.client.runner;
    db.client.runner = function(builder) {
        return t.context.oldRunner.call(t.context.trx.client, builder);
    };
    t.context.oldRaw = db.raw;
    db.raw = function(...args) {
        return t.context.oldRaw.call(this, ...args).transacting(t.context.trx);
    };
});

test.afterEach(async t => {
    db.raw = t.context.oldRaw;
    db.client.runner = t.context.oldRunner;
    await t.context.trx.rollback();
});

Et ça marche un peu. Donc, je remplace les méthodes .raw et .client.runner . .client.runner appelle en interne lorsque vous .then un générateur de requêtes. db dans cette fonction est le client knex knex({ /* config */}) .

@Niklv comme je l'ai déjà expliqué ici; l'utilisation de la transaction pour réinitialiser les données de test est généralement une mauvaise idée et je la considérerais même comme un anti-pattern. Il en va de même pour les internes de knex. Tronquer + repeupler la base de données à chaque test ou pour un ensemble de tests est une recommandation. Cela ne prend pas plusieurs millisecondes si les données de test sont de taille raisonnable.