ノードに専用のプロのソフトウェア開発者として.JS RESTful API、次の結論に達しました.

Developers are not paid to write code.
They are paid to deliver tech
solutions.

そしてこれらの解決策は.

コンクリートと丈夫な

は負荷

に関係なく、高可用性を有する

信頼性

安全

コスト効果的な

維持可能

開発者はまた、それらの解決策が上記の基準と一致するという証拠を提供することができるべきです.また、検出して、簡単かつ迅速に修正することができます任意のバグや問題が発生する可能性があります.
そして、それはユニットテストが

定義

Unit Testing is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed.
Source: softwaretestingfundamentals.com

しかし、APIの単位はどれですか？

APIの単位は以下の通りです.

APIリクエスト

HTTPメソッド(すなわち取得、ポスト、プット等)APIエンドポイント(すなわちE/V 1/ポスト)

リクエストパラメータ

リクエストヘッダ

リクエストボディモデル

のプロパティ/フィールド

モデル方法

例による学習：事例API

この記事の目的のために、我々は古典的な本図書館(例えば、あなたが本、研究などを借りることができるオリジナルのもの)のために模範APIを使用します
APIは次の要素から構成されます.

実体/モデル

本

ユーザー

終点

取得/ユーザ

ポスト/ユーザー

取得/書籍

ポスト/ブック

エンドポイントには、次のスクリーンショットに示すフォームがあります.
APIが使用するダミーデータを生成するために、faker.jsを使用します.
ゲット/ユーザーエンドポイント

ポスト/ユーザエンドポイント

ゲット/ブックエンドポイント

ポスト/ブックエンドポイント

これまでのところ良い.それぞれの終点が何をするのか、それが反応するデータの形だと思います.
GET/ユーザエンドポイントに対する応答例は次のようになります.

しかし、我々は本当にテストしたいですか？

APIの単体テストを書くことにより、以下のような質問に答えます.

取得/ユーザーは常にユーザーオブジェクトの配列で応答しますか?

ポスト/ブックは、常に予約されたブックオブジェクトで応えますか?

ポスト/ユーザーは、1つ以上の必須のフィールドがなくなっているとき、正しいエラーコードで応えますか?

電子メールが正しい形式を持っていないとき、

はポスト/ユーザーが正しいエラーコードで応えますか?

もちろん、我々のAPIが期待通りに動作していることを確認するために答えたいかもしれない多くの質問があります、しかし、我々の例のために、それらは重要なものです.

コーヒーを飲みましょう

2つの主なライブラリは、ノードの単位テストを記述するために使用します.JSアプリケーションは、主要なテストフレームワークであるMochaとアサーションライブラリであるChaiです.チャイは、我々がずっと簡単に実行したいチェックをする機能を提供します.
アイアイイー

response.should.be.a('string'); 
response.should.not.have.property(‘phone’);

チャイライブラリには、同じことを行う4つのメインインターフェイスがあります
別の構文

は

は、

を主張します

は、

を予想します
以下の3行はまったく同じテストを行います.

email.should.be.a(‘string’) 
expect(email).to.be.a(‘string’) 
assert.typeOf(email,’string’)

パッケージの外観。プロジェクトのファイル

デフォルトnpm test commandでテストを実行するには、scriptsファイルのpackage.jsonキーに次の値を追加します.

"scripts": {
 "test": "nyc mocha --timeout 10000"
}

各テストケースのタイムアウト(テストケースをAPIコールを実行します)を10 k ms(10秒)に設定します.

テストの解剖

テストを見ることができるように

依存症(多くのテストケースに共通する)

の名前と説明

API呼び出し

実際のテスト(アサーション)

Mochaライブラリにテストが完了したことを通知するコールバック.

カバレッジレポートとNYC

nycは、合計コードのどれくらいが我々が書いたテストによってカバーされるかについて報告するツールです.また、どこに見て、どのようなテストを書くかを知るために、すべての覆われている行を報告します.
テスト終了後のカバレッジレポートは次のようになります.

ユニットテストに関する良い慣行

私たちが別々にポストエンドポイントをテストするのに使う異なるペイロードを保存することは、良い実行です.txtまたは.JSONファイル.

別のテスト宣言を作成します.
チェックしたい関数.

私たちは異なった「シナリオ」を形成するためにテストを書くようにしなければなりません.
DBが最初に空であるので、我々は新しいユーザーをポストします、そして、ユーザーは新しい本を投稿しました.

エラーコードやエラーをチェックするテストも書きます.バグと問題は、検証ロジックに隠されるかもしれません.

私たちのAPIが異なるアクセスレベルで

を持っているなら、アクセスレベルをチェックするテストも書くべきです
最終的に、我々は我々がそうすることができるより高い報道に到達しようとしなければなりません.しかし、我々は常に100 %に到達することは不可能であることを心に留めておく必要があります.

それはすべての人々です！

私はあなたがそれを楽しんで、あなたのノードの単位テストを書くのを助けることを望む.将来のJS API.