MIT🎊2022年4月の発表:5つの新しいベストプラクティス、さらに多くのコード例、4つの新しい言語翻訳を含む新しいエディションがリリースされました。👨‍🏫次のワークショップ:イタリア、ヴェローナ🇮🇹、4月20日。📗50以上のベストプラクティス:非常に包括的で網羅的これは、AZのJavaScriptとNode.jsの信頼性に関するガイドです。それはあなたのために市場が提供しなければならない何十もの最高のブログ投稿、本とツールを要約してキュレートします🚢上級:基本を10,000マイル超えます基本を超えて、本番環境でのテスト、ミューテーションテスト、プロパティベースのテスト、その他多くの戦略的および専門的なツールなどの高度なトピックに進む旅に飛び込みましょう。このガイドのすべての単語を読むと、テストスキルは平均をはるかに超える可能性があります🌐フルスタック:フロント、バックエンド、CI、その他まず、あらゆるアプリケーション層の基盤となるユビキタスなテスト手法を理解することから始めます。UI、バックエンド、CI、またはそれらすべて)を詳しく調べます。テストコードは本番コードではありません-短く、非常にシンプルで、フラットで、操作しやすいように設計してください。テストを見て、すぐに意図を理解する必要があります。ほら、私たちの心はすでに私たちの主な仕事であるプロダクションコードに専念しています。複雑にするための「ヘッドスペース」はありません。別のsusシステムを貧弱な脳に押し込もうとすると、チームの速度が低下し、テストを行う理由に反します。実際には、これは多くのチームがテストを放棄する場所です。テストは他の何かのための機会です-小さな投資で大きな価値を提供するフレンドリーなアシスタント、副操縦士。科学によると、私たちには2つの脳システムがあります。システム1は空の道路で車を運転するなどの楽な活動に使用され、システム2は数学の方程式を解くなどの複雑で意識的な操作を目的としています。システム1のテストを設計します。テストコードを見ると、2X(17×24)を解くのではなく、HTMLドキュメントを変更するのと同じくらい簡単に感じるはずです。これは、費用対効果が高く、優れたROIを提供する、選択的にチェリーピッキングする手法、ツール、およびテストターゲットによって実現できます。必要なだけテストし、機敏に保つように努めます。場合によっては、いくつかのテストを中止し、信頼性を敏捷性と単純さと引き換えにする価値さえあります。以下のアドバイスのほとんどは、この原則の派生物です。実施:テストレポートでは、現在のアプリケーションリビジョンが、コードに必ずしも精通していない人々(テスター、デプロイしているDevOpsエンジニア、および2年後の将来)の要件を満たしているかどうかを確認する必要があります。これは、テストが要件レベルで記述され、次の3つの部分が含まれている場合に最もよく達成できます。それ以外の場合:展開が失敗したばかりで、「製品の追加」という名前のテストが失敗しました。これは、正確に何が誤動作しているのかを教えてくれますか?👇注:各箇条書きにはコード例があり、場合によっては画像のイラストもあります。実施:アレンジ、アクト、アサーション(AAA)の3つのセクションでテストを構成します。この構造に従うことで、読者がテスト計画の理解に頭脳CPUを費やさないことが保証されます。1番目のA-配置:テストがシミュレートすることを目的としたシナリオにシステムを導入するためのすべてのセットアップコード。これには、テスト中のユニットコンストラクターのインスタンス化、DBレコードの追加、オブジェクトのモック/スタブ、およびその他の準備コードが含まれる場合があります。2番目のA-行為:テスト中のユニットを実行します。通常、1行のコード3番目のA-アサート:受信した値が期待値を満たしていることを確認します。実施:テストを宣言型でコーディングすることで、読者は脳とCPUのサイクルを1つも費やすことなく、即座に手に入れることができます。条件付きロジックが詰め込まれた命令型コードを書くと、リーダーはより多くのブレインCPUサイクルを実行することを余儀なくされます。その場合、カスタムコードを使用するexpectかどうかにかかわらず、人間のような言語、宣言型BDDスタイルで期待値をコーディングします。shouldChai&Jestに目的のアサーションが含まれておらず、再現性が高い場合は、Jestマッチャー(Jest)を拡張するか、カスタムChaiプラグインを作成することを検討してください。それ以外の場合:チームはテストの記述を減らし、迷惑なテストを.skip()で装飾します。👎アンチパターンの例:読者は、テストストーリーを取得するためだけに、それほど短くなく、命令型のコードをざっと読む必要があります。実施:内部をテストすると、ほとんど何もせずに大きなオーバーヘッドが発生します。コード/APIが正しい結果を提供する場合、内部でどのように機能するかをテストするために次の3時間を本当に投資してから、これらの脆弱なテストを維持する必要がありますか?パブリック動作がチェックされるときはいつでも、プライベート実装も暗黙的にテストされ、特定の問題(たとえば、間違った出力)がある場合にのみテストが失敗します。それ以外の場合:テストは、オオカミを泣いた少年のように動作します:偽陽性の叫びを叫びます(たとえば、プライベート変数名が変更されたため、テストは失敗します)。実施:テストダブルはアプリケーションの内部に結合されているため、必要な悪ですが、いくつかは計り知れない価値を提供します(テストダブルについてのリマインダーをここで読んでください:モックvsスタブvsスパイ)。テストダブルを使用する前に、非常に簡単な質問をしてください。要件ドキュメントに表示される、または表示される可能性のある機能をテストするために使用しますか?いいえの場合、それはホワイトボックステストの匂いです。支払いサービスがダウンしているときにアプリが適切に動作することをテストする場合は、支払いサービスをスタブし、「応答なし」の戻りをトリガーして、テスト対象のユニットが正しい値を返すことを確認します。これにより、特定のシナリオでのアプリケーションの動作/応答/結果がチェックされます。スパイを使用して、そのサービスがダウンしたときに電子メールが送信されたことを表明することもできます。これも、要件ドキュメントに表示される可能性のある動作チェックです(「支払いを保存できなかった場合は電子メールを送信してください」)。反対に、Paymentサービスをモックして、適切なJavaScriptタイプで呼び出されたことを確認すると、テストは、アプリケーションの機能とは関係がなく、頻繁に変更される可能性のある内部的なものに焦点が当てられます。それ以外の場合:コードのリファクタリングでは、コード内のすべてのモックを検索し、それに応じて更新する必要があります。実施:多くの場合、本番環境のバグは、非常に具体的で驚くべき入力の下で明らかになります。テスト入力が現実的であるほど、バグを早期に発見できる可能性が高くなります。ChanceやFakerなどの専用ライブラリを使用して、本番データの多様性と形式に似た疑似実データを生成します。このようなライブラリは、現実的な電話番号、ユーザー名、クレジットカード、会社名、さらには「loremipsum」テキストを生成できます。偽造者のデータをランダム化してテスト対象のユニットを拡張したり、実稼働環境から実際のデータをインポートしたりするテストを(ユニットテストに加えて、代替としてではなく)作成することもできます。それを次のレベルに引き上げたいですか?次の箇条書き(プロパティベースのテスト)を参照してください。3e2ddsf」などの厄介な文字列を渡すと、本番環境が赤色に変わる可能性があります。##'1fdsfds。実施:通常、テストごとにいくつかの入力サンプルを選択します。"string"、false、0))のみを取り上げます。本番環境では、5つのパラメーターで呼び出されるAPIを数千の異なる順列で呼び出すことができ、そのうちの1つでプロセスがダウンする可能性があります(ファズテストを参照)。さまざまな入力の1000の順列を自動的に送信し、コードが正しい応答を返さない入力をキャッチする単一のテストを作成できるとしたらどうでしょうか。プロパティベースのテストは、まさにそれを行う手法です。可能なすべての入力の組み合わせをテスト対象のユニットに送信することで、バグを見つける可能性が高まります。Galaxy)のような(number、string、boolean)の多くの組み合わせでこのメソッドを呼び出します。js-verifyやtestcheck(はるかに優れたドキュメント)などのライブラリを使用して、お気に入りのテストランナー(Mocha、Jestなど)を使用してプロパティベースのテストを実行できます。Dubienは、以下のコメントで次のように提案しています。それ以外の場合:無意識のうちに、適切に機能するコードパスのみをカバーするテスト入力を選択します。実施:スナップショットテストが必要な場合は、テスト(インラインスナップショット)の一部として含まれ、外部ファイルには含まれない、短く焦点を絞ったスナップショット(つまり、3〜7行)のみを使用します。このガイドラインを守ることで、テストが自明で脆弱性が少なくなることが保証されます。JSON結果など)を外部メディアに保存し、テストを実行するたびに、受信した結果と保存したバージョンを比較することをお勧めします。これは、たとえば、テストライターが読み取ったり推論したりしたことのない3000のデータ値を持つ1000行にテストを暗黙的に結合する可能性があります。これが間違っているのですか?そうすることで、テストが失敗する理由は1000あります。スナップショットが無効になるには、1行を変更するだけで十分であり、これは頻繁に発生する可能性があります。どのくらいの頻度で?すべてのスペース、コメント、またはCSS/HTMLのマイナーな変更。これだけでなく、テスト名は1000行が変更されていないことを確認するだけなので、失敗についての手がかりを与えません。テストライターは、検査および検証できなかった長いドキュメントを目的の真として受け入れることをお勧めします。これらはすべて、焦点が絞られておらず、達成しすぎることを目的とした、あいまいで熱心なテストの症状です。データではなくスキーマでアサートする場合(値を抽出してフィールドに焦点を合わせる場合)、または受信したドキュメントがめったに変更されない場合など、長い外部スナップショットが受け入れられるケースはほとんどないことに注意してください。UIテストは失敗します。行う:テスト結果に影響を与える必要な詳細をすべて含めますが、それ以上は含めません。例として、100行の入力JSONを因数分解する必要があるテストを考えてみましょう-これをすべてのテストに貼り付けるのは面倒です。それを外部でtransferFactory.getJSON()に抽出すると、テストがあいまいになります-データがないと、テスト結果を原因と関連付けるのは困難です(「なぜ400ステータスを返すことになっているのですか?」)。このパターンを「ミステリーゲスト」と名付けた古典的な本のxユニットパターン-目に見えない何かがテスト結果に影響を与えました。正確には何がわかりません。繰り返し可能な長い部分を外側に抽出し、どの特定の詳細がテストに重要であるかを明示的に言及することで、より良い結果を得ることができます。上記の例を使用すると、テストは重要なものを強調するパラメーターを渡すことができます:transferFactory.getJSON({sender:undefined})。500のJSON行をコピーすると、テストが保守できなくなり、読み取り不能になります。実施:一部の入力がエラーをトリガーすることを表明しようとすると、try-catch-finallyを使用するのが正しいように見え、catch句が入力されたことを表明します。結果は、単純なテストの意図と結果の期待を隠す厄介で冗長なテストケース(以下の例)です。洗練された代替手段は、1行の専用Chaiアサーションを使用することです:expect(method).to.throw(またはJestではexpect(method).toThrow())。例外にエラータイプを示すプロパティが含まれていることも確認する必要があります。しないと、一般的なエラーが発生した場合、アプリケーションはユーザーに期待外れのメッセージを表示するのではなく、多くのことを実行できなくなります。実施:さまざまなシナリオでさまざまなテストを実行する必要があります。クイックスモーク、IOレス、開発者がファイルを保存またはコミットするときにテストを実行する必要があります。通常、新しいプルリクエストが送信されると、完全なエンドツーエンドのテストが実行されます。#sanityなどのキーワードでテストにタグを付けることで実現できるため、テストハーネスを使用してgrepを実行し、目的のサブセットを呼び出すことができます。これは、Mochaを使用して健全性テストグループのみを呼び出す方法です。それ以外の場合:数十のDBクエリを実行するテストを含むすべてのテストの実行は、開発者が小さな変更を加えるたびに非常に遅くなり、開発者がテストを実行できないようにします。実施:テストスイートに構造を適用して、不定期の訪問者が要件(テストが最適なドキュメント)とテストされているさまざまなシナリオを簡単に理解できるようにします。これの一般的な方法は、テストの上に少なくとも2つの「describe」ブロックを配置することです。1つ目はテスト対象のユニットの名前用で、2つ目はシナリオやカスタムカテゴリなどの追加レベルの分類用です(コード例と印刷を参照)下の画面)。することで、テストレポートも大幅に改善されます。読者は、テストカテゴリを簡単に推測し、目的のセクションを掘り下げて、失敗したテストを相互に関連付けることができます。開発者が多くのテストを含むスイートのコードをナビゲートするのがはるかに簡単になります。テストスイートには、次のように考えることができる複数の代替構造があります。それ以外の場合:テストのフラットで長いリストを含むレポートを見る場合、読者は長いテキストをざっと読んで主要なシナリオを結論付け、失敗するテストの共通性を関連付ける必要があります。次の場合を考えてみましょう。7/100テストが失敗した場合、フラットリストを見るには、失敗したテストのテキストを読んで、それらが互いにどのように関連しているかを確認する必要があります。階層レポートでは、それらすべてが同じフローまたはカテゴリに属している可能性があり、読者は根本的な障害の原因が何であるか、少なくともどこにあるかをすばやく推測します。👏正しい方法の例:テスト対象のユニットの名前とシナリオを使用してスイートを構築すると、以下に示す便利なレポートが表示されます。実施:この投稿は、ノードJSに関連する、または少なくともノードJSで例示できるテストアドバイスに焦点を当てています。この箇条書きでは、よく知られているノードに関連しないヒントをいくつかグループ化しています。TDDの原則を学び、実践します。多くの人にとって非常に価値がありますが、自分のスタイルに合わなくても恐れることはありません。あなただけではありません。コードの前に赤緑リファクタースタイルでテストを作成することを検討し、バグを見つけたときに各テストが1つだけチェックすることを確認します。修正する前に、将来このバグを検出するテストを作成し、少なくとも各テストを失敗させます。緑色に変わる前に、テストを満たす迅速で単純なコードを記述してモジュールを開始します。次に、徐々にリファクタリングして製品グレードレベルにし、環境(パス、OSなど)への依存を回避します。実施:テストピラミッドは10年以上前のものですが、3つのテストタイプを提案し、ほとんどの開発者のテスト戦略に影響を与える、優れた関連モデルです。同時に、一握り以上の光沢のある新しいテスト手法が出現し、テストピラミッドの陰に隠れています。最近10年間に見られたすべての劇的な変化(マイクロサービス、クラウド、サーバーレス)を考えると、1つの非常に古いモデルがすべてのタイプのアプリケーションに適合する可能性さえありますか?テストの世界では、新しいテスト手法を歓迎することを検討すべきではありませんか?誤解しないでください。2019年のテストピラミッド、TDD、および単体テストは依然として強力な手法であり、おそらく多くのアプリケーションに最適です。他のモデルと同じように、その有用性にもかかわらず、それは時々間違っているに違いありません。RabbitMQのようなメッセージバスに多くのイベントを取り込み、データウェアハウスに流れ込み、最終的に分析UIによってクエリされるIoTアプリケーションについて考えてみます。統合中心でロジックがほとんどないアプリケーションの単体テストの作成に、テスト予算の50%を実際に費やす必要がありますか?アプリケーションタイプ(ボット、暗号、Alexaスキル)の多様性が増すにつれて、テストピラミッドが最適ではないシナリオを見つける可能性が高くなります。テストポートフォリオを充実させ、より多くのテストタイプ(次の箇条書きはいくつかのアイデアを提案します)、テストピラミッドのようなマインドモデルに精通するときですが、テストタイプを直面している実際の問題に一致させます(「ねえ、私たちのAPI壊れている場合は、消費者主導の契約テストを作成しましょう!')、リスク分析に基づいてポートフォリオを構築する投資家のようにテストを多様化します—問題が発生する可能性のある場所を評価し、それらの潜在的なリスクを軽減するためのいくつかの予防策と一致させます注意の言葉:ソフトウェアの世界でのTDDの議論は、典型的な誤った二分法の顔を取り、どこでもそれを使用するように説教する人もいれば、それが悪魔だと考える人もいます。それ以外の場合:ファズ、リント、ミューテーションなど、驚くべきROIを備えたツールを見逃してしまいます。10分で価値が得られます。—同じ方法」で豊富なテストポートフォリオを提案しています。実施:各単体テストはアプリケーションのごく一部をカバーし、全体をカバーするのに費用がかかりますが、エンドツーエンドのテストは簡単に多くの領域をカバーしますが、不安定で時間がかかります。バランスの取れたアプローチを適用して、単体テストよりも大きいが、エンドツーエンドのテストよりも小さい?コンポーネントテストは、テストの世界で歌われていない歌です。これらは、妥当なパフォーマンスとTDDパターンを適用する可能性+現実的で優れたカバレッジという、両方の世界から最高のものを提供します。コンポーネントテストはマイクロサービスの「ユニット」に焦点を当て、APIに対して機能し、マイクロサービス自体に属するもの(たとえば、実際のDB、または少なくともそのDBのメモリ内バージョン)をモックしませんが、外部のものをスタブします他のマイクロサービスへの呼び出しのように。することで、デプロイする内容をテストし、アプリに外側から内側にアプローチし、妥当な時間内に大きな自信を得ることができます。行う:したがって、マイクロサービスには複数のクライアントがあり、互換性の理由からサービスの複数のバージョンを実行します(全員を満足させます)。次に、いくつかのフィールドを変更して「ブーム!」とすると、このフィールドに依存している重要なクライアントが怒っています。これは統合の世界のキャッチ22です。サーバー側が複数のクライアントの期待をすべて考慮することは非常に困難です—一方、サーバーがリリース日を制御するため、クライアントはテストを実行できません。契約の問題を軽減できるさまざまな手法があります。単純なものもあれば、機能が豊富で、より急な学習曲線が必要なものもあります。シンプルで推奨されるアプローチでは、APIプロバイダーはAPIタイピング(JSDoc、TypeScriptなど)を使用してnpmパッケージを公開します。次に、消費者はこのライブラリをフェッチして、コードインタイムインテリセンスと検証の恩恵を受けることができます。使用するためのより手の込んだアプローチ非常に破壊的なアプローチでこのプロセスを形式化するために生まれたPACT—サーバーがそれ自体のテスト計画を定義するのではなく、クライアントが...サーバーのテストを定義します!PACTはクライアントの期待を記録し、共有の場所「ブローカー」に配置できるため、サーバーは期待を引き出し、PACTライブラリを使用してすべてのビルドで実行し、壊れた契約(クライアントの期待が満たされていない)を検出できます。CIの早い段階で検出され、フラストレーションを大幅に軽減できる可能性があります。実施:ミドルウェアテストはシステムのごく一部を表し、ライブExpressサーバーを必要とするため、多くの場合ミドルウェアテストを回避します。両方の理由が間違っています—ミドルウェアは小さいですが、すべてまたはほとんどのリクエストに影響を与え、{req、res}JSオブジェクトを取得する純粋関数として簡単にテストできます。ミドルウェア関数をテストするには、ミドルウェア関数を呼び出して、{req、res}オブジェクトとの相互作用をスパイし(たとえばSinonを使用)、関数が正しいアクションを実行したことを確認する必要があります。ライブラリnode-mock-httpはそれをさらに進め、{req、res}オブジェクトをそれらの動作をスパイするとともに因数分解します。実施:静的分析ツールを使用すると、コードの品質を向上させ、コードを保守しやすくするための客観的な方法を提供できます。静的分析ツールをCIビルドに追加して、コードの臭いが見つかったときに中止することができます。プレーンリンティングに対する主なセールスポイントは、複数のファイルのコンテキストで品質を検査し(重複の検出など)、高度な分析を実行し(コードの複雑さなど)、コードの問題の履歴と進行状況を追跡できることです。Climate(2,000以上の星)です。それ以外の場合:コードの品質が低いと、バグとパフォーマンスが常に問題になり、光沢のある新しいライブラリや最先端の​​機能では修正できません。実施:奇妙なことに、ほとんどのソフトウェアテストはロジックとデータのみを対象としていますが、発生する(そして軽減するのが非常に難しい)最悪の事態のいくつかはインフラストラクチャの問題です。カオスエンジニアリングはNetflixによって生まれました。これは、混沌とした問題に対するアプリの復元力をテストするための認識、フレームワーク、ツールを提供することを目的としています。有名なツールの1つであるカオスモンキーは、サーバーをランダムに強制終了して、サービスが単一のサーバーに依存せずにユーザーにサービスを提供できるようにします(Kubernetesバージョンのkube-monkeyもあります)、それはポッドを殺します)。👏正しく行う例::Node-chaosは、あらゆる種類のNode.jsいたずらを生成する可能性があるため、アプリがカオスに対してどの程度回復力があるかをテストできます。実施:黄金律(箇条書き0)に従って、各テストは、結合を防ぎ、テストフローについて簡単に推論できるように、独自のDB行のセットを追加して処理する必要があります。実際には、パフォーマンスを向上させるために、テストを実行する前にDBにデータをシードするテスター(「テストフィクスチャ」とも呼ばれます)は、これに違反することがよくあります。パフォーマンスは確かに有効な懸念事項ですが、軽減することはできますが(「コンポーネントのテスト」の箇条書きを参照)、テストの複雑さは非常に苦痛な悲しみであり、ほとんどの場合、他の考慮事項を左右するはずです。実際には、各テストケースに必要なDBレコードを明示的に追加し、それらのレコードのみに作用するようにします。パフォーマンスが重大な懸念事項になる場合—バランスの取れた妥協は、データを変更しない唯一のテストスイート(クエリなど)をシードするという形で発生する可能性があります。それ以外の場合:失敗するテストはほとんどなく、展開は中止されます。チームは貴重な時間を費やす予定です。行う:テストがデータベースをクリーンアップするタイミングによって、テストの記述方法が決まります。実行可能な2つのオプションは、すべてのテスト後のクリーニングと、すべてのテスト後のクリーニングです。後者のオプションを選択すると、すべてのテストの後にクリーニングすることで、テーブルがクリーンになり、開発者にとって便利なテスト特典が構築されます。テストの開始時に他のレコードは存在しません。どのデータがクエリされているかを確認でき、アサーション中に行をカウントしたくなる場合もあります。これには重大な欠点があります。マルチプロセスモードで実行すると、テストが相互に干渉する可能性があります。process-1はテーブルをパージしますが、その瞬間、process-2はデータを照会して失敗します(DBがprocess-1によって突然削除されたため)。失敗したテストのトラブルシューティングは困難です。DBにアクセスしても、レコードは表示されません。2番目のオプションは、すべてのテストファイルが終了した後(または毎日!)にクリーンアップすることです。このアプローチは、既存のレコードを持つ同じDBがすべてのテストとプロセスに対応することを意味します。お互いのつま先を踏まないようにするには、テストは追加した特定のレコードを追加して処理する必要があります。いくつかのレコードが追加されたことを確認する必要がありますか?他にも数千のレコードがあり、明示的に追加されたレコードを照会するとします。レコードが削除されたことを確認する必要がありますか?空のテーブルを想定することはできません。この特定のレコードが存在しないことを確認してください。この手法は、いくつかの強力な利点をもたらします。開発者が何が起こったのかを理解したい場合、マルチプロセスモードでネイティブに機能します。データはそこにあり、削除されません。DBはレコードでいっぱいであり、人為的に空ではないため、バグを見つける可能性が高くなります。ここで完全な比較表を参照してください。それ以外の場合:レコードを分離したりクリーンアップしたりする戦略がない場合-テストは互いに足を踏み入れます。👏すべてのテスト後のクリーニング。すべての実行後に必ずしも必要ではありません。テストの実行中に取得するデータが多いほど、本番環境の特典に似ています。APIがヒットしないようにすることで、テスト対象のコンポーネントを分離します。Nockは、外部サービスの動作を定義するための便利な構文を提供するため、このミッションに最適なツールです。分離は、ノイズやパフォーマンスの低下を防ぐために必須ですが、主にさまざまなシナリオや応答をシミュレートするために必要です-優れたフライトシミュレーターは、澄んだ青い空を描くことではなく、安全な嵐や混乱をもたらすことです。これは、他の世界を巻き込むことなく、常に単一のコンポーネントに焦点を当てる必要があるマイクロサービスアーキテクチャで強化されています。テストダブル(モッキング)を使用して外部サービスの動作をシミュレートすることは可能ですが、展開されたコードに触れずにネットワークレベルで動作して、テストを純粋なブラックボックスに保つことが望ましいです。それ以外の場合:一部のサービスは、通常はDockerを使用して、呼び出し元がローカルにデプロイできる偽のバージョンを提供します。これにより、セットアップが簡単になり、パフォーマンスが向上しますが、さまざまな応答のシミュレーションには役立ちません。実施:統合を確認するときは、幸せな道と悲しい道を超えてください。500エラーなど)だけでなく、応答が遅くタイムアウトしたなどのネットワークレベルの異常も確認してください。これは、コードが回復力があり、タイムアウト後に正しいパスをとるなどのさまざまなネットワークシナリオを処理でき、脆弱な競合状態がなく、再試行用の回路ブレーカーが含まれていることを証明します。評判の良いインターセプターツールは、ときどき失敗する多忙なサービスのようなさまざまなネットワーク動作を簡単にシミュレートできます。それ以外の場合:すべてのテストに合格します。サードパーティが例外的な応答を送信したときにクラッシュするか、エラーを正しく報告しないのは本番環境のみです。実施:テストを計画するときは、5つの典型的なフローの出力をカバーすることを検討してください。テストが何らかのアクション(API呼び出しなど)をトリガーしているとき、反応が発生し、何か意味のあることが発生し、テストが必要になります。私たちは物事がどのように機能するかを気にしないことに注意してください。私たちの焦点は、結果、つまり外部から目立ち、ユーザーに影響を与える可能性のあるものにあります。これらの結果/反応は、5つのカテゴリに分類できます。•応答–テストは(APIなどを介して)アクションを呼び出し、応答を取得します。応答データの正確性、スキーマ、およびHTTPステータスのチェックに関係するようになりました•新しい状態-アクションを呼び出した後、公的にアクセス可能なデータの一部が変更されている可能性があります•外部呼び出し-アクションを呼び出した後、アプリはHTTPまたはその他のトランスポートを介して外部コンポーネントを呼び出す場合があります。•メッセージキュー-フローの結果は、キュー内のメッセージになる可能性があります•可観測性–エラーや顕著なビジネスイベントなど、監視する必要のあるものがいくつかあります。トランザクションが失敗した場合、正しい応答だけでなく、正しいエラー処理と適切なロギング/メトリックも期待されます。/管理者)に直接送信されます。Do:実際のバックエンドを含み、API呼び出しに有効なユーザートークンに依存するE2Eテストでは、ユーザーが作成され、すべてのリクエストにログインするレベルにテストを分離することは報われません。代わりに、テストの実行が開始される前に1回だけログインし(つまり、すべてのフックの前に)、トークンをローカルストレージに保存して、リクエスト間で再利用します。これは、コアテストの原則の1つに違反しているようです。リソースを結合せずにテストを自律的に維持します。これは有効な懸念事項ですが、E2Eテストではパフォーマンスが重要な懸念事項であり、個々のテストを開始する前に1〜3個のAPIリクエストを作成すると、実行時間がひどくなる可能性があります。資格情報を再利用することは、テストが同じユーザーレコードに対して実行する必要があることを意味するわけではありません-ユーザーレコードに依存している場合(例:テストユーザーの支払い履歴)よりも、テストの一部としてこれらのレコードを生成し、他のテストとその存在を共有しないようにしてください。バックエンドは偽造される可能性があることにも注意してください。テストがフロントエンドに焦点を合わせている場合は、フロントエンドを分離してバックエンドAPIをスタブ化する方がよい場合があります(を参照)。実施:本番監視と開発時の健全性チェックのために、サイトのすべて/ほとんどのページにアクセスし、誰も壊れないことを確認する単一のE2Eテストを実行します。このタイプのテストは、作成と保守が非常に簡単であるため、投資収益率が高くなりますが、機能、ネットワーク、および展開の問題を含むあらゆる種類の障害を検出できます。他のスタイルの煙と健全性チェックは、それほど信頼性が高く、網羅的ではありません。一部の運用チームは、ホームページ(本番環境)にpingを送信するだけであるか、パッケージングやブラウザーの問題を発見しない多くの統合テストを実行する開発者です。言うまでもなく、スモークテストは機能テストに取って代わるものではなく、迅速な煙探知器として機能することを目的としています。実施:アプリの信頼性を高めることに加えて、テストはテーブルに別の魅力的な機会をもたらします-ライブアプリのドキュメントとして機能します。テストは本質的に技術的ではなく製品/UX言語で話すため、適切なツールを使用すると、すべてのピア(開発者とその顧客)を大幅に調整するコミュニケーションアーティファクトとして機能できます。一部のフレームワークでは、人間が読める言語を使用してフローと期待(つまり、テスト計画)を表現できるため、製品マネージャーを含むすべての利害関係者が、ライブ要件ドキュメントになったばかりのテストを読み、承認し、共同作業を行うことができます。この手法は、顧客が受け入れ基準を平易な言葉で定義できるため、「受け入れテスト」とも呼ばれます。これはBDD(ビヘイビア駆動テスト)ですその最も純粋な形で。これを可能にする人気のあるフレームワークの1つは、JavaScriptフレーバーを持つCucumberです。以下の例を参照してください。1つの類似しているが異なる機会であるStoryBookを使用すると、UIコンポーネントをグラフィックカタログとして公開でき、各コンポーネントのさまざまな状態をウォークスルーできます(たとえば、フィルターなしでグリッドをレンダリングする、複数行でグリッドをレンダリングする、またはなしでグリッドをレンダリングするなど)。それがどのように見えるか、そしてその状態をトリガーする方法を見てください-これは製品の人々にもアピールできますが、ほとんどの場合、それらのコンポーネントを消費する開発者のためのライブドキュメントとして機能します。実施:正しく行われた場合、テストは24時間年中無休の友人であり、ほぼ瞬時にフィードバックを提供します。実際には、1つのスレッドで500個のCPUバウンドユニットテストを実行すると、時間がかかりすぎる可能性があります。幸いなことに、最新のテストランナーとCIプラットフォーム(Jest、AVA、Mocha拡張機能など)は、テストを複数のプロセスに並列化し、フィードバック時間を大幅に改善することができます。一部のCIベンダーは、コンテナー間でテストを並列化することもあり(!)、フィードバックループをさらに短縮します。ローカルで複数のプロセスを使用する場合でも、複数のマシンを使用するクラウドCLIを使用する場合でも、需要を並列化して、それぞれが異なるプロセスで実行される可能性があるため、テストを自律的に維持します。それ以外の場合:次の機能をすでにコーディングしているため、新しいコードをプッシュしてから1時間後にテスト結果を取得することは、テストの関連性を低くするための優れたレシピです。Overflowからコピーして貼り付けられ、一部の著作権を侵害していると思われるコードなどの悲しみを検査できます。Expressなどの最も信頼できる依存関係でさえ、既知の脆弱性があります。auditなどのコミュニティツール、またはsnykなどの商用ツール(無料のコミュニティバージョンも提供)を使用して簡単に使いこなすことができます。それ以外の場合:専用ツールを使用せずにコードを脆弱性からクリーンに保つには、新しい脅威に関するオンライン出版物を常にフォローする必要があります。Yarnとnpmのpackage-lock.jsonの最新の導入により、深刻な課題が発生しました(地獄への道は善意で舗装されています)—デフォルトでは、パッケージは更新されなくなりました。'npminstall'と'npmupdate'を使用して多くの新しいデプロイメントを実行しているチームでさえ、新しい更新を取得しません。これは、せいぜい標準以下の依存パッケージバージョンにつながるか、最悪の場合脆弱なコードにつながります。チームは現在、開発者の善意とメモリに依存して、package.jsonを手動で更新したり、ncuなどのツールを手動で使用したりしています。信頼性の高い方法は、最も信頼性の高い依存関係バージョンを取得するプロセスを自動化することですが、特効薬の解決策はありませんが、2つの可能な自動化の道があります。Writer概要:私は独立したコンサルタントであり、フォーチュン500企業やガレージの新興企業と協力してJSおよびNode.jsアプリケーションを磨いています。私が魅了され、テストの芸術を習得することを目指している他のどのトピックよりも。Node.jsプロジェクトとWebアプリケーションのセキュリティに取り組むのが大好きです。Copyrights。