[コンパイルと共有] Node.jsで使用できるいくつかのテストフレームワーク

ノードどのようなテスト フレームワークを使用できますか?次の記事では、Node.js テスト フレームワークをいくつか紹介します。

編集者注: この記事の著者は、Ant Group Node.js のエンジニアである Tianzhu です。まず、よく使用されるクラスを紹介します。記事の最後に、単体テストが必要かどうかについて議論しましょう。一緒に議論することを歓迎します。

一般的に使用されるクラス ライブラリとツール

テスト ケース エグゼキューター

mocha および jest がより頻繁に使用されます。公式の新しい node test はまだ改良中であり、将来は有望です。

$ mocha

  test/egg-view-ejs.test.js
    render
      ✓ should render with locals
      ✓ should render with cache
      ✓ should render with layout
      ✓ should render error
    renderString
      ✓ should renderString with data
      ✓ should renderString error

  6 passing (398ms)

ランナーの数は非常に多いですが、出力規格はすべて TAP 形式であり、結果はさまざまなレポーターを通じて出力されます。

カバレッジ統計

単一のテストを書くだけでは十分ではなく、コードのすべての分岐プロセスがカバーされているかどうかを知る必要があります。通常、コード カバレッジ レート ツールと組み合わせて使用​​されます。

以前は istanbuljs でしたが、後に作成者が nyc に書き換えました。主に 2 つの役割を担っています。1 つは、コードを翻訳して杭打ちコードを挿入することです。もう 1 つは、さまざまなレポーターをサポートしてカバレッジ レポートを作成することです。

その後、V8 にはカバレッジ統計が組み込まれています。

つまり、コードを変換する必要がなくなり、カバレッジ データの収集がネイティブでサポートされます。

その後、この著者はカバレッジ レポートの生成に焦点を当てて c8 を書きました。

Assert クラス ライブラリ

変数の結果を検証するには、assert が不可欠です。

これまでに登場したもの: expect.js、Should.js、chai、および power-assert、 jest には独自の組み込みの Expect もあります。

しかし、公式の Node.js assert/strict は実際には非常に優れています。

その中で、私たち EggJS が使用しているのが power-assert です。私も何年も前に「おそらく最高の JS Assert ライブラリ - The Empire's New Clothes」と良いコメントをしました。 。

const assert = require('power-assert');

describe('test/showcase.test.js', () => {
  const arr = [ 1, 2, 3 ];

  it('power-assert', () => {
    assert(arr[1] === 10);
  });
});

// output:
4) test/showcase.test.js power-assert:

      AssertionError:   # test/showcase.test.js:6

  assert(arr[1] === 10)
         |  |   |
         |  2   false
         [1,2,3]

  [number] 10
  => 10
  [number] arr[1]
  => 2

PS: ファイルの内容を確認したい場合は、assert-file も作成しました。ぜひ試してみてください。

モック & スタブ クラス ライブラリ

これは単体テストであるため、多くの場合、環境またはダウンストリームの応答をシミュレートする必要があります。

sinonjs 悪くはありません。モックやスタブなどをサポートしています。 jest には独自のモック ライブラリも組み込まれています。

これが HTTP テストの場合、nock は非常に強力で、サーバーの応答を模擬するのに役立ちます。

nock('http://www.example.com')
  .post('/login', 'username=pgte&password=123456')
  .reply(200, { id: '123ABC' })

ただし、公式の Node.js undici リクエスト ライブラリには、組み込みのモック機能もあります。

スナップショットという用語もありますが、これは運用中のデータをダンプし、次のテストの模擬データとして直接使用することを意味し、テスト作成の効率をある程度向上させることができます。

HTTP テスト クラス ライブラリ

HTTP サーバー シナリオをテストするには、supertest ライブラリが不可欠です。

describe('GET /users', function() {
  it('responds with json', async function() {
    return request(app)
      .get('/users')
      .set('Accept', 'application/json')
      .expect('Content-Type', /json/)
      .expect(200)
      .then(response => {
        assert(response.body.email, 'foo@bar.com');
      });
  });
});

コマンド ライン テスト ライブラリ

Node.js の使用シナリオの 1 つは、Webpack や Babel などのコマンド ライン CLI です。これらのライブラリ自体にも必要があります。の単一テスト。

これをお勧めします:

• ##GitHub - ノードモジュール/clet: コマンドライン E2E テスト

• ##GitHub - ノードモジュール/コーヒー: Node.js でコマンド ラインをテストします。

  import {runner, KEYS } from 'clet';
  it('は動作するはずですボイラープレート'、async () => { ランナーを待つ() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // stdout を待ってから応答します .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // 標準出力を検証します .notStderr(/npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // ファイルを検証する });

Web ページ自動テスト ツール

ページを軽くクロールします。HTTP リクエスト ライブラリを直接使用できます。推奨

undici 。

ブラウザの実際の実行をシミュレートするには、初期の頃は

selenium と phantomjs を使用していました。

その後、Google は

puppeteer を正式にリリースしました。Chromium の蓄積と devtools-protocol プロトコルに基づいていたため、すぐに人気が高まり、最初の 2 つは廃止されました。同様の競合製品としては、playwright や cypress などがあります。

ちなみに、

macacajs は、ブラウザだけでなくモバイル APP やデスクトップ APP のテストもサポートするマルチターミナル テスト ツールで、Yuque チームのエンジニアによってオープンソース化されています。

継続的インテグレーション サービス

オープン ソースを作成するとき、多くの場合、テストに役立つ自動化された継続的インテグレーション サービスが必要になります。

この分野のプレーヤーには、

Travis、Appveyor、GitHub Actions などが含まれます。

現在、私は基本的に GitHub Actions を使用していますが、統合レベルは非常に優れています。

#ディスカッション: 単体テストは必要ですか?

単体テストが非常に重要であることは間違いなく、資格のあるプログラマーに必要な能力であり、専門的な資質です。

もちろん、私たちは 100% カバレッジを重視しているわけではなく、多くの場合、ROI のバランスポイントを追求する必要があります。

1.単体テストを書くのは時間の無駄ですか?

まず最初に、よくある初心者の視点を修正させてください:

単体テストを書くのは時間の無駄ですか?

実際には、単体テストを作成すると時間を節約できます。直観に反する考え方の理由は、比較条件が客観的ではないことが多いためです。

同じ品質要件の下でコードを 2 回変更した後の回帰のコストを考慮する必要があります。

公平な比較のために、「単一のテストを作成する時間」を考慮することに加えて、見落とされやすいのは「各コード変更後の回帰テストの時間」です。

単一のテストを書く テストの場合、初期段階でさまざまなブランチモックを作成し、回帰テストの時間はキーボードをタップするだけです;

• 単一のテストを書かない場合は、アプリケーションのコードを更新してから、ブラウザを開いてさまざまな場所をクリックするなど、さまざまな状況でさまざまなテストを手動でシミュレートする必要があります。
• この2つがいかに時間がかかるかは一目瞭然です。

あくまで初期投資と維持費にすぎず、返品の品質を重視し、それを天秤にかけた上での意思決定という点では、各社それぞれの尺度があります。

もちろん、私が述べたシナリオの多くは、フレームワーク ライブラリ (フロントエンドや Node.js を含む)、サーバー側アプリケーション、コマンド ライン ツールなどです。

これは事実です。いくつかの大きな変更があります フロントエンドの部分的な UI 表示や高速アップおよび高速ダウンのアクティビティ ページを備えたアプリケーションには、単体テストのメンテナンス コストが非常に高くなります。現時点では、一部の非コア ブランチ ベースの単体テストを適切に放棄するのが合理的です。 ROIについて。

しかし、これは最後の手段であることを理解する必要があり、さまざまな方法で単一テストのメンテナンス コストを削減できますが、単体テストが役に立たないと主張することはできません。

フロントエンド分野には半自動回帰テストもあります。これは、差分に基づいて比較を自動化し、変更の影響に注意を払うように所有者に通知します。これは上記のツール ライブラリと同様で、単一のテストを作成するコストを削減するために用意されています。

2. 単体テストはプログラマが書くべきではないでしょうか?

これも間違った見方です。単体テストはプログラマ自身が書くべきです。なぜならそれはあなた自身のコードであり、あなたが責任を負わなければならないからです。これはある種のことです。プロ意識。標準化を少しでも行っているチームは、コードを提出するときに CI テストを行う必要があります。そうしないと、質の高いコード レビューのコラボレーションが行われません。

テスト受講生は、統合テスト、回帰テスト、エンドツーエンド テストなどの より大きなレベルの作業を担当します。

分業は違います、他人のせいにしないでください。

so...

単体テストは非常に必要です。単体テストを書くのはプログラマの基本的な職業的資質です。できる限りたくさん書いて構いません。シナリオに応じて、ROI をトレードオフできます。

ノード関連の知識の詳細については、nodejs チュートリアル を参照してください。

以上が[コンパイルと共有] Node.jsで使用できるいくつかのテストフレームワークの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。