Knex: Knexを使用するメソッドの単体テストを作成する方法。

昨夜、「knex.jsを使用してアトミック単体テストを作成する方法」を再試行したところ、興味深い結果が得られたため、グーグルでうまくいかなかったようです。 今それらを読み通すつもりです。 何か学んだらまた投稿します。

いいえ、何もありません。 ソースの時系列順での要約：

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

戦略：モックナイフを使用します。 DBをモックしたくない-実際のMySQLDBに対してメソッドをテストして正しい動作を確認したい-とにかくmock-knex調べた...それは最悪の設計のライブラリかもしれない私は今までに遭遇したことがあります。 :(

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

戦略：各テスト後にDBをロールバック/再移行/再シードします。 これは、各テストのオーバーヘッドが大きいように思われ、実行速度が非常に遅くなります。 同時実行性は、各テストのDB名に対してUUIDを生成することで実現できますが、それはトランザクションの優雅さに比べればひどい解決策のように思えます...

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

戦略：テストにはsqliteを使用し、テストごとにDBを作成/破棄します。 上記のこのアプローチが嫌いな理由の両方について説明しました。

それで...まだ提案を探しており、Knexトランザクションが実際にどのように機能するか、およびそれらを私のユースケースに適切に適用する方法に関する追加のガイダンスを探しています。

@odigityは、悪いテスト手法をうまくまとめています👍

私たちは次のような「ユニット」テストを行っています。

1. システムを起動し、DBを初期化し、移行を実行します

2. 各テストの前に、すべてのテーブルとシーケンスを切り捨てます（knex-db-managerパッケージを使用）

3. テストケースに必要なデータを挿入します（ネストされたオブジェクト階層を1つのコマンドで挿入できるようにするためにknexベースのobjection.js ORMを使用します。挿入を最適化する方法を知っているため、行ごとに個別の挿入を行う必要はありません。テーブル内ですが、通常はテーブルごとに1つの挿入のみです）

4. 1つのテストを実行し、ステップ2に進みます

e2eテストでは、saveState / restoreState（pg_restore / pg_dumpを使用）メソッドを実装しました。これにより、テスト実行中に特定の状態にロールバックできるため、実行後にテストが失敗するたびにテスト実行を再開する必要はありません。テストの分。

それはシンプルで率直で、進歩する必要があったので、昨日始めたのと似ています。

すべてのテーブルを切り捨てるよりも高速な代替手段として、テストをトランザクションでラップし、後でロールバックする戦略を検討しましたか？ 実装を理解できれば、それは私にとって理想のように思えます。

dbとアプリケーションコードを同じプロセスで実行すると、テストコードでトランザクションを作成し、そのトランザクションをknexインスタンスとして登録できると思います（knexインスタンスとトランザクションは少し異なる場合がありますが、通常はトランザクションを使用できます通常のknexインスタンスのようなインスタンス）。

次に、通常のプールされたknexインスタンスの代わりにトランザクションをフェッチするアプリケーションコードを開始し、それを介してクエリを開始します。

OPで説明したのとほぼ同じ方法です。 あなたがそれをどのように説明したかは実行可能に聞こえます。

数年前のテストでDBをリセットするためにトランザクションを使用することを検討しましたが、接続プールをアプリで動作するのとほぼ同じ方法で動作させたいため、拒否しました+切り捨て/初期化は十分に高速です。

1つのバッチで実行されるすべてのクエリが同じ接続を使用し、単一のトランザクションでラップできるように、トランザクションの期間中に接続アフィニティを実現する方法はありませんか？

切り捨て戦略は一種の機能ですが、それは非常にブルートフォースです。 現在、各テストファイルにtest.after.always（）フックがあり、そのファイル内のテストの影響を受けるテーブル（通常はファイルごとに1つのテーブル）を切り捨てていますが、それによって台無しになるエッジケースを考えることができます。

たとえば、同じテーブルにアクセスする異なるテストファイルからの2つのテストがほぼ同時に実行される場合、2番目のファイルのテストが実行中に、1つのファイルの切り捨てフックが開始され、そのテストが台無しになる可能性があります。

最後に、Knexでトランザクションがどのように機能するかについてはまだはっきりしていません。 knex.transaction()でtrxを作成した場合、 trx自動的にトランザクションの一部になりますか？ 手動でコミット/ロールバックする必要がありますか？ （スローされたエラーがないと仮定します。）

1つのバッチで実行されるすべてのクエリが同じ接続を使用し、単一のトランザクションでラップできるように、トランザクションの期間中に接続アフィニティを実現する方法はありませんか？

私はこれを理解していませんでした

切り捨て戦略は一種の機能ですが、それは非常にブルートフォースです。 現在、各テストファイルにtest.after.always（）フックがあり、そのファイル内のテストの影響を受けるテーブル（通常はファイルごとに1つのテーブル）を切り捨てていますが、それによって台無しになるエッジケースを考えることができます。

たとえば、同じテーブルにアクセスする異なるテストファイルからの2つのテストがほぼ同時に実行される場合、2番目のファイルのテストが実行中に、1つのファイルの切り捨てフックが開始され、そのテストが台無しになる可能性があります。

トランザクションを使用してテストデータをリセットしている場合でも、通常、複数のテストを並行して実行することはできません。 IDシーケンスが異なり、トランザクションがデッドロックする可能性があります。

最後に、Knexでトランザクションがどのように機能するかについてはまだはっきりしていません。 knex.transaction（）を使用してtrxを作成した場合、trxを使用して実行されるすべてのクエリは自動的にトランザクションの一部になりますか？ 手動でコミット/ロールバックする必要がありますか？ （スローされたエラーがないと仮定します。）

これはドキュメントから見つかります。 knex.transaction(callback)コールバックからpromiseを返さない場合は、手動でコミット/ロールバックする必要があります。 コールバックがpromiseを返す場合、commit / rollbackが自動的に呼び出されます。 あなたの場合、おそらく手動でロールバックする必要があります。

トランザクションを使用してテストデータをリセットしている場合でも、通常、複数のテストを並行して実行することはできません。 IDシーケンスが異なり、トランザクションがデッドロックする可能性があります。

挿入するレコードごとにランダムにIDを生成しています。 衝突は発生する可能性がありますが、発生する可能性は低く、1日に1回発生する場合は、単なるテストであり、顧客向けのコードではありません。

同時実行性に関しては、単一のトランザクションにグループ化する必要があるすべてのクエリも同じDB接続を使用する必要があると想定しています。これは、Knexプールサイズを1に設定することで実現できます。次に、テストを行う必要があります。 .serial修飾子を使用したファイルシリアル。 ただし、Avaは各テストファイルを個別の子プロセスで実行するため、テストファイル間の同時実行性（パフォーマンスの最も重要な要素）があります。

私はそれを試してみるべきだと思います。

動作しました！

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

プロジェクトの単体テストにAvaを使用していますが、この例では、概念を示すために、前後のフックを使用して模擬単体テストシナリオを作成しました。

フック前

• トランザクションの取得は非同期アクションであるため、 beforeフックから戻る新しいPromiseを作成し、そのresolveメソッドをキャプチャして、 transaction()コールバックで呼び出すことができるようにします。
• トランザクションを開きます。 コールバックでは、私は...
  
  
  
  • txハンドルを、テストとafterフックにアクセスできる場所に保存します
  
  
  • 保存したresolveメソッドを呼び出して、「テストフレームワーク」にbeforeフックが完了し、テストを開始できることを通知します。
  
  

テスト—保存されたtxハンドルを使用して2つの挿入クエリを実行します。

フック後—保存されたtxハンドルを使用してトランザクションをロールバックし、テスト中に行われたすべての変更を元に戻します。 データはコミットされないため、他のテストのアクティビティによって表示されたり、妨害されたりすることはありません。

並行性について

Knex

Knexでは、接続プールサイズのオプションを指定できます。 トランザクション内のすべてのクエリが同じ接続で実行されるようにする必要がある場合（私はそうしていると思います）、プールサイズを1に設定することでこれを実現できます。

_しかし待ってください..._ソースでこのコメントをチェックしてください：

// 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) {

私がこれを正しく理解していれば、プールが1より大きい場合でも、トランザクション内のすべてのクエリが同じ接続を通過することを保証するためにKnexを信頼できることを意味します。 したがって、シナリオでこの特定の同時実行性を犠牲にする必要はありません。

ところで—ドキュメントはおそらくこの本質的で素晴らしい事実を反映しているはずです。

エイバ

_Knex固有ではなくAva固有であることは知っていますが、これは人気のあるフレームワークであり、レッスンはほとんどのフレームワークに広く適用できます。_

Avaは、各テストファイルを別々のプロセスで同時に実行します。 各プロセス内で、すべてのテストを同時に実行します。 両方の形式の並行性は、 --serial CLIオプション（すべてをシリアル化する）またはtestメソッドの.serial修飾子（残りを同時に実行する前にマークされたテストをシリアル化する）を使用して無効にできます）。

要約

これらすべての事実をまとめると、次のようになります。

• 各テストをトランザクションでラップできます。これにより、（a）テストデータの非衝突（b）切り捨てや再移行なしのテスト後の自動クリーンアップが保証されます。 実際、この戦略を使用すると、私のテストDBには、おそらく必須のシードデータを除いて、文字通り単一のレコードが保持されることはありません。

• 各テストファイルは別々のプロセスで実行され、独自のKnex接続プールを持つため、Avaのテストファイル間の同時実行性の恩恵を受け続けることができます。

• 接続プールがファイル内のテストの数以上であることを確認すれば、Avaのテストファイル内同時実行性の恩恵を受け続けることができます。 これは問題ではないはずです。1つのファイルに膨大な数のテストを入れないので、とにかく避けようとします。 また、プールは1〜10のような範囲で設定できるため、不要な接続を作成する必要はありませんが、テストを追加または削除するたびに各テストファイルの定数を調整する必要はありません。

同時に新しいテクノロジーの交差点に手を出しているので、他の人の考えを知りたがっています...

@odigityうん、knexのトランザクションは、trxインスタンスが作成されたときにknexが自動的にBEGINクエリを追加する専用接続へのハンドルにすぎません（実際、SQLのトランザクションは通常、BEGINが前に付いた同じ接続に向かうクエリです）。

knexがトランザクションに接続を割り当てない場合、トランザクションはまったく機能しません。

uuidキーを使用することも悪くありません。実際に多くの行がない限り、衝突が変化する可能性はほとんどありません。 （「128ビットのUUIDを使用する場合、「誕生日の効果」は、各キーに128ビットのエントロピーがある場合、約2 ^ 64のキーを生成した後に衝突が発生する可能性があることを示しています。」）

あなたはあなたの答えを理解したと思うので、これを閉じます👍

再開して申し訳ありませんが、予期しない動作が見られます。 具体的には、あるべきではないときに機能しているので、私の理解を修正する必要があります。

プールサイズを1に設定した場合、トランザクションを開き、それを使用せずにクエリを実行すると、接続を取得できないためにタイムアウトになります。これは、その接続がトランザクションによってすでにロックされているためです。

ただし、プールサイズを1に設定し、4つのテストを同時に実行すると、それぞれが次のようになります。

• トランザクションを開きます
• クエリを実行します
• 最後にロールバックを呼び出します

それらはすべて機能します。 それらは機能しないはずです-少なくともそれらのいくつかは接続不足によってロックアウトされるはずです-しかしそれらはすべて毎回正常に機能します。

Knexには、その時点で使用可能な接続がない場合のクエリのキューイングが組み込まれていますか？ もしそうなら、非txクエリを実行する前にトランザクションが終了するのを待つのではなく、なぜ私の最初の例が失敗するのですか？

または、Knexはどういうわけか複数の同時トランザクションを単一の接続に多重化しますか？

それとも、Knexは実際に2回目、3回目、4回目の呼び出しでサブトランザクションを作成していますか？ もしそうなら、それはおそらくランダムに期待される結果を引き起こすでしょう...

@odgity最初のケースでは、アプリケーション側のデッドロックが発生します（アプリは、接続とacquireConnectionタイムアウトトリガーの待機でスタックします）。

2番目のケースでは、1人を除く全員が接続を待機しているため、テストは実際には連続して実行されます。 それを並行して実行する十分なテストがある場合、またはテストケースが本当に遅い場合は、2番目のケースでもacquireConnectionTimeoutがトリガーされます。

単一接続でトランザクションを多重化することはできません。 ネストトランザクションは、トランザクション内のセーブポイントを使用するknexによってサポートされます。 プールからの新しいトランザクションを要求している場合も発生しません。

ありがとう、それは本当に役に立ちます。

開いているトランザクションによって接続が確立されたときにクエリの実行がロックされる理由についてはまだ少し混乱していますが、2番目の新しいトランザクションを開こうとすると、辛抱強く待ってから完了します。

DEBUG = knex：*環境変数を使用してコードを実行すると、プールが何をしているかがわかります。 Knexは、最初のケースでも、「接続を取得できませんでした」タイムアウトが発生するまで待機する必要があります。 したがって、2番目の接続が取得されるまでトランザクションが待機している場合、両方の接続が相互に待機しているため、アプリケーションレベルのデッドロックになります（ただし、これが当てはまるかどうかはわかりません）。

このスレッドはとても便利だと思いました。 他の人もシステムの状態を汚染しないテストを書くことに関心を持っているのを見るのはうれしいです。 私は、テストの完了後にロールバックするknexを使用するコードのテストを作成できるプロジェクトを開始しました。

https://github.com/bas080/knest

@ bas080は一般的に、このアプローチではテストできるものが制限されます（テストで単一のトランザクションのみを使用できるようにします）。 複数の接続/同時トランザクションを使用するコードのテストを防ぎます。 また、この方法で暗黙的なコミットを行うコードをテストすることはできません（ただし、あまり一般的ではありません）。

テストの実行後にトランザクションを使用して状態をリセットすることはかなり一般的なパターンであることを私は知っています。強調したいのは、そのアプローチのみを使用すると、特定のものをテストできないということです。

私は常に、データを変更する各テストの後、または相互に依存するいくつかのテストのセットの後にDBを切り捨てて再入力することを好みました（入力に50ミリ秒以上かかる場合は、パフォーマンス上の理由でこれを行うことがあります）。

こんにちは、この問題を再度開いて申し訳ありませんが、私はknexが_偽のデータを含む複数のデータベースをシードするためのCLIである新しいプロジェクトを開始しました_それを見て、いくつかの貢献を手伝ってほしい

単体テストでは、クエリチェーンの最後でtoString()を使用して、SQLラッパーからKnexによって実行されたクエリが正しく形成されていることを確認しているだけです。 統合テストでは、すべてのテストの前に、上記の戦略を採用しています。つまり、サイクルバック->移行->シードです。 当然のことながら、シードデータを小さく保つことができない場合は遅すぎる可能性がありますが、他の人には適している可能性があります。

つまり、すべてのテストの前に、ロールバック->移行->シードを循環させます。

それは本当に悪い方法です。 移行の実行には数百ミリ秒かかりますが、これは遅すぎます。 テストスイート全体に対して一度だけ移行を実行し、テストの前にすべてのテーブルを切り捨てて適切なテストデータを入力する必要があります。スキーマ全体をロールバック/再作成するよりも100倍速く簡単に実行できます。

knex-cleanerを使用すると、すべてのテーブルを簡単に切り捨てることができます。

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

各テストスイートの実行の開始時に移行を実行している場合は、 ignoreTables部分を使用する必要がないことに注意してください。 これは、テストデータベースで手動で移行を実行する場合にのみ必要です。

@ricardograca外部キーのあるケースをうまく処理しますか？ （削除順序が間違っているためにクリーニングが失敗しないことを意味します）

そうでない場合は、簡単に修正できます（1つのクエリですべてのテーブルを切り捨てる必要があります）:)

@elhiguどうすればそれができますか？

データベースによって異なりますが、たとえば次のようになります： https ：

@kibertoadはい、外部キー制約を

@odigityそのような構造をテストする場合はどうなりますか？

// 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 */});

トランザクションを実際のクエリビルダーに渡すには、すべての関数に追加の引数（たとえば、 trx ）が必要です。
https://knexjs.org/#Builder -transacting

私は正しい方法はそのようなものでなければならないと思います：

1. beforeEach trxを作成します。
2. どういうわけかそれを注入します。 私の例では、 require('./db') trx値を返します。
3. テストを行います。
4. 'afterEach'でtrxをロールバックします。

しかし、私はそれがknexで可能かどうかわかりませんか？
コードが別のトランザクションを使用する場合はどうなりますか？

また、別のオプション：クエリの実行を開始する関数があるかもしれません。 したがって、これをオーバーライドして、テストトランザクションで強制的に実行することができます。

knexコードを読んだ後、私はこのアプローチを試します。

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();
});

そしてそれはちょっとうまくいきます。 上書き私は.rawと.client.runnerメソッドを。 .client.runnerは、クエリビルダーを.thenすると、内部的に呼び出されます。 この関数のdbはknexクライアントknex({ /* config */})です。

@Niklvは、すでにここで説明しました。 トランザクションを使用してテストデータをリセットすることは一般的に悪い考えであり、アンチパターンとさえ見なします。 したがって、knexの内部をオーバーライドします。 すべてのテストまたは一連のテストでdbを切り捨てて再入力することをお勧めします。 テストデータのサイズが適切であれば、実行に数ミリ秒はかかりません。