Node にはどのようなテスト フレームワークを使用できますか?次の記事では、Node.js テスト フレームワークについて説明します。お役に立てば幸いです。 
Node.js クイック入門コース: 学習するために入力してください
編集者注: この記事の著者は、Ant Group の Node.js エンジニアである Tianzhu です。最初に、記事の最後に、単体テストが必要かどうかについて説明します。一緒に話し合うこと。
mocha と jest が一般的に使用されます。公式の新しいノードのテストはまだ改良中であり、将来は有望です。
$モカ テスト/egg-view-ejs.test.js 与える ✓ ローカルでレンダリングする必要があります ✓ キャッシュを使用してレンダリングする必要があります ✓ レイアウトを使用してレンダリングする必要があります ✓ エラーが表示されるはずです レンダリング文字列 ✓ データを含む renderString を実行する必要があります ✓ renderString エラーが発生するはずです 6パス（398ミリ秒）
非常に多くの Runner が存在しますが、その出力規格はすべて TAP 形式であり、結果はさまざまな Reporter を通じて出力されます。
単一のテストを作成するだけでは十分ではないため、コードのすべての分岐プロセスがカバーされているかどうかを知る必要があるため、通常はコード カバレッジ ツールを使用する必要があります。
以前は istanbuljs でしたが、後に作者は nyc を書き直しました。彼らは主に 2 つの役割を担っています。1 つはコードを変換して杭打ちコードを挿入すること、もう 1 つはさまざまなレポーターがカバレッジ レポートを生成することをサポートすることです。
その後、V8 組み込みカバレッジ統計
つまり、コードを変換する必要がなくなり、カバレッジ データの収集がネイティブにサポートされます。
その後、この著者はカバレッジ レポートの生成に焦点を当てた c8 を作成しました。
変数の結果を検証するには、assert が不可欠です。
歴史的には、expect.js、 should.js、chai、power-assert、jest にも独自の組み込みの Expect があります。
しかし、今では Node.js 公式のassert/strictは実際にはかなり優れています。
その中で、power-assert は、私も何年も前に「おそらく最高の JS Assert ライブラリ - The Empire's New Clothes」で使用しているものです。
constassert = require('power-assert');
description('test/showcase.test.js', () => {
const arr = [1, 2, 3];
it('power-assert', () => {
アサート(arr[1] === 10);
});
});
//出力：
4) test/showcase.test.js power-assert:
AssertionError: # test/showcase.test.js:6
アサート(arr[1] === 10)
| |
| 2 偽
[1,2,3]
【個数】10
=> 10
[番号] arr[1]
=> 2PS: ファイルの内容を確認したい場合は、assert ファイルも作成しましたので、ぜひ試してみてください。
これは単体テストであるため、多くの場合、環境またはダウンストリームの応答をシミュレートする必要があります。
sinonjs は悪くなく、モック、スタブなどをサポートしています。 jest には独自のモック ライブラリも組み込まれています。
HTTP テストの場合、nock は非常に強力で、サーバーの応答を模擬するのに役立ちます。
ノック('http://www.example.com')
.post('/ログイン', 'ユーザー名=pgte&パスワード=123456')
.reply(200, { id: '123ABC' })ただし、Node.js の公式 undici リクエスト ライブラリには、組み込みのモック機能もあります。
スナップショットという用語もありますが、これは運用中のデータをダンプし、次のテストの模擬データとして直接利用することを意味し、テスト作成の効率をある程度向上させることができます。
HTTP サーバーのシナリオをテストするには、スーパーテスト ライブラリが不可欠です。
description('GET /users', function() {
it('json で応答', async function() {
返品リクエスト(アプリ)
.get('/users')
.set('受け入れ', 'アプリケーション/json')
.expect('コンテンツタイプ', /json/)
.expect(200)
.then(応答 => {
assert(response.body.email, '[email protected]');
});
});
});Node.js の主な使用シナリオの 1 つは、Webpack や Babel などのコマンド ライン CLI ですが、これら自体にも単体テストが必要です。
これをお勧めします。
GitHub - ノードモジュール/clet: コマンドライン E2E テスト
GitHub - ノードモジュール/コーヒー: Node.js のコマンドラインをテストする
import { ランナー, KEYS } から 'clet';
it('ボイラープレートで動作するはずです', async () => { awaitrunner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // stdout を待ってから応答します。 .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // stdout を検証します。 .notStderr(/ npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // ファイルを検証する });
軽量のページ クローリングの場合は、HTTP を使用してライブラリを直接リクエストすることをお勧めします。
ブラウザの実際の実行をシミュレートするには、初期には Selenium と phantomjs が使用されていました。
その後、Google は Chromium の蓄積と devtools-protocol プロトコルに基づいた puppeteer を正式にリリースしましたが、すぐに人気が高まり、最初の 2 つは廃止されました。同様の競合製品としては、Playwright や Cypress などがあります。
ちなみに、macacajs をダウンロードします。これは、ブラウザに加えて、モバイル APP とデスクトップ APP のテストもサポートしています。これは、Yuque チームのエンジニアによってオープンソース化されています。
オープンソースを作成する場合、多くの場合、テストに役立つ自動化された継続的インテグレーション サービスが必要になります。
この分野のプレーヤーには、Travis、Appveyor、GitHub Actions などが含まれます。
現在、私は基本的に GitHub Actions を使用していますが、統合のレベルは非常に優れています。
単体テストが非常に重要であることは疑いなく、資格のあるプログラマーに必要な能力と専門的資質です。
もちろん、私たちは 100% カバレッジを重視するわけではありません。多くの場合、ROI のバランスポイントを追求する必要があります。
まず最初に、よくある初心者の視点を修正させてください。単体テストを書くのは時間の無駄なのでしょうか?
実際、単体テストを作成すると時間を節約できます。その理由は、比較条件が客観的ではないことが多いためです。同じ品質要件の下でコードを 2 回変更した後の回帰コストを考慮する必要があります。
公平に比較するには、「単一のテストを作成する時間」に加えて、「コードを変更するたびに回帰テストを実行する時間」も見落とされがちです。
単一のテストを作成する場合、初期段階でさまざまなブランチ モックを作成します。回帰テストの時間はキーボードを入力するだけです。
単一のテストを作成せずに、アプリケーションのコードを更新し、ブラウザを開いてさまざまな場所をクリックするなど、さまざまな状況を手動でシミュレートしてテストする必要があります。
この 2 つの作業にどれだけ時間がかかるかは一目瞭然です。
初期投資＋保守コスト＋リターンの質を重視して、それらを天秤にかけた上で意思決定するのが各社独自の尺度があるだけです。
もちろん、私が言及したシナリオの多くは、フレームワーク ライブラリ (フロントエンドや Node.js を含む)、サーバー側アプリケーション、コマンド ライン ツールなどです。一部のフロントエンド アプリケーションで大きな変更が加えられたことは事実です。 UI の表示や高速なロードとアンロードは、アクティビティ ページの場合、対応する単一テストのメンテナンス コストが実際に非常に高くなります。現時点では、ROI に基づいて、一部の非コア ブランチの単一テストを適切に放棄するのが妥当です。
ただし、これは最後の手段であることを理解する必要があります。さまざまな方法で単体テストのメンテナンス コストを削減できますが、単体テストが役に立たないと主張することはできません。
フロントエンドフィールドには半自動回帰テストもあり、これは差分に基づいて比較を自動化し、変更の影響に注意を払うように所有者に通知します。これは上記のツール ライブラリと同様で、単一のテストを作成するコストを削減するために用意されています。
これも間違った考え方です。単体テストはプログラマ自身が書くべきであり、それは自分自身のコードであり、自分自身が責任を負わなければなりません。これは一種のプロフェッショナリズムです。標準化を少しでも行っているチームは、コードを提出するときに CI テストが必要です。そうしないと、質の高いコード レビューのコラボレーションが行われません。
テスト生は、統合テスト、回帰テスト、エンドツーエンド テストなど、より大きなレベルの作業を担当します。
役割分担が違うので他人のせいにしないでください。
単体テストは非常に必要です。単体テストを作成することは、プログラマの基本的な資質です。個々のシナリオでは、ROI に基づいて選択できます。