私はjestとsupertestを介して新しいAPIの広範なテストを書いています。テストを実行する前に、テストデータベースを設定し、ユーザーを入力します。
テストコマンド
jest --forceExit --config src/utils/testing/jest.config.js
jest.config.js
module.exports = {
rootDir: process.cwd(),
// Sets up testing database with users
globalSetup: './src/utils/testing/jest.setup.js',
// Ensures connection to database for all test suites
setupTestFrameworkScriptFile: './src/utils/testing/jest.db.js',
}
だから私はテストするいくつかのユーザーのデータベースから始めています。問題はこれです:
私のテストのいくつかは、他のテストの成功に依存しています。このアプリケーションでは、ユーザーは画像をアップロードしてパックにグループ化できます。したがって、グループ化エンドポイントスイートは、画像アップロードスイートの成功などに依存します。
多くの人がこれは悪い習慣であり、テストは他のテストに依存すべきではないと言うかもしれないことを私はよく知っています。そうは言っても、私は実際にはすべてのテストをsupertest
で保持し、依存性注入などを行わないようにします。テスト条件を細心の注意を払って設定する必要はありません(たとえば、多数のユーザーイメージを作成するなど)。テストを実行する前に人為的に)、理由は次のとおりです。(1)これはロジックの単なる複製であり、(2)何かが壊れる可能性が高くなります。
ジェストスイートをグループ化する方法はありますか?たとえば、スイートを順番に実行します。
jest run creationSuite
jest run modificationSuite
このようにして、すべての「creationSuite」テストを同時に実行でき、allが成功すると、「modificationSuite」がトリガーされ、フェイルファスト方式。
または、テストスイート内で他のテストスイートへの依存関係を指定すると便利です。
describe('Grouping endpoint', () => {
// Somehow define deps
this.dependsOn(uploadSuite)
jest-runner-groups
を使用して、グループでテストを定義および実行できます。インストールしてjest構成に追加したら、次のようにdocblock表記を使用してテストにタグを付けることができます。
/**
* Foo tests
*
* @group group1/subgroup1
* @group unit/foo
*/
describe( 'Foo class', () => {
...
} );
/**
* Bar tests
*
* @group group1/subgroup2
* @group unit/bar
*/
describe( 'Bar class', () => {
...
} );
Jest構成を更新して、新しいランナーを指定します。
// jest.config.js
module.exports = {
...
runner: "groups"
};
次に、特定のグループを実行するには、--group=
引数を使用する必要があります。
// using jest executable
jest --group=mygroup
// or npm
npm test -- --group=mygroup
複数の--group
引数を使用して、複数のグループを実行することもできます。
// will execute tests in the unit/bar and unit/foo groups
npm test -- --group=unit/bar --group=unit/foo
// will execute tests in the unit group (including unit/bar and unit/foo groups)
npm test -- --group=unit
--testNamePattern
フラグを使用して実行しました。手順は次のとおりです。
2つのグループのテストがあるとしましょう。
DevTest
開発環境でのテスト用ProdTest
本番環境でのテスト用開発環境に必要な機能のみをテストする場合は、テストの説明にDevTest
を追加する必要があります
describe('(DevTest): Test in dev environment', () => {
// your test
})
describe('(ProdTest): Test in production environment', () => {
// your test
})
describe('Test everywhere', () => {
// your test
})
その後、package.json
にコマンドを追加できます。
"scripts": {
"test": "jest",
"test:prod": "jest --testNamePattern=ProdTest",
"test:dev": "jest --testNamePattern=DevTest",
"test:update": "jest --updateSnapshot"
}
フラグnpm test
を使用していないため、コマンド--testNamePattern
はすべてのテストを実行します。他のテストを実行したい場合は、たとえばnpm run test:dev
を使用してください。
ただし、テストグループに名前を付けるときは注意してください。テストの説明で正規表現を使用して検索されるため、このコマンドを他の単語と一致させないでください。
Jestテストスイートは複数のスレッドで実行されます。これはその主な利点の1つです。この方法でテストの実行をはるかに高速に完了することができますが、テストシーケンスは設計によって保持されません。
runInBand
オプションを使用して、この機能を無効にすることができます。
testNamePattern
オプションを使用して名前に基づいて、または testPathPattern
option を使用してパスに基づいて、テストとスイートを選択することができます。
あるスイートは別のスイートに依存しているため、実行が期待される順序で1つのスイートに組み合わせることができます。それらは引き続き異なるファイルに存在できます(Jestと一致していないことを確認してください)。例:
// foobar.test.js
describe(..., () => {
require('foo.partial-test.js');
require('bar.partial-test.js');
});
問題はこれです:
私のテストのいくつかは、他のテストの成功に依存しています。
これがここでの本当の問題です。以前のテスト状態に依存するアプローチは、あらゆる種類の自動テストに欠陥があると見なされます。
テスト条件を細心の注意を払って設定する必要はありません(たとえば、テストを実行する前に人工的にユーザーイメージの束を作成する)。これは、(1)これは単なるロジックの複製であり、(2)何かの可能性を高めるためです。速報。
テスト条件(フィクスチャ)を人為的に設定する必要はありません。フィクスチャは、品質に確信がある場合は、現在のテストの結果からでも、既存の環境から抽出できます。
冗長性とトートロジーは自動テストで自然に発生しますが、問題はありません。フィクスチャと共有コードを適切に管理することで、テストをDRYerで行うことができます。
まったく逆に、エラーは常に蓄積されます。誤った前提条件を作成したテストは合格する可能性がありますが、別のテストは失敗するため、デバッグの難問が発生します。