🎊2022年4月の発表：5つの新しいベストプラクティス、さらに多くのコード例、4つの新しい言語翻訳を含む新しいエディションがリリースされました。

👨‍🏫次のワークショップ：イタリア、ヴェローナ🇮🇹、4月20日。チケットと詳細はこちら

👇このガイドがテストスキルを次のレベルに引き上げることができる理由

📗50以上のベストプラクティス：非常に包括的で網羅的

これは、AZのJavaScriptとNode.jsの信頼性に関するガイドです。それはあなたのために市場が提供しなければならない何十もの最高のブログ投稿、本とツールを要約してキュレートします

🚢上級：基本を10,000マイル超えます

基本を超えて、本番環境でのテスト、ミューテーションテスト、プロパティベースのテスト、その他多くの戦略的および専門的なツールなどの高度なトピックに進む旅に飛び込みましょう。このガイドのすべての単語を読むと、テストスキルは平均をはるかに超える可能性があります

🌐フルスタック：フロント、バックエンド、CI、その他

まず、あらゆるアプリケーション層の基盤となるユビキタスなテスト手法を理解することから始めます。次に、選択した領域（フロントエンド/ UI、バックエンド、CI、またはそれらすべて）を詳しく調べます。

ヨニゴールドバーグ脚本の作品

• JavaScriptとNode.jsのコンサルタント
• 📗 Node.jsとJavaScriptをAからZまでテスト-7時間以上のビデオ、14のテストタイプ、40以上のベストプラクティスを備えた私の包括的なオンラインコース
• Twitterでフォローしてください
• 次のワークショップ：イタリア、ヴェローナ🇮🇹、4月20日

翻訳-あなた自身の言語で読む

• 🇨🇳中国語-Yvesyao提供
• 🇰🇷韓国語-RainByun提供
• 🇵🇱ポーランド語-MichalBiesiada提供
• 🇪🇸スペイン語-MiguelG.Sanguino提供
• 🇧🇷ポルトガル語-BR - IagoAngelimCosta Cavalcante、Douglas Mariano Valero、kooogeの厚意により提供
• 🇫🇷フランス語-MathildeElMouktafi提供
• 🇯🇵日本語（ドラフト）-Yoichi Yogoandryo提供
• 🇹🇼繁体字中国語-YubinHsu提供
• あなた自身の言語に翻訳したいですか？問題を開いてください💜

Table of Contents

Section 0: The Golden Rule

他のすべてを刺激する単一のアドバイス（1つの特別な箇条書き）

Section 1: The Test Anatomy

基盤-クリーンテストの構築（12弾）

Section 2: Backend

バックエンドとマイクロサービスのテストを効率的に作成する（13箇条書き）

Section 3: Frontend

コンポーネントテストとE2Eテストを含むWebUIのテストの作成（11箇条書き）

Section 4: Measuring Tests Effectiveness

警備員を監視する-テスト品質の測定（4つの弾丸）

Section 5: Continuous Integration

JSの世界におけるCIのガイドライン（9箇条書き）

セクション0️⃣：黄金律

⚪️0黄金律：無駄のないテストのための設計

✅ 実施： テストコードは本番コードではありません-短く、非常にシンプルで、フラットで、操作しやすいように設計してください。テストを見て、すぐに意図を理解する必要があります。

ほら、私たちの心はすでに私たちの主な仕事であるプロダクションコードに専念しています。さらに複雑にするための「ヘッドスペース」はありません。さらに別のsusシステムを貧弱な脳に押し込もうとすると、チームの速度が低下し、テストを行う理由に反します。実際には、これは多くのチームがテストを放棄する場所です。

テストは他の何かのための機会です-小さな投資で大きな価値を提供するフレンドリーなアシスタント、副操縦士。科学によると、私たちには2つの脳システムがあります。システム1は空の道路で車を運転するなどの楽な活動に使用され、システム2は数学の方程式を解くなどの複雑で意識的な操作を目的としています。システム1のテストを設計します。テストコードを見ると、2X（17×24）を解くのではなく、HTMLドキュメントを変更するのと同じくらい簡単に感じるはずです。

これは、費用対効果が高く、優れたROIを提供する、選択的にチェリーピッキングする手法、ツール、およびテストターゲットによって実現できます。必要なだけテストし、機敏に保つように努めます。場合によっては、いくつかのテストを中止し、信頼性を敏捷性と単純さと引き換えにする価値さえあります。

以下のアドバイスのほとんどは、この原則の派生物です。

始める準備はできましたか？

セクション1：テストの構造

⚪️1.1各テスト名に3つの部分を含める

✅ 実施：テストレポートでは、現在のアプリケーションリビジョンが、コードに必ずしも精通していない人々（テスター、デプロイしているDevOpsエンジニア、および2年後の将来）の要件を満たしているかどうかを確認する必要があります。これは、テストが要件レベルで記述され、次の3つの部分が含まれている場合に最もよく達成できます。

（1）何がテストされていますか？たとえば、ProductsService.addNewProductメソッド

（2）どのような状況とシナリオで？たとえば、メソッドに価格が渡されることはありません

（3）期待される結果は何ですか？たとえば、新製品は承認されていません

❌ それ以外の場合：展開が失敗したばかりで、「製品の追加」という名前のテストが失敗しました。これは、正確に何が誤動作しているのかを教えてくれますか？

👇注：各箇条書きにはコード例があり、場合によっては画像のイラストもあります。クリックして展開

//1. unit under test
describe('Products Service', function() {
  describe('Add new product', function() {
    //2. scenario and 3. expectation
    it('When no price is specified, then the product status is pending approval', ()=> {
      const newProduct = new ProductService().add(...);
      expect(newProduct.status).to.equal('pendingApproval');
    });
  });
});

⚪️1.2AAAパターンによる構造テスト

✅ 実施：アレンジ、アクト、アサーション（AAA）の3つのセクションでテストを構成します。この構造に従うことで、読者がテスト計画の理解に頭脳CPUを費やさないことが保証されます。

1番目のA-配置：テストがシミュレートすることを目的としたシナリオにシステムを導入するためのすべてのセットアップコード。これには、テスト中のユニットコンストラクターのインスタンス化、DBレコードの追加、オブジェクトのモック/スタブ、およびその他の準備コードが含まれる場合があります。

2番目のA-行為：テスト中のユニットを実行します。通常、1行のコード

3番目のA-アサート：受信した値が期待値を満たしていることを確認します。通常、1行のコード

❌ それ以外の場合：メインコードを理解するのに何時間も費やすだけでなく、1日の最も単純な部分（テスト）であるはずだったことが脳を伸ばします

describe("Customer classifier", () => {
  test("When customer spent more than 500$, should be classified as premium", () => {
    //Arrange
    const customerToClassify = { spent: 505, joined: new Date(), id: 1 };
    const DBStub = sinon.stub(dataAccess, "getCustomer").reply({ id: 1, classification: "regular" });

    //Act
    const receivedClassification = customerClassifier.classifyCustomer(customerToClassify);

    //Assert
    expect(receivedClassification).toMatch("premium");
  });
});

test("Should be classified as premium", () => {
  const customerToClassify = { spent: 505, joined: new Date(), id: 1 };
  const DBStub = sinon.stub(dataAccess, "getCustomer").reply({ id: 1, classification: "regular" });
  const receivedClassification = customerClassifier.classifyCustomer(customerToClassify);
  expect(receivedClassification).toMatch("premium");
});

⚪️1.3製品言語で期待を説明する：BDDスタイルのアサーションを使用する

✅ 実施：テストを宣言型でコーディングすることで、読者は脳とCPUのサイクルを1つも費やすことなく、即座に手に入れることができます。条件付きロジックが詰め込まれた命令型コードを書くと、リーダーはより多くのブレインCPUサイクルを実行することを余儀なくされます。その場合、カスタムコードを使用する

expect

should

❌ それ以外の場合：チームはテストの記述を減らし、迷惑なテストを.skip（）で装飾します。

test("When asking for an admin, ensure only ordered admins in results", () => {
  //assuming we've added here two admins "admin1", "admin2" and "user1"
  const allAdmins = getUsers({ adminOnly: true });

  let admin1Found,
    adming2Found = false;

  allAdmins.forEach(aSingleUser => {
    if (aSingleUser === "user1") {
      assert.notEqual(aSingleUser, "user1", "A user was found and not admin");
    }
    if (aSingleUser === "admin1") {
      admin1Found = true;
    }
    if (aSingleUser === "admin2") {
      admin2Found = true;
    }
  });

  if (!admin1Found || !admin2Found) {
    throw new Error("Not all admins were returned");
  }
});

it("When asking for an admin, ensure only ordered admins in results", () => {
  //assuming we've added here two admins
  const allAdmins = getUsers({ adminOnly: true });

  expect(allAdmins)
    .to.include.ordered.members(["admin1", "admin2"])
    .but.not.include.ordered.members(["user1"]);
});

⚪️1.4ブラックボックステストに固執する：パブリックメソッドのみをテストする

✅ 実施：内部をテストすると、ほとんど何もせずに大きなオーバーヘッドが発生します。コード/APIが正しい結果を提供する場合、内部でどのように機能するかをテストするために次の3時間を本当に投資してから、これらの脆弱なテストを維持する必要がありますか？パブリック動作がチェックされるときはいつでも、プライベート実装も暗黙的にテストされ、特定の問題（たとえば、間違った出力）がある場合にのみテストが失敗します。このアプローチは、とも呼ばれ

behavioral testing

❌ それ以外の場合：テストは、オオカミを泣いた少年のように動作します：偽陽性の叫びを叫びます（たとえば、プライベート変数名が変更されたため、テストは失敗します）。当然のことながら、人々はすぐにCI通知を無視し始め、いつの日か、本当のバグが無視されるようになります…

class ProductService {
  //this method is only used internally
  //Change this name will make the tests fail
  calculateVATAdd(priceWithoutVAT) {
    return { finalPrice: priceWithoutVAT * 1.2 };
    //Change the result format or key name above will make the tests fail
  }
  //public method
  getPrice(productId) {
    const desiredProduct = DB.getProduct(productId);
    finalPrice = this.calculateVATAdd(desiredProduct.price).finalPrice;
    return finalPrice;
  }
}

it("White-box test: When the internal methods get 0 vat, it return 0 response", async () => {
  //There's no requirement to allow users to calculate the VAT, only show the final price. Nevertheless we falsely insist here to test the class internals
  expect(new ProductService().calculateVATAdd(0).finalPrice).to.equal(0);
});

⚪️️1.5適切なテストダブルを選択してください：スタブとスパイを支持してモックを避けてください

✅ 実施：テストダブルはアプリケーションの内部に結合されているため、必要な悪ですが、いくつかは計り知れない価値を提供します（テストダブルについてのリマインダーをここで読んでください：モックvsスタブvsスパイ）。

テストダブルを使用する前に、非常に簡単な質問をしてください。要件ドキュメントに表示される、または表示される可能性のある機能をテストするために使用しますか？いいえの場合、それはホワイトボックステストの匂いです。

たとえば、支払いサービスがダウンしているときにアプリが適切に動作することをテストする場合は、支払いサービスをスタブし、「応答なし」の戻りをトリガーして、テスト対象のユニットが正しい値を返すことを確認します。これにより、特定のシナリオでのアプリケーションの動作/応答/結果がチェックされます。スパイを使用して、そのサービスがダウンしたときに電子メールが送信されたことを表明することもできます。これも、要件ドキュメントに表示される可能性のある動作チェックです（「支払いを保存できなかった場合は電子メールを送信してください」）。反対に、Paymentサービスをモックして、適切なJavaScriptタイプで呼び出されたことを確認すると、テストは、アプリケーションの機能とは関係がなく、頻繁に変更される可能性のある内部的なものに焦点が当てられます。

❌ それ以外の場合：コードのリファクタリングでは、コード内のすべてのモックを検索し、それに応じて更新する必要があります。テストは親切な友達ではなく負担になります

it("When a valid product is about to be deleted, ensure data access DAL was called once, with the right product and right config", async () => {
  //Assume we already added a product
  const dataAccessMock = sinon.mock(DAL);
  //hmmm BAD: testing the internals is actually our main goal here, not just a side-effect
  dataAccessMock
    .expects("deleteProduct")
    .once()
    .withArgs(DBConfig, theProductWeJustAdded, true, false);
  new ProductService().deletePrice(theProductWeJustAdded);
  dataAccessMock.verify();
});

it("When a valid product is about to be deleted, ensure an email is sent", async () => {
  //Assume we already added here a product
  const spy = sinon.spy(Emailer.prototype, "sendEmail");
  new ProductService().deletePrice(theProductWeJustAdded);
  //hmmm OK: we deal with internals? Yes, but as a side effect of testing the requirements (sending an email)
  expect(spy.calledOnce).to.be.true;
});

📗ライブビデオでこれらすべてのプラクティスを学びたいですか？

私のオンラインコース「Node.jsとJavaScriptをAからZまでテストする」にアクセスしてください

⚪️1.6「foo」しないで、現実的な入力データを使用してください

✅ 実施：多くの場合、本番環境のバグは、非常に具体的で驚くべき入力の下で明らかになります。テスト入力が現実的であるほど、バグを早期に発見できる可能性が高くなります。ChanceやFakerなどの専用ライブラリを使用して、本番データの多様性と形式に似た疑似実データを生成します。たとえば、このようなライブラリは、現実的な電話番号、ユーザー名、クレジットカード、会社名、さらには「loremipsum」テキストを生成できます。また、偽造者のデータをランダム化してテスト対象のユニットを拡張したり、実稼働環境から実際のデータをインポートしたりするテストを（ユニットテストに加えて、代替としてではなく）作成することもできます。それを次のレベルに引き上げたいですか？次の箇条書き（プロパティベースのテスト）を参照してください。

❌ それ以外の場合：「Foo」などの合成入力を使用すると、すべての開発テストで誤って緑色が表示されますが、ハッカーが「@ 3e2ddsf」などの厄介な文字列を渡すと、本番環境が赤色に変わる可能性があります。##'1fdsfds。fds432AAAA」

const addProduct = (name, price) => {
  const productNameRegexNoSpace = /^\S*$/; //no white-space allowed

  if (!productNameRegexNoSpace.test(name)) return false; //this path never reached due to dull input

  //some logic here
  return true;
};

test("Wrong: When adding new product with valid properties, get successful confirmation", async () => {
  //The string "Foo" which is used in all tests never triggers a false result
  const addProductResult = addProduct("Foo", 5);
  expect(addProductResult).toBe(true);
  //Positive-false: the operation succeeded because we never tried with long
  //product name including spaces
});

it("Better: When adding new valid product, get successful confirmation", async () => {
  const addProductResult = addProduct(faker.commerce.productName(), faker.random.number());
  //Generated random input: {'Sleek Cotton Computer',  85481}
  expect(addProductResult).to.be.true;
  //Test failed, the random input triggered some path we never planned for.
  //We discovered a bug early!
});

⚪️1.7プロパティベースのテストを使用して多くの入力の組み合わせをテストします

✅ 実施：通常、テストごとにいくつかの入力サンプルを選択します。入力形式が実際のデータに似ている場合でも（箇条書き'Do n't foo'を参照）、いくつかの入力の組み合わせ（method（''、true、1）、method（ "string"、false、0））のみを取り上げます。 、ただし、本番環境では、5つのパラメーターで呼び出されるAPIを数千の異なる順列で呼び出すことができ、そのうちの1つでプロセスがダウンする可能性があります（ファズテストを参照）。）。さまざまな入力の1000の順列を自動的に送信し、コードが正しい応答を返さない入力をキャッチする単一のテストを作成できるとしたらどうでしょうか。プロパティベースのテストは、まさにそれを行う手法です。可能なすべての入力の組み合わせをテスト対象のユニットに送信することで、バグを見つける可能性が高まります。たとえば、メソッド（addNewProduct（id、name、isDiscount））が与えられると、サポートライブラリは、（1、“ iPhone”、false）、（2、“ Galaxy）のような（number、string、boolean）の多くの組み合わせでこのメソッドを呼び出します。 "、 真実）。js-verifyやtestcheck（はるかに優れたドキュメント）などのライブラリを使用して、お気に入りのテストランナー（Mocha、Jestなど）を使用してプロパティベースのテストを実行できます。更新：Nicolas Dubienは、以下のコメントで次のように提案しています。いくつかの追加機能を提供し、積極的に維持されているように見える チェックアウトファストチェック

❌ それ以外の場合：無意識のうちに、適切に機能するコードパスのみをカバーするテスト入力を選択します。残念ながら、これはバグを明らかにするための手段としてのテストの効率を低下させます

import fc from "fast-check";

describe("Product service", () => {
  describe("Adding new", () => {
    //this will run 100 times with different random properties
    it("Add new product with random yet valid properties, always successful", () =>
      fc.assert(
        fc.property(fc.integer(), fc.string(), (id, name) => {
          expect(addNewProduct(id, name).status).toEqual("approved");
        })
      ));
  });
});

⚪️1.8必要に応じて、短いインラインスナップショットのみを使用してください

✅ 実施：スナップショットテストが必要な場合は、テスト（インラインスナップショット）の一部として含まれ、外部ファイルには含まれない、短く焦点を絞ったスナップショット（つまり、3〜7行）のみを使用します。このガイドラインを守ることで、テストが自明で脆弱性が少なくなることが保証されます。

一方、「クラシックスナップショット」のチュートリアルとツールでは、大きなファイル（コンポーネントレンダリングマークアップ、API JSON結果など）を外部メディアに保存し、テストを実行するたびに、受信した結果と保存したバージョンを比較することをお勧めします。これは、たとえば、テストライターが読み取ったり推論したりしたことのない3000のデータ値を持つ1000行にテストを暗黙的に結合する可能性があります。なぜこれが間違っているのですか？そうすることで、テストが失敗する理由は1000あります。スナップショットが無効になるには、1行を変更するだけで十分であり、これは頻繁に発生する可能性があります。どのくらいの頻度で？すべてのスペース、コメント、またはCSS/HTMLのマイナーな変更。これだけでなく、テスト名は1000行が変更されていないことを確認するだけなので、失敗についての手がかりを与えません。また、テストライターは、検査および検証できなかった長いドキュメントを目的の真として受け入れることをお勧めします。これらはすべて、焦点が絞られておらず、達成しすぎることを目的とした、あいまいで熱心なテストの症状です。

データではなくスキーマでアサートする場合（値を抽出してフィールドに焦点を合わせる場合）、または受信したドキュメントがめったに変更されない場合など、長い外部スナップショットが受け入れられるケースはほとんどないことに注意してください。

❌ それ以外の場合： UIテストは失敗します。コードは正しいようです、画面は完璧なピクセルをレンダリングします、何が起こったのですか？スナップショットテストで、元のドキュメントと現在受信しているドキュメントとの違いが見つかりました-マークダウンに単一のスペース文字が追加されました...

it("TestJavaScript.com is renderd correctly", () => {
  //Arrange

  //Act
  const receivedPage = renderer
    .create(<DisplayPage page="http://www.testjavascript.com"> Test JavaScript </DisplayPage>)
    .toJSON();

  //Assert
  expect(receivedPage).toMatchSnapshot();
  //We now implicitly maintain a 2000 lines long document
  //every additional line break or comment - will break this test
});

it("When visiting TestJavaScript.com home page, a menu is displayed", () => {
  //Arrange

  //Act
  const receivedPage = renderer
    .create(<DisplayPage page="http://www.testjavascript.com"> Test JavaScript </DisplayPage>)
    .toJSON();

  //Assert

  const menu = receivedPage.content.menu;
  expect(menu).toMatchInlineSnapshot(`
<ul>
<li>Home</li>
<li> About </li>
<li> Contact </li>
</ul>
`);
});

⚪️コードをコピーしますが、必要なものだけです

✅ 行う：テスト結果に影響を与える必要な詳細をすべて含めますが、それ以上は含めません。例として、100行の入力JSONを因数分解する必要があるテストを考えてみましょう-これをすべてのテストに貼り付けるのは面倒です。それを外部でtransferFactory.getJSON（）に抽出すると、テストがあいまいになります-データがないと、テスト結果を原因と関連付けるのは困難です（「なぜ400ステータスを返すことになっているのですか？」）。このパターンを「ミステリーゲスト」と名付けた古典的な本のxユニットパターン-目に見えない何かがテスト結果に影響を与えました。正確には何がわかりません。繰り返し可能な長い部分を外側に抽出し、どの特定の詳細がテストに重要であるかを明示的に言及することで、より良い結果を得ることができます。上記の例を使用すると、テストは重要なものを強調するパラメーターを渡すことができます：transferFactory.getJSON（{sender：undefined}）。この例では、

❌ それ以外の場合： 500のJSON行をコピーすると、テストが保守できなくなり、読み取り不能になります。すべてを外に移動すると、理解しにくい漠然としたテストで終わります

test("When no credit, then the transfer is declined", async() => {
      // Arrange
      const transferRequest = testHelpers.factorMoneyTransfer() //get back 200 lines of JSON;
      const transferServiceUnderTest = new TransferService();

      // Act
      const transferResponse = await transferServiceUnderTest.transfer(transferRequest);

      // Assert
      expect(transferResponse.status).toBe(409);// But why do we expect failure: All seems perfectly valid in the test 🤔
    });

test("When no credit, then the transfer is declined ", async() => {
      // Arrange
      const transferRequest = testHelpers.factorMoneyTransfer({userCredit:100, transferAmount:200}) //obviously there is lack of credit
      const transferServiceUnderTest = new TransferService({disallowOvercharge:true});

      // Act
      const transferResponse = await transferServiceUnderTest.transfer(transferRequest);

      // Assert
      expect(transferResponse.status).toBe(409); // Obviously if the user has no credit it should fail
    });

⚪️1.10エラーをキャッチしないでください、それらを期待してください

✅ 実施：一部の入力がエラーをトリガーすることを表明しようとすると、try-catch-finallyを使用するのが正しいように見え、catch句が入力されたことを表明します。結果は、単純なテストの意図と結果の期待を隠す厄介で冗長なテストケース（以下の例）です。

より洗練された代替手段は、1行の専用Chaiアサーションを使用することです：expect（method）.to.throw（またはJestではexpect（method）.toThrow（））。例外にエラータイプを示すプロパティが含まれていることも確認する必要があります。そうしないと、一般的なエラーが発生した場合、アプリケーションはユーザーに期待外れのメッセージを表示するのではなく、多くのことを実行できなくなります。

❌ それ以外の場合：テストレポート（CIレポートなど）から何が悪かったのかを推測するのは困難です

it("When no product name, it throws error 400", async () => {
  let errorWeExceptFor = null;
  try {
    const result = await addNewProduct({});
  } catch (error) {
    expect(error.code).to.equal("InvalidInput");
    errorWeExceptFor = error;
  }
  expect(errorWeExceptFor).not.to.be.null;
  //if this assertion fails, the tests results/reports will only show
  //that some value is null, there won't be a word about a missing Exception
});

it("When no product name, it throws error 400", async () => {
  await expect(addNewProduct({}))
    .to.eventually.throw(AppError)
    .with.property("code", "InvalidInput");
});

⚪️1.11テストにタグを付ける

✅ 実施：さまざまなシナリオでさまざまなテストを実行する必要があります。クイックスモーク、IOレス、開発者がファイルを保存またはコミットするときにテストを実行する必要があります。通常、新しいプルリクエストが送信されると、完全なエンドツーエンドのテストが実行されます。 #cold #api #sanityなどのキーワードでテストにタグを付けることで実現できるため、テストハーネスを使用してgrepを実行し、目的のサブセットを呼び出すことができます。たとえば、これは、Mochaを使用して健全性テストグループのみを呼び出す方法です。mocha— grep'sanity'

❌ それ以外の場合：数十のDBクエリを実行するテストを含むすべてのテストの実行は、開発者が小さな変更を加えるたびに非常に遅くなり、開発者がテストを実行できないようにします。

//this test is fast (no DB) and we're tagging it correspondigly
//now the user/CI can run it frequently
describe("Order service", function() {
  describe("Add new order #cold-test #sanity", function() {
    test("Scenario - no currency was supplied. Expectation - Use the default currency #sanity", function() {
      //code logic here
    });
  });
});

⚪️1.12少なくとも2つのレベルでテストを分類する

✅ 実施：テストスイートに構造を適用して、不定期の訪問者が要件（テストが最適なドキュメント）とテストされているさまざまなシナリオを簡単に理解できるようにします。これの一般的な方法は、テストの上に少なくとも2つの「describe」ブロックを配置することです。1つ目はテスト対象のユニットの名前用で、2つ目はシナリオやカスタムカテゴリなどの追加レベルの分類用です（コード例と印刷を参照）下の画面）。そうすることで、テストレポートも大幅に改善されます。読者は、テストカテゴリを簡単に推測し、目的のセクションを掘り下げて、失敗したテストを相互に関連付けることができます。さらに、開発者が多くのテストを含むスイートのコードをナビゲートするのがはるかに簡単になります。テストスイートには、次のように考えることができる複数の代替構造があります。与えられたときとRITE

❌ それ以外の場合：テストのフラットで長いリストを含むレポートを見る場合、読者は長いテキストをざっと読んで主要なシナリオを結論付け、失敗するテストの共通性を関連付ける必要があります。次の場合を考えてみましょう。7/100テストが失敗した場合、フラットリストを見るには、失敗したテストのテキストを読んで、それらが互いにどのように関連しているかを確認する必要があります。ただし、階層レポートでは、それらすべてが同じフローまたはカテゴリに属している可能性があり、読者は根本的な障害の原因が何であるか、少なくともどこにあるかをすばやく推測します。

// Unit under test
describe("Transfer service", () => {
  //Scenario
  describe("When no credit", () => {
    //Expectation
    test("Then the response status should decline", () => {});

    //Expectation
    test("Then it should send email to admin", () => {});
  });
});

test("Then the response status should decline", () => {});

test("Then it should send email", () => {});

test("Then there should not be a new transfer record", () => {});

⚪️1.13その他の一般的な良好な試験衛生

✅ 実施：この投稿は、ノードJSに関連する、または少なくともノードJSで例示できるテストアドバイスに焦点を当てています。ただし、この箇条書きでは、よく知られているノードに関連しないヒントをいくつかグループ化しています。

TDDの原則を学び、実践します。TDDの原則 は多くの人にとって非常に価値がありますが、自分のスタイルに合わなくても恐れることはありません。あなただけではありません。コードの前に赤緑リファクタースタイルでテストを作成することを検討し、バグを見つけたときに各テストが1つだけチェックすることを確認します。修正する前に、将来このバグを検出するテストを作成し、少なくとも各テストを失敗させます。緑色に変わる前に、テストを満たす迅速で単純なコードを記述してモジュールを開始します。次に、徐々にリファクタリングして製品グレードレベルにし、環境（パス、OSなど）への依存を回避します。

❌ そうでなければ：あなたは何十年もの間集められた知恵の真珠を見逃すでしょう

セクション2️⃣：バックエンドテスト

⚪️2.1テストポートフォリオを充実させる：単体テストとピラミッドを超えて見てください

✅ 実施：テストピラミッドは10年以上前のものですが、3つのテストタイプを提案し、ほとんどの開発者のテスト戦略に影響を与える、優れた関連モデルです。同時に、一握り以上の光沢のある新しいテスト手法が出現し、テストピラミッドの陰に隠れています。最近10年間に見られたすべての劇的な変化（マイクロサービス、クラウド、サーバーレス）を考えると、1つの非常に古いモデルがすべてのタイプのアプリケーションに適合する可能性さえありますか？テストの世界では、新しいテスト手法を歓迎することを検討すべきではありませんか？

誤解しないでください。2019年のテストピラミッド、TDD、および単体テストは依然として強力な手法であり、おそらく多くのアプリケーションに最適です。他のモデルと同じように、その有用性にもかかわらず、それは時々間違っているに違いありません。たとえば、Kafka / RabbitMQのようなメッセージバスに多くのイベントを取り込み、データウェアハウスに流れ込み、最終的に分析UIによってクエリされるIoTアプリケーションについて考えてみます。統合中心でロジックがほとんどないアプリケーションの単体テストの作成に、テスト予算の50％を実際に費やす必要がありますか？アプリケーションタイプ（ボット、暗号、Alexaスキル）の多様性が増すにつれて、テストピラミッドが最適ではないシナリオを見つける可能性が高くなります。

テストポートフォリオを充実させ、より多くのテストタイプ（次の箇条書きはいくつかのアイデアを提案します）、テストピラミッドのようなマインドモデルに精通するときですが、テストタイプを直面している実際の問題に一致させます（「ねえ、私たちのAPI壊れている場合は、消費者主導の契約テストを作成しましょう！'）、リスク分析に基づいてポートフォリオを構築する投資家のようにテストを多様化します—問題が発生する可能性のある場所を評価し、それらの潜在的なリスクを軽減するためのいくつかの予防策と一致させます

注意の言葉：ソフトウェアの世界でのTDDの議論は、典型的な誤った二分法の顔を取り、どこでもそれを使用するように説教する人もいれば、それが悪魔だと考える人もいます。絶対的に話す人は誰でも間違っています：]

❌ それ以外の場合：ファズ、リント、ミューテーションなど、驚くべきROIを備えたツールを見逃してしまいます。10分で価値が得られます。

⚪️2.2コンポーネントテストはあなたの最善の問題かもしれません

✅ 実施：各単体テストはアプリケーションのごく一部をカバーし、全体をカバーするのに費用がかかりますが、エンドツーエンドのテストは簡単に多くの領域をカバーしますが、不安定で時間がかかります。バランスの取れたアプローチを適用して、単体テストよりも大きいが、エンドツーエンドのテストよりも小さい？コンポーネントテストは、テストの世界で歌われていない歌です。これらは、妥当なパフォーマンスとTDDパターンを適用する可能性+現実的で優れたカバレッジという、両方の世界から最高のものを提供します。

コンポーネントテストはマイクロサービスの「ユニット」に焦点を当て、APIに対して機能し、マイクロサービス自体に属するもの（たとえば、実際のDB、または少なくともそのDBのメモリ内バージョン）をモックしませんが、外部のものをスタブします他のマイクロサービスへの呼び出しのように。そうすることで、デプロイする内容をテストし、アプリに外側から内側にアプローチし、妥当な時間内に大きな自信を得ることができます。

コンポーネントテストを正しい方法で書くことに専念する完全なガイドがあります

❌ それ以外の場合：システムカバレッジが20％しかないことを確認するために、単体テストの作成に長い日数を費やす可能性があります

⚪️2.3コントラクトテストを使用して、新しいリリースがAPIを壊さないことを確認します

✅ 行う：したがって、マイクロサービスには複数のクライアントがあり、互換性の理由からサービスの複数のバージョンを実行します（全員を満足させます）。次に、いくつかのフィールドを変更して「ブーム！」とすると、このフィールドに依存している重要なクライアントが怒っています。これは統合の世界のキャッチ22です。サーバー側が複数のクライアントの期待をすべて考慮することは非常に困難です—一方、サーバーがリリース日を制御するため、クライアントはテストを実行できません。契約の問題を軽減できるさまざまな手法があります。単純なものもあれば、機能が豊富で、より急な学習曲線が必要なものもあります。シンプルで推奨されるアプローチでは、APIプロバイダーはAPIタイピング（JSDoc、TypeScriptなど）を使用してnpmパッケージを公開します。次に、消費者はこのライブラリをフェッチして、コードインタイムインテリセンスと検証の恩恵を受けることができます。使用するためのより手の込んだアプローチ非常に破壊的なアプローチでこのプロセスを形式化するために生まれたPACT—サーバーがそれ自体のテスト計画を定義するのではなく、クライアントが…サーバーのテストを定義します！PACTはクライアントの期待を記録し、共有の場所「ブローカー」に配置できるため、サーバーは期待を引き出し、PACTライブラリを使用してすべてのビルドで実行し、壊れた契約（クライアントの期待が満たされていない）を検出できます。そうすることで、サーバーとクライアントのAPIの不一致はすべて、ビルド/ CIの早い段階で検出され、フラストレーションを大幅に軽減できる可能性があります。

❌ それ以外の場合：代替案は、手動テストまたは展開の恐れを使い果たしています

⚪️2.4ミドルウェアを分離してテストする

✅ 実施：ミドルウェアテストはシステムのごく一部を表し、ライブExpressサーバーを必要とするため、多くの場合ミドルウェアテストを回避します。両方の理由が間違っています—ミドルウェアは小さいですが、すべてまたはほとんどのリクエストに影響を与え、{req、res}JSオブジェクトを取得する純粋関数として簡単にテストできます。ミドルウェア関数をテストするには、ミドルウェア関数を呼び出して、{req、res}オブジェクトとの相互作用をスパイし（たとえばSinonを使用）、関数が正しいアクションを実行したことを確認する必要があります。ライブラリnode-mock-httpはそれをさらに進め、{req、res}オブジェクトをそれらの動作をスパイするとともに因数分解します。たとえば、resオブジェクトに設定されたhttpステータスが期待値と一致するかどうかをアサートできます（以下の例を参照）

❌ それ以外の場合： Expressミドルウェアのバグ===すべてまたはほとんどのリクエストのバグ

//the middleware we want to test
const unitUnderTest = require("./middleware");
const httpMocks = require("node-mocks-http");
//Jest syntax, equivelant to describe() & it() in Mocha
test("A request without authentication header, should return http status 403", () => {
  const request = httpMocks.createRequest({
    method: "GET",
    url: "/user/42",
    headers: {
      authentication: ""
    }
  });
  const response = httpMocks.createResponse();
  unitUnderTest(request, response);
  expect(response.statusCode).toBe(403);
});

⚪️2.5静的分析ツールを使用した測定とリファクタリング

✅ 実施：静的分析ツールを使用すると、コードの品質を向上させ、コードを保守しやすくするための客観的な方法を提供できます。静的分析ツールをCIビルドに追加して、コードの臭いが見つかったときに中止することができます。プレーンリンティングに対する主なセールスポイントは、複数のファイルのコンテキストで品質を検査し（重複の検出など）、高度な分析を実行し（コードの複雑さなど）、コードの問題の履歴と進行状況を追跡できることです。使用できるツールの2つの例は、SonarQube（4,900以上の星）とCode Climate（2,000以上の星）です。

クレジット：キースホリデイ

❌ それ以外の場合：コードの品質が低いと、バグとパフォーマンスが常に問題になり、光沢のある新しいライブラリや最先端の​​機能では修正できません。

⚪️2.6ノード関連の混乱に対する準備を確認します

✅ 実施：奇妙なことに、ほとんどのソフトウェアテストはロジックとデータのみを対象としていますが、発生する（そして軽減するのが非常に難しい）最悪の事態のいくつかはインフラストラクチャの問題です。たとえば、プロセスメモリが過負荷になったとき、サーバー/プロセスが停止したときに何が起こるかをテストしたことがありますか、またはAPIが50％遅くなったときに監視システムが認識しますか？これらのタイプの悪いことをテストして軽減するために— カオスエンジニアリングはNetflixによって生まれました。これは、混沌とした問題に対するアプリの復元力をテストするための認識、フレームワーク、ツールを提供することを目的としています。たとえば、有名なツールの1つであるカオスモンキーは、サーバーをランダムに強制終了して、サービスが単一のサーバーに依存せずにユーザーにサービスを提供できるようにします（Kubernetesバージョンのkube-monkeyもあります）、それはポッドを殺します）。これらのツールはすべてホスティング/プラットフォームレベルで機能しますが、ノードプロセスがキャッチされないエラー、未処理のプロミス拒否、最大許容値1.7GBで過負荷のv8メモリにどのように対処するかを確認するなど、純粋なノードカオスをテストして生成したい場合はどうなりますか？イベントループが頻繁にブロックされても、UXは満足のいくものですか？私が書いたこれに対処するために、ノード関連のあらゆる種類の混沌とし​​た行為を提供する ノードカオス（アルファ）

❌ そうでなければ：ここで逃げることはできません、マーフィーの法則は容赦なくあなたの作品に影響を与えます

⚪️2.7グローバルなテストフィクスチャとシードを避け、テストごとにデータを追加します

✅ 実施：黄金律（箇条書き0）に従って、各テストは、結合を防ぎ、テストフローについて簡単に推論できるように、独自のDB行のセットを追加して処理する必要があります。実際には、パフォーマンスを向上させるために、テストを実行する前にDBにデータをシードするテスター（「テストフィクスチャ」とも呼ばれます）は、これに違反することがよくあります。パフォーマンスは確かに有効な懸念事項ですが、軽減することはできますが（「コンポーネントのテスト」の箇条書きを参照）、テストの複雑さは非常に苦痛な悲しみであり、ほとんどの場合、他の考慮事項を左右するはずです。実際には、各テストケースに必要なDBレコードを明示的に追加し、それらのレコードのみに作用するようにします。パフォーマンスが重大な懸念事項になる場合—バランスの取れた妥協は、データを変更しない唯一のテストスイート（クエリなど）をシードするという形で発生する可能性があります。

❌ それ以外の場合：失敗するテストはほとんどなく、展開は中止されます。チームは貴重な時間を費やす予定です。バグはありますか？調べてみましょう、いや、2つのテストが同じシードデータを変異させていたようです

before(async () => {
  //adding sites and admins data to our DB. Where is the data? outside. At some external json or migration framework
  await DB.AddSeedDataFromJson('seed.json');
});
it("When updating site name, get successful confirmation", async () => {
  //I know that site name "portal" exists - I saw it in the seed files
  const siteToUpdate = await SiteService.getSiteByName("Portal");
  const updateNameResult = await SiteService.changeName(siteToUpdate, "newName");
  expect(updateNameResult).to.be(true);
});
it("When querying by site name, get the right site", async () => {
  //I know that site name "portal" exists - I saw it in the seed files
  const siteToCheck = await SiteService.getSiteByName("Portal");
  expect(siteToCheck.name).to.be.equal("Portal"); //Failure! The previous test change the name :[
});

it("When updating site name, get successful confirmation", async () => {
  //test is adding a fresh new records and acting on the records only
  const siteUnderTest = await SiteService.addSite({
    name: "siteForUpdateTest"
  });
  const updateNameResult = await SiteService.changeName(siteUnderTest, "newName");
  expect(updateNameResult).to.be(true);
});

⚪️2.8明確なデータクリーンアップ戦略を選択します：結局のところ（推奨）またはそれぞれの後

✅ 行う：テストがデータベースをクリーンアップするタイミングによって、テストの記述方法が決まります。最も実行可能な2つのオプションは、すべてのテスト後のクリーニングと、すべてのテスト後のクリーニングです。後者のオプションを選択すると、すべてのテストの後にクリーニングすることで、テーブルがクリーンになり、開発者にとって便利なテスト特典が構築されます。テストの開始時に他のレコードは存在しません。どのデータがクエリされているかを確認でき、アサーション中に行をカウントしたくなる場合もあります。これには重大な欠点があります。マルチプロセスモードで実行すると、テストが相互に干渉する可能性があります。process-1はテーブルをパージしますが、その瞬間、process-2はデータを照会して失敗します（DBがprocess-1によって突然削除されたため）。さらに、失敗したテストのトラブルシューティングは困難です。DBにアクセスしても、レコードは表示されません。

2番目のオプションは、すべてのテストファイルが終了した後（または毎日！）にクリーンアップすることです。このアプローチは、既存のレコードを持つ同じDBがすべてのテストとプロセスに対応することを意味します。お互いのつま先を踏まないようにするには、テストは追加した特定のレコードを追加して処理する必要があります。いくつかのレコードが追加されたことを確認する必要がありますか？他にも数千のレコードがあり、明示的に追加されたレコードを照会するとします。レコードが削除されたことを確認する必要がありますか？空のテーブルを想定することはできません。この特定のレコードが存在しないことを確認してください。この手法は、いくつかの強力な利点をもたらします。開発者が何が起こったのかを理解したい場合、マルチプロセスモードでネイティブに機能します。データはそこにあり、削除されません。また、DBはレコードでいっぱいであり、人為的に空ではないため、バグを見つける可能性が高くなります。ここで完全な比較表を参照してください。

❌ それ以外の場合：レコードを分離したりクリーンアップしたりする戦略がない場合-テストは互いに足を踏み入れます。トランザクションの使用はリレーショナルDBでのみ機能し、内部トランザクションがあると複雑になる可能性があります

  // After-all clean up (recommended)
// global-teardown.js
module.exports = async () => {
  // ...
  if (Math.ceil(Math.random() * 10) === 10) {
    await new OrderRepository().cleanup();
  }
};

⚪️2.9HTTPインターセプターを使用してコンポーネントをワールドから分離する

✅ 行う：発信HTTPリクエストをインターセプトし、必要な応答を提供して、コラボレーターのHTTP APIがヒットしないようにすることで、テスト対象のコンポーネントを分離します。Nockは、外部サービスの動作を定義するための便利な構文を提供するため、このミッションに最適なツールです。分離は、ノイズやパフォーマンスの低下を防ぐために必須ですが、主にさまざまなシナリオや応答をシミュレートするために必要です-優れたフライトシミュレーターは、澄んだ青い空を描くことではなく、安全な嵐や混乱をもたらすことです。これは、他の世界を巻き込むことなく、常に単一のコンポーネントに焦点を当てる必要があるマイクロサービスアーキテクチャで強化されています。テストダブル（モッキング）を使用して外部サービスの動作をシミュレートすることは可能ですが、展開されたコードに触れずにネットワークレベルで動作して、テストを純粋なブラックボックスに保つことが望ましいです。

❌ それ以外の場合：一部のサービスは、通常はDockerを使用して、呼び出し元がローカルにデプロイできる偽のバージョンを提供します。これにより、セットアップが簡単になり、パフォーマンスが向上しますが、さまざまな応答のシミュレーションには役立ちません。一部のサービスは「サンドボックス」環境を提供するため、実際のサービスはヒットしますが、コストや副作用は発生しません-これにより、サードパーティサービスのセットアップのノイズが削減されますが、シナリオのシミュレーションもできなくなります

// Intercept requests for 3rd party APIs and return a predefined response 
beforeEach(() => {
  nock('http://localhost/user/').get(`/1`).reply(200, {
    id: 1,
    name: 'John',
  });
});```

</details>

## ⚪ ️2.10 Test the response schema, mostly when there are auto-generated fields

:white_check_mark: **Do:** When it is impossible to assert for specific data, check for mandatory field existence and types. Sometimes, the response contains important fields with dynamic data that can't be predicted when writing the test, like dates and incrementing numbers. If the API contract promises that these fields won't be null and hold the right types, it's imperative to test it. Most assertion libraries support checking types. If the response is small, check the return data and type together within the same assertion (see code example). One more option is to verify the entire response against an OpenAPI doc (Swagger). Most test runners have community extensions that validate API responses against their documentation.


<br/>

❌ **Otherwise:** Although the code/API caller relies on some field with dynamic data (e.g., ID, date), it will not come in return and break the contract

<br/>

<details><summary>✏ <b>Code Examples</b></summary>

<br/>

### :clap: Asserting that fields with dynamic value exist and have the right type

```javascript
  test('When adding a new valid order, Then should get back approval with 200 response', async () => {
  // ...
  //Assert
  expect(receivedAPIResponse).toMatchObject({
    status: 200,
    data: {
      id: expect.any(Number), // Any number satisfies this test
      mode: 'approved',
    },
  });
});

⚪️2.12統合のコーナーケースとカオスを確認する

✅ 実施：統合を確認するときは、幸せな道と悲しい道を超えてください。エラー応答（HTTP 500エラーなど）だけでなく、応答が遅くタイムアウトしたなどのネットワークレベルの異常も確認してください。これは、コードが回復力があり、タイムアウト後に正しいパスをとるなどのさまざまなネットワークシナリオを処理でき、脆弱な競合状態がなく、再試行用の回路ブレーカーが含まれていることを証明します。評判の良いインターセプターツールは、ときどき失敗する多忙なサービスのようなさまざまなネットワーク動作を簡単にシミュレートできます。デフォルトのHTTPクライアントタイムアウト値がシミュレートされた応答時間よりも長い場合でも認識でき、待機せずにすぐにタイムアウト例外をスローします

❌ それ以外の場合：すべてのテストに合格します。サードパーティが例外的な応答を送信したときにクラッシュするか、エラーを正しく報告しないのは本番環境のみです。

  test('When users service replies with 503 once and retry mechanism is applied, then an order is added successfully', async () => {
  //Arrange
  nock.removeInterceptor(userServiceNock.interceptors[0])
  nock('http://localhost/user/')
    .get('/1')
    .reply(503, undefined, { 'Retry-After': 100 });
  nock('http://localhost/user/')
    .get('/1')
    .reply(200);
  const orderToAdd = {
    userId: 1,
    productId: 2,
    mode: 'approved',
  };

  //Act
  const response = await axiosAPIClient.post('/order', orderToAdd);

  //Assert
  expect(response.status).toBe(200);
});

⚪️2.135つの潜在的な結果をテストします

✅ 実施：テストを計画するときは、5つの典型的なフローの出力をカバーすることを検討してください。テストが何らかのアクション（API呼び出しなど）をトリガーしているとき、反応が発生し、何か意味のあることが発生し、テストが必要になります。私たちは物事がどのように機能するかを気にしないことに注意してください。私たちの焦点は、結果、つまり外部から目立ち、ユーザーに影響を与える可能性のあるものにあります。これらの結果/反応は、5つのカテゴリに分類できます。

•応答–テストは（APIなどを介して）アクションを呼び出し、応答を取得します。応答データの正確性、スキーマ、およびHTTPステータスのチェックに関係するようになりました

•新しい状態-アクションを呼び出した後、公的にアクセス可能なデータの一部が変更されている可能性があります

•外部呼び出し-アクションを呼び出した後、アプリはHTTPまたはその他のトランスポートを介して外部コンポーネントを呼び出す場合があります。たとえば、SMSを送信したり、電子メールを送信したり、クレジットカードに請求したりするための電話

•メッセージキュー-フローの結果は、キュー内のメッセージになる可能性があります

•可観測性–エラーや顕著なビジネスイベントなど、監視する必要のあるものがいくつかあります。トランザクションが失敗した場合、正しい応答だけでなく、正しいエラー処理と適切なロギング/メトリックも期待されます。この情報は、非常に重要なユーザー（つまり、本番SRE /管理者）に直接送信されます。

Section 3️⃣: Frontend Testing

⚪ ️ 3.1 Separate UI from functionality

✅ Do: When focusing on testing component logic, UI details become a noise that should be extracted, so your tests can focus on pure data. Practically, extract the desired data from the markup in an abstract way that is not too coupled to the graphic implementation, assert only on pure data (vs HTML/CSS graphic details) and disable animations that slow down. You might get tempted to avoid rendering and test only the back part of the UI (e.g. services, actions, store) but this will result in fictional tests that don't resemble the reality and won't reveal cases where the right data doesn't even arrive in the UI

❌ Otherwise: The pure calculated data of your test might be ready in 10ms, but then the whole test will last 500ms (100 tests = 1 min) due to some fancy and irrelevant animation

test("When users-list is flagged to show only VIP, should display only VIP members", () => {
  // Arrange
  const allUsers = [{ id: 1, name: "Yoni Goldberg", vip: false }, { id: 2, name: "John Doe", vip: true }];

  // Act
  const { getAllByTestId } = render(<UsersList users={allUsers} showOnlyVIP={true} />);

  // Assert - Extract the data from the UI first
  const allRenderedUsers = getAllByTestId("user").map(uiElement => uiElement.textContent);
  const allRealVIPUsers = allUsers.filter(user => user.vip).map(user => user.name);
  expect(allRenderedUsers).toEqual(allRealVIPUsers); //compare data with data, no UI here
});

test("When flagging to show only VIP, should display only VIP members", () => {
  // Arrange
  const allUsers = [{ id: 1, name: "Yoni Goldberg", vip: false }, { id: 2, name: "John Doe", vip: true }];

  // Act
  const { getAllByTestId } = render(<UsersList users={allUsers} showOnlyVIP={true} />);

  // Assert - Mix UI & data in assertion
  expect(getAllByTestId("user")).toEqual('[<li data-test-id="user">John Doe</li>]');
});

⚪ ️ 3.2 Query HTML elements based on attributes that are unlikely to change

✅ Do: Query HTML elements based on attributes that are likely to survive graphic changes unlike CSS selectors and like form labels. If the designated element doesn't have such attributes, create a dedicated test attribute like 'test-id-submit-button'. Going this route not only ensures that your functional/logic tests never break because of look & feel changes but also it becomes clear to the entire team that this element and attribute are utilized by tests and shouldn't get removed

❌ Otherwise: You want to test the login functionality that spans many components, logic and services, everything is set up perfectly - stubs, spies, Ajax calls are isolated. All seems perfect. Then the test fails because the designer changed the div CSS class from 'thick-border' to 'thin-border'

// the markup code (part of React component)
<h3>
  <Badge pill className="fixed_badge" variant="dark">
    <span data-test-id="errorsLabel">{value}</span>
    <!-- note the attribute data-test-id -->
  </Badge>
</h3>

// this example is using react-testing-library
test("Whenever no data is passed to metric, show 0 as default", () => {
  // Arrange
  const metricValue = undefined;

  // Act
  const { getByTestId } = render(<dashboardMetric value={undefined} />);

  expect(getByTestId("errorsLabel").text()).toBe("0");
});

<!-- the markup code (part of React component) -->
<span id="metric" className="d-flex-column">{value}</span>
<!-- what if the designer changes the classs? -->

// this exammple is using enzyme
test("Whenever no data is passed, error metric shows zero", () => {
  // ...

  expect(wrapper.find("[className='d-flex-column']").text()).toBe("0");
});

⚪ ️ 3.3 Whenever possible, test with a realistic and fully rendered component

✅ Do: Whenever reasonably sized, test your component from outside like your users do, fully render the UI, act on it and assert that the rendered UI behaves as expected. Avoid all sort of mocking, partial and shallow rendering - this approach might result in untrapped bugs due to lack of details and harden the maintenance as the tests mess with the internals (see bullet 'Favour blackbox testing'). If one of the child components is significantly slowing down (e.g. animation) or complicating the setup - consider explicitly replacing it with a fake

With all that said, a word of caution is in order: this technique works for small/medium components that pack a reasonable size of child components. Fully rendering a component with too many children will make it hard to reason about test failures (root cause analysis) and might get too slow. In such cases, write only a few tests against that fat parent component and more tests against its children

❌ Otherwise: When poking into a component's internal by invoking its private methods, and checking the inner state - you would have to refactor all tests when refactoring the components implementation. Do you really have a capacity for this level of maintenance?

class Calendar extends React.Component {
  static defaultProps = { showFilters: false };

  render() {
    return (
      <div>
        A filters panel with a button to hide/show filters
        <FiltersPanel showFilter={showFilters} title="Choose Filters" />
      </div>
    );
  }
}

//Examples use React & Enzyme
test("Realistic approach: When clicked to show filters, filters are displayed", () => {
  // Arrange
  const wrapper = mount(<Calendar showFilters={false} />);

  // Act
  wrapper.find("button").simulate("click");

  // Assert
  expect(wrapper.text().includes("Choose Filter"));
  // This is how the user will approach this element: by text
});

test("Shallow/mocked approach: When clicked to show filters, filters are displayed", () => {
  // Arrange
  const wrapper = shallow(<Calendar showFilters={false} title="Choose Filter" />);

  // Act
  wrapper
    .find("filtersPanel")
    .instance()
    .showFilters();
  // Tap into the internals, bypass the UI and invoke a method. White-box approach

  // Assert
  expect(wrapper.find("Filter").props()).toEqual({ title: "Choose Filter" });
  // what if we change the prop name or don't pass anything relevant?
});

⚪ ️ 3.4 Don't sleep, use frameworks built-in support for async events. Also try to speed things up

✅ Do: In many cases, the unit under test completion time is just unknown (e.g. animation suspends element appearance) - in that case, avoid sleeping (e.g. setTimeOut) and prefer more deterministic methods that most platforms provide. Some libraries allows awaiting on operations (e.g. Cypress cy.request('url')), other provide API for waiting like @testing-library/dom method wait(expect(element)). Sometimes a more elegant way is to stub the slow resource, like API for example, and then once the response moment becomes deterministic the component can be explicitly re-rendered. When depending upon some external component that sleeps, it might turn useful to hurry-up the clock. Sleeping is a pattern to avoid because it forces your test to be slow or risky (when waiting for a too short period). Whenever sleeping and polling is inevitable and there's no support from the testing framework, some npm libraries like wait-for-expect can help with a semi-deterministic solution

❌ Otherwise: When sleeping for a long time, tests will be an order of magnitude slower. When trying to sleep for small numbers, test will fail when the unit under test didn't respond in a timely fashion. So it boils down to a trade-off between flakiness and bad performance

// using Cypress
cy.get("#show-products").click(); // navigate
cy.wait("@products"); // wait for route to appear
// this line will get executed only when the route is ready

// @testing-library/dom
test("movie title appears", async () => {
  // element is initially not present...

  // wait for appearance
  await wait(() => {
    expect(getByText("the lion king")).toBeInTheDocument();
  });

  // wait for appearance and return the element
  const movie = await waitForElement(() => getByText("the lion king"));
});

test("movie title appears", async () => {
  // element is initially not present...

  // custom wait logic (caution: simplistic, no timeout)
  const interval = setInterval(() => {
    const found = getByText("the lion king");
    if (found) {
      clearInterval(interval);
      expect(getByText("the lion king")).toBeInTheDocument();
    }
  }, 100);

  // wait for appearance and return the element
  const movie = await waitForElement(() => getByText("the lion king"));
});

⚪ ️ 3.5 Watch how the content is served over the network

✅ Do: Apply some active monitor that ensures the page load under real network is optimized - this includes any UX concern like slow page load or un-minified bundle. The inspection tools market is no short: basic tools like pingdom, AWS CloudWatch, gcp StackDriver can be easily configured to watch whether the server is alive and response under a reasonable SLA. This only scratches the surface of what might get wrong, hence it's preferable to opt for tools that specialize in frontend (e.g. lighthouse, pagespeed) and perform richer analysis. The focus should be on symptoms, metrics that directly affect the UX, like page load time, meaningful paint, time until the page gets interactive (TTI). On top of that, one may also watch for technical causes like ensuring the content is compressed, time to the first byte, optimize images, ensuring reasonable DOM size, SSL and many others. It's advisable to have these rich monitors both during development, as part of the CI and most important - 24x7 over the production's servers/CDN

❌ Otherwise: It must be disappointing to realize that after such great care for crafting a UI, 100% functional tests passing and sophisticated bundling - the UX is horrible and slow due to CDN misconfiguration

⚪ ️ 3.6 Stub flaky and slow resources like backend APIs

✅ Do: When coding your mainstream tests (not E2E tests), avoid involving any resource that is beyond your responsibility and control like backend API and use stubs instead (i.e. test double). Practically, instead of real network calls to APIs, use some test double library (like Sinon, Test doubles, etc) for stubbing the API response. The main benefit is preventing flakiness - testing or staging APIs by definition are not highly stable and from time to time will fail your tests although YOUR component behaves just fine (production env was not meant for testing and it usually throttles requests). Doing this will allow simulating various API behavior that should drive your component behavior as when no data was found or the case when API throws an error. Last but not least, network calls will greatly slow down the tests

❌ Otherwise: The average test runs no longer than few ms, a typical API call last 100ms>, this makes each test ~20x slower

// unit under test
export default function ProductsList() {
  const [products, setProducts] = useState(false);

  const fetchProducts = async () => {
    const products = await axios.get("api/products");
    setProducts(products);
  };

  useEffect(() => {
    fetchProducts();
  }, []);

  return products ? <div>{products}</div> : <div data-test-id="no-products-message">No products</div>;
}

// test
test("When no products exist, show the appropriate message", () => {
  // Arrange
  nock("api")
    .get(`/products`)
    .reply(404);

  // Act
  const { getByTestId } = render(<ProductsList />);

  // Assert
  expect(getByTestId("no-products-message")).toBeTruthy();
});

⚪ ️ 3.7 Have very few end-to-end tests that spans the whole system

✅ Do: Although E2E (end-to-end) usually means UI-only testing with a real browser (See bullet 3.6), for other they mean tests that stretch the entire system including the real backend. The latter type of tests is highly valuable as they cover integration bugs between frontend and backend that might happen due to a wrong understanding of the exchange schema. They are also an efficient method to discover backend-to-backend integration issues (e.g. Microservice A sends the wrong message to Microservice B) and even to detect deployment failures - there are no backend frameworks for E2E testing that are as friendly and mature as UI frameworks like Cypress and Puppeteer. The downside of such tests is the high cost of configuring an environment with so many components, and mostly their brittleness - given 50 microservices, even if one fails then the entire E2E just failed. For that reason, we should use this technique sparingly and probably have 1-10 of those and no more. That said, even a small number of E2E tests are likely to catch the type of issues they are targeted for - deployment & integration faults. It's advisable to run those over a production-like staging environment

❌ Otherwise: UI might invest much in testing its functionality only to realizes very late that the backend returned payload (the data schema the UI has to work with) is very different than expected

⚪ ️ 3.8 Speed-up E2E tests by reusing login credentials

✅ Do:実際のバックエンドを含み、API呼び出しに有効なユーザートークンに依存するE2Eテストでは、ユーザーが作成され、すべてのリクエストにログインするレベルにテストを分離することは報われません。代わりに、テストの実行が開始される前に1回だけログインし（つまり、すべてのフックの前に）、トークンをローカルストレージに保存して、リクエスト間で再利用します。これは、コアテストの原則の1つに違反しているようです。つまり、リソースを結合せずにテストを自律的に維持します。これは有効な懸念事項ですが、E2Eテストではパフォーマンスが重要な懸念事項であり、個々のテストを開始する前に1〜3個のAPIリクエストを作成すると、実行時間がひどくなる可能性があります。資格情報を再利用することは、テストが同じユーザーレコードに対して実行する必要があることを意味するわけではありません-ユーザーレコードに依存している場合（例：テストユーザーの支払い履歴）よりも、テストの一部としてこれらのレコードを生成し、他のテストとその存在を共有しないようにしてください。また、バックエンドは偽造される可能性があることにも注意してください。テストがフロントエンドに焦点を合わせている場合は、フロントエンドを分離してバックエンドAPIをスタブ化する方がよい場合があります（を参照）。箇条書き3.6）。

❌ それ以外の場合： 200のテストケースが与えられ、login = 100ms=20秒と仮定して何度もログインする場合のみ

let authenticationToken;

// happens before ALL tests run
before(() => {
  cy.request('POST', 'http://localhost:3000/login', {
    username: Cypress.env('username'),
    password: Cypress.env('password'),
  })
  .its('body')
  .then((responseFromLogin) => {
    authenticationToken = responseFromLogin.token;
  })
})

// happens before EACH test
beforeEach(setUser => () {
  cy.visit('/home', {
    onBeforeLoad (win) {
      win.localStorage.setItem('token', JSON.stringify(authenticationToken))
    },
  })
})

⚪️3.9サイトマップを移動するだけのE2Eスモークテストを1つ行う

✅ 実施：本番監視と開発時の健全性チェックのために、サイトのすべて/ほとんどのページにアクセスし、誰も壊れないことを確認する単一のE2Eテストを実行します。このタイプのテストは、作成と保守が非常に簡単であるため、投資収益率が高くなりますが、機能、ネットワーク、および展開の問題を含むあらゆる種類の障害を検出できます。他のスタイルの煙と健全性チェックは、それほど信頼性が高く、網羅的ではありません。一部の運用チームは、ホームページ（本番環境）にpingを送信するだけであるか、パッケージングやブラウザーの問題を発見しない多くの統合テストを実行する開発者です。言うまでもなく、スモークテストは機能テストに取って代わるものではなく、迅速な煙探知器として機能することを目的としています。

❌ それ以外の場合：すべてが完璧に見える可能性があり、すべてのテストに合格し、本番ヘルスチェックも陽性ですが、Paymentコンポーネントにパッケージングの問題があり、/Paymentルートのみがレンダリングされていません

it("When doing smoke testing over all page, should load them all successfully", () => {
  // exemplified using Cypress but can be implemented easily
  // using any E2E suite
  cy.visit("https://mysite.com/home");
  cy.contains("Home");
  cy.visit("https://mysite.com/Login");
  cy.contains("Login");
  cy.visit("https://mysite.com/About");
  cy.contains("About");
});

⚪️3.10ライブの共同ドキュメントとしてテストを公開します

✅ 実施：アプリの信頼性を高めることに加えて、テストはテーブルに別の魅力的な機会をもたらします-ライブアプリのドキュメントとして機能します。テストは本質的に技術的ではなく製品/UX言語で話すため、適切なツールを使用すると、すべてのピア（開発者とその顧客）を大幅に調整するコミュニケーションアーティファクトとして機能できます。たとえば、一部のフレームワークでは、人間が読める言語を使用してフローと期待（つまり、テスト計画）を表現できるため、製品マネージャーを含むすべての利害関係者が、ライブ要件ドキュメントになったばかりのテストを読み、承認し、共同作業を行うことができます。この手法は、顧客が受け入れ基準を平易な言葉で定義できるため、「受け入れテスト」とも呼ばれます。これはBDD（ビヘイビア駆動テスト）ですその最も純粋な形で。これを可能にする人気のあるフレームワークの1つは、JavaScriptフレーバーを持つCucumberです。以下の例を参照してください。もう1つの類似しているが異なる機会であるStoryBookを使用すると、UIコンポーネントをグラフィックカタログとして公開でき、各コンポーネントのさまざまな状態をウォークスルーできます（たとえば、フィルターなしでグリッドをレンダリングする、複数行でグリッドをレンダリングする、またはなしでグリッドをレンダリングするなど）。それがどのように見えるか、そしてその状態をトリガーする方法を見てください-これは製品の人々にもアピールできますが、ほとんどの場合、それらのコンポーネントを消費する開発者のためのライブドキュメントとして機能します。

❌ それ以外の場合：テストに最高のリソースを投資した後、この投資を活用して大きな価値を獲得しないのは残念です

// this is how one can describe tests using cucumber: plain language that allows anyone to understand and collaborate

Feature: Twitter new tweet

  I want to tweet something in Twitter

  @focus
  Scenario: Tweeting from the home page
    Given I open Twitter home
    Given I click on "New tweet" button
    Given I type "Hello followers!" in the textbox
    Given I click on "Submit" button
    Then I see message "Tweet saved"

⚪️3.11自動ツールで視覚的な問題を検出する

✅ 行う： Setup automated tools to capture UI screenshots when changes are presented and detect visual issues like content overlapping or breaking. This ensures that not only the right data is prepared but also the user can conveniently see it. This technique is not widely adopted, our testing mindset leans toward functional tests but it's the visuals what the user experience and with so many device types it's very easy to overlook some nasty UI bug. Some free tools can provide the basics - generate and save screenshots for the inspection of human eyes. While this approach might be sufficient for small apps, it's flawed as any other manual testing that demands human labor anytime something changes. On the other hand, it's quite challenging to detect UI issues automatically due to the lack of clear definition - this is where the field of 'Visual Regression' chime in and solve this puzzle by comparing old UI with the latest changes and detect differences. Some OSS/free tools can provide some of this functionality (e.g. wraith, PhantomCSS but might charge significant setup time. The commercial line of tools (e.g. Applitools, Percy.io) takes is a step further by smoothing the installation and packing advanced features like management UI, alerting, smart capturing by eliminating 'visual noise' (e.g. ads, animations) and even root cause analysis of the DOM/CSS changes that led to the issue

❌ Otherwise: How good is a content page that display great content (100% tests passed), loads instantly but half of the content area is hidden?

​# Add as many domains as necessary. Key will act as a label​

domains:
  english: "http://www.mysite.com"​

​# Type screen widths below, here are a couple of examples​

screen_widths:

  - 600​
  - 768​
  - 1024​
  - 1280​

​# Type page URL paths below, here are a couple of examples​
paths:
  about:
    path: /about
    selector: '.about'​
  subscribe:
      selector: '.subscribe'​
    path: /subscribe

import * as todoPage from "../page-objects/todo-page";

describe("visual validation", () => {
  before(() => todoPage.navigate());
  beforeEach(() => cy.eyesOpen({ appName: "TAU TodoMVC" }));
  afterEach(() => cy.eyesClose());

  it("should look good", () => {
    cy.eyesCheckWindow("empty todo list");
    todoPage.addTodo("Clean room");
    todoPage.addTodo("Learn javascript");
    cy.eyesCheckWindow("two todos");
    todoPage.toggleTodo(0);
    cy.eyesCheckWindow("mark as completed");
  });
});

Section 4️⃣: Measuring Test Effectiveness

⚪ ️ 4.1 Get enough coverage for being confident, ~80% seems to be the lucky number

✅ Do: The purpose of testing is to get enough confidence for moving fast, obviously the more code is tested the more confident the team can be. Coverage is a measure of how many code lines (and branches, statements, etc) are being reached by the tests. So how much is enough? 10–30% is obviously too low to get any sense about the build correctness, on the other side 100% is very expensive and might shift your focus from the critical paths to the exotic corners of the code. The long answer is that it depends on many factors like the type of application — if you’re building the next generation of Airbus A380 than 100% is a must, for a cartoon pictures website 50% might be too much. Although most of the testing enthusiasts claim that the right coverage threshold is contextual, most of them also mention the number 80% as a thumb of a rule (Fowler: “in the upper 80s or 90s”) that presumably should satisfy most of the applications.

Implementation tips: You may want to configure your continuous integration (CI) to have a coverage threshold (Jest link) and stop a build that doesn’t stand to this standard (it’s also possible to configure threshold per component, see code example below). On top of this, consider detecting build coverage decrease (when a newly committed code has less coverage) — this will push developers raising or at least preserving the amount of tested code. All that said, coverage is only one measure, a quantitative based one, that is not enough to tell the robustness of your testing. And it can also be fooled as illustrated in the next bullets

❌ Otherwise: Confidence and numbers go hand in hand, without really knowing that you tested most of the system — there will also be some fear and fear will slow you down

⚪ ️ 4.2 Inspect coverage reports to detect untested areas and other oddities

✅ Do: Some issues sneak just under the radar and are really hard to find using traditional tools. These are not really bugs but more of surprising application behavior that might have a severe impact. For example, often some code areas are never or rarely being invoked — you thought that the ‘PricingCalculator’ class is always setting the product price but it turns out it is actually never invoked although we have 10000 products in DB and many sales… Code coverage reports help you realize whether the application behaves the way you believe it does. Other than that, it can also highlight which types of code is not tested — being informed that 80% of the code is tested doesn’t tell whether the critical parts are covered. Generating reports is easy — just run your app in production or during testing with coverage tracking and then see colorful reports that highlight how frequent each code area is invoked. If you take your time to glimpse into this data — you might find some gotchas

❌ Otherwise: If you don’t know which parts of your code are left un-tested, you don’t know where the issues might come from

⚪ ️ 4.3 Measure logical coverage using mutation testing

✅ Do: The Traditional Coverage metric often lies: It may show you 100% code coverage, but none of your functions, even not one, return the right response. How come? it simply measures over which lines of code the test visited, but it doesn’t check if the tests actually tested anything — asserted for the right response. Like someone who’s traveling for business and showing his passport stamps — this doesn’t prove any work done, only that he visited few airports and hotels.

Mutation-based testing is here to help by measuring the amount of code that was actually TESTED not just VISITED. Stryker is a JavaScript library for mutation testing and the implementation is really neat:

(1) it intentionally changes the code and “plants bugs”. For example the code newOrder.price===0 becomes newOrder.price!=0. This “bugs” are called mutations

(2) it runs the tests, if all succeed then we have a problem — the tests didn’t serve their purpose of discovering bugs, the mutations are so-called survived. If the tests failed, then great, the mutations were killed.

Knowing that all or most of the mutations were killed gives much higher confidence than traditional coverage and the setup time is similar

❌ Otherwise: You’ll be fooled to believe that 85% coverage means your test will detect bugs in 85% of your code

function addNewOrder(newOrder) {
  logger.log(`Adding new order ${newOrder}`);
  DB.save(newOrder);
  Mailer.sendMail(newOrder.assignee, `A new order was places ${newOrder}`);

  return { approved: true };
}

it("Test addNewOrder, don't use such test names", () => {
  addNewOrder({ assignee: "John@mailer.com", price: 120 });
}); //Triggers 100% code coverage, but it doesn't check anything

⚪ ️4.4 Preventing test code issues with Test linters

✅ Do: A set of ESLint plugins were built specifically for inspecting the tests code patterns and discover issues. For example, eslint-plugin-mocha will warn when a test is written at the global level (not a son of a describe() statement) or when tests are skipped which might lead to a false belief that all tests are passing. Similarly, eslint-plugin-jest can, for example, warn when a test has no assertions at all (not checking anything)

❌ Otherwise: Seeing 90% code coverage and 100% green tests will make your face wear a big smile only until you realize that many tests aren’t asserting for anything and many test suites were just skipped. Hopefully, you didn’t deploy anything based on this false observation

describe("Too short description", () => {
  const userToken = userService.getDefaultToken() // *error:no-setup-in-describe, use hooks (sparingly) instead
  it("Some description", () => {});//* error: valid-test-description. Must include the word "Should" + at least 5 words
});

it.skip("Test name", () => {// *error:no-skipped-tests, error:error:no-global-tests. Put tests only under describe or suite
  expect("somevalue"); // error:no-assert
});

it("Test name", () => {*//error:no-identical-title. Assign unique titles to tests
});

Section 5️⃣: CI and Other Quality Measures

⚪ ️ 5.1 Enrich your linters and abort builds that have linting issues

✅ Do: Linters are a free lunch, with 5 min setup you get for free an auto-pilot guarding your code and catching significant issue as you type. Gone are the days where linting was about cosmetics (no semi-colons!). Nowadays, Linters can catch severe issues like errors that are not thrown correctly and losing information. On top of your basic set of rules (like ESLint standard or Airbnb style), consider including some specializing Linters like eslint-plugin-chai-expect that can discover tests without assertions, eslint-plugin-promise can discover promises with no resolve (your code will never continue), eslint-plugin-security which can discover eager regex expressions that might get used for DOS attacks, and eslint-plugin-you-dont-need-lodash-underscore is capable of alarming when the code uses utility library methods that are part of the V8 core methods like Lodash._map(…)

❌ Otherwise: Consider a rainy day where your production keeps crashing but the logs don’t display the error stack trace. What happened? Your code mistakenly threw a non-error object and the stack trace was lost, a good reason for banging your head against a brick wall. A 5 min linter setup could detect this TYPO and save your day

⚪ ️ 5.2 Shorten the feedback loop with local developer-CI

✅ Do: Using a CI with shiny quality inspections like testing, linting, vulnerabilities check, etc? Help developers run this pipeline also locally to solicit instant feedback and shorten the feedback loop. Why? an efficient testing process constitutes many and iterative loops: (1) try-outs -> (2) feedback -> (3) refactor. The faster the feedback is, the more improvement iterations a developer can perform per-module and perfect the results. On the flip, when the feedback is late to come fewer improvement iterations could be packed into a single day, the team might already move forward to another topic/task/module and might not be up for refining that module.

Practically, some CI vendors (Example: CircleCI local CLI) allow running the pipeline locally. Some commercial tools like wallaby provide highly-valuable & testing insights as a developer prototype (no affiliation). Alternatively, you may just add npm script to package.json that runs all the quality commands (e.g. test, lint, vulnerabilities) — use tools like concurrently for parallelization and non-zero exit code if one of the tools failed. Now the developer should just invoke one command — e.g. ‘npm run quality’ — to get instant feedback. Consider also aborting a commit if the quality check failed using a githook (husky can help)

❌ Otherwise: When the quality results arrive the day after the code, testing doesn’t become a fluent part of development rather an after the fact formal artifact

"scripts": {
    "inspect:sanity-testing": "mocha **/**--test.js --grep \"sanity\"",
    "inspect:lint": "eslint .",
    "inspect:vulnerabilities": "npm audit",
    "inspect:license": "license-checker --failOn GPLv2",
    "inspect:complexity": "plato .",

    "inspect:all": "concurrently -c \"bgBlue.bold,bgMagenta.bold,yellow\" \"npm:inspect:quick-testing\" \"npm:inspect:lint\" \"npm:inspect:vulnerabilities\" \"npm:inspect:license\""
  },
  "husky": {
    "hooks": {
      "precommit": "npm run inspect:all",
      "prepush": "npm run inspect:all"
    }
}

⚪ ️5.3 Perform e2e testing over a true production-mirror

✅ Do: End to end (e2e) testing are the main challenge of every CI pipeline — creating an identical ephemeral production mirror on the fly with all the related cloud services can be tedious and expensive. Finding the best compromise is your game: Docker-compose allows crafting isolated dockerized environment with identical containers using a single plain text file but the backing technology (e.g. networking, deployment model) is different from real-world productions. You may combine it with ‘AWS Local’ to work with a stub of the real AWS services. If you went serverless multiple frameworks like serverless and AWS SAM allows the local invocation of FaaS code.

The huge Kubernetes ecosystem is yet to formalize a standard convenient tool for local and CI-mirroring though many new tools are launched frequently. One approach is running a ‘minimized-Kubernetes’ using tools like Minikube and MicroK8s which resemble the real thing only come with less overhead. Another approach is testing over a remote ‘real-Kubernetes’, some CI providers (e.g. Codefresh) has native integration with Kubernetes environment and make it easy to run the CI pipeline over the real thing, others allow custom scripting against a remote Kubernetes.

❌ Otherwise: Using different technologies for production and testing demands maintaining two deployment models and keeps the developers and the ops team separated

deploy:
stage: deploy
image: registry.gitlab.com/gitlab-examples/kubernetes-deploy
script:
- ./configureCluster.sh $KUBE_CA_PEM_FILE $KUBE_URL $KUBE_TOKEN
- kubectl create ns $NAMESPACE
- kubectl create secret -n $NAMESPACE docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_REGISTRY_USER" --docker-password="$CI_REGISTRY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL"
- mkdir .generated
- echo "$CI_BUILD_REF_NAME-$CI_BUILD_REF"
- sed -e "s/TAG/$CI_BUILD_REF_NAME-$CI_BUILD_REF/g" templates/deals.yaml | tee ".generated/deals.yaml"
- kubectl apply --namespace $NAMESPACE -f .generated/deals.yaml
- kubectl apply --namespace $NAMESPACE -f templates/my-sock-shop.yaml
環境：
名前：test-for-ci

⚪️5.4テスト実行の並列化

✅ 実施：正しく行われた場合、テストは24時間年中無休の友人であり、ほぼ瞬時にフィードバックを提供します。実際には、1つのスレッドで500個のCPUバウンドユニットテストを実行すると、時間がかかりすぎる可能性があります。幸いなことに、最新のテストランナーとCIプラットフォーム（Jest、AVA、Mocha拡張機能など）は、テストを複数のプロセスに並列化し、フィードバック時間を大幅に改善することができます。一部のCIベンダーは、コンテナー間でテストを並列化することもあり（！）、フィードバックループをさらに短縮します。ローカルで複数のプロセスを使用する場合でも、複数のマシンを使用するクラウドCLIを使用する場合でも、需要を並列化して、それぞれが異なるプロセスで実行される可能性があるため、テストを自律的に維持します。

❌ それ以外の場合：次の機能をすでにコーディングしているため、新しいコードをプッシュしてから1時間後にテスト結果を取得することは、テストの関連性を低くするための優れたレシピです。

⚪️5.5ライセンスと盗用チェックを使用して法的な問題を回避する

✅ 実施：ライセンスと盗用の問題は、おそらく今のところあなたの主な関心事ではありませんが、10分以内にこのボックスにもチェックを入れてみませんか？ライセンスチェックや盗用チェック（無料プランで商用）などのnpmパッケージの束は、CIパイプラインに簡単に組み込むことができ、制限付きライセンスの依存関係や、Stack Overflowからコピーして貼り付けられ、一部の著作権を侵害していると思われるコードなどの悲しみを検査できます。

❌ それ以外の場合：意図せずに、開発者が不適切なライセンスのパッケージを使用したり、商用コードをコピーして貼り付けたりして、法的な問題に遭遇する可能性があります

//install license-checker in your CI environment or also locally
npm install -g license-checker

//ask it to scan all licenses and fail with exit code other than 0 if it found unauthorized license. The CI system should catch this failure and stop the build
license-checker --summary --failOn BSD

⚪️5.6脆弱な依存関係を常に検査します

✅ 実施： Expressなどの最も信頼できる依存関係でさえ、既知の脆弱性があります。これは、npm auditなどのコミュニティツール、またはsnykなどの商用ツール（無料のコミュニティバージョンも提供）を使用して簡単に使いこなすことができます。両方とも、ビルドごとにCIから呼び出すことができます

❌ それ以外の場合：専用ツールを使用せずにコードを脆弱性からクリーンに保つには、新しい脅威に関するオンライン出版物を常にフォローする必要があります。かなり退屈です

⚪️5.7依存関係の更新を自動化する

✅ Do： Yarnとnpmのpackage-lock.jsonの最新の導入により、深刻な課題が発生しました（地獄への道は善意で舗装されています）—デフォルトでは、パッケージは更新されなくなりました。'npminstall'と'npmupdate'を使用して多くの新しいデプロイメントを実行しているチームでさえ、新しい更新を取得しません。これは、せいぜい標準以下の依存パッケージバージョンにつながるか、最悪の場合脆弱なコードにつながります。チームは現在、開発者の善意とメモリに依存して、package.jsonを手動で更新したり、ncuなどのツールを手動で使用したりしています。より信頼性の高い方法は、最も信頼性の高い依存関係バージョンを取得するプロセスを自動化することですが、特効薬の解決策はありませんが、2つの可能な自動化の道があります。

(1) CI can fail builds that have obsolete dependencies — using tools like ‘npm outdated’ or ‘npm-check-updates (ncu)’ . Doing so will enforce developers to update dependencies.

(2) Use commercial tools that scan the code and automatically send pull requests with updated dependencies. One interesting question remaining is what should be the dependency update policy — updating on every patch generates too many overhead, updating right when a major is released might point to an unstable version (many packages found vulnerable on the very first days after being released, see the eslint-scope incident).

An efficient update policy may allow some ‘vesting period’ — let the code lag behind the @latest for some time and versions before considering the local copy as obsolete (e.g. local version is 1.3.1 and repository version is 1.3.8)

❌ Otherwise: Your production will run packages that have been explicitly tagged by their author as risky

⚪ ️ 5.8 Other, non-Node related, CI tips

✅ Do: This post is focused on testing advice that is related to, or at least can be exemplified with Node JS. This bullet, however, groups few non-Node related tips that are well-known

1. Use a declarative syntax. This is the only option for most vendors but older versions of Jenkins allows using code or UI
2. Opt for a vendor that has native Docker support
3. Fail early, run your fastest tests first. Create a ‘Smoke testing’ step/milestone that groups multiple fast inspections (e.g. linting, unit tests) and provide snappy feedback to the code committer
4. Make it easy to skim-through all build artifacts including test reports, coverage reports, mutation reports, logs, etc
5. Create multiple pipelines/jobs for each event, reuse steps between them. For example, configure a job for feature branch commits and a different one for master PR. Let each reuse logic using shared steps (most vendors provide some mechanism for code reuse)
6. Never embed secrets in a job declaration, grab them from a secret store or from the job’s configuration
7. Explicitly bump version in a release build or at least ensure the developer did so
8. Build only once and perform all the inspections over the single build artifact (e.g. Docker image)
9. Test in an ephemeral environment that doesn’t drift state between builds. Caching node_modules might be the only exception

❌ Otherwise: You‘ll miss years of wisdom

⚪ ️ 5.9 Build matrix: Run the same CI steps using multiple Node versions

✅ Do: Quality checking is about serendipity, the more ground you cover the luckier you get in detecting issues early. When developing reusable packages or running a multi-customer production with various configuration and Node versions, the CI must run the pipeline of tests over all the permutations of configurations. For example, assuming we use MySQL for some customers and Postgres for others — some CI vendors support a feature called ‘Matrix’ which allow running the suit of testing against all permutations of MySQL, Postgres and multiple Node version like 8, 9 and 10. This is done using configuration only without any additional effort (assuming you have testing or any other quality checks). Other CIs who doesn’t support Matrix might have extensions or tweaks to allow that

❌ Otherwise: So after doing all that hard work of writing testing are we going to let bugs sneak in only because of configuration issues?

language: node_js
node_js:
  - "7"
  - "6"
  - "5"
  - "4"
install:
  - npm install
script:
  - npm run test

Team

Yoni Goldberg

Role: Writer

概要：私は独立したコンサルタントであり、フォーチュン500企業やガレージの新興企業と協力してJSおよびNode.jsアプリケーションを磨いています。私が魅了され、テストの芸術を習得することを目指している他のどのトピックよりも。私はNode.jsのベストプラクティスの著者でもあります

📗オンラインコース：このガイドが気に入り、テストスキルを最大限に発揮したいですか？Node.jsとJavaScriptをAからZまでテストする私の包括的なコースにアクセスすることを検討してください

従う：

• 🐦ツイッター
• 📞コンタクト
• ✉️ニュースレター

ブルーノ・シューフラー

役割：技術レビュー担当者およびアドバイザー

すべてのテキストを改訂、改善、リント、ポリッシュするように注意を払いました

概要：フルスタックWebエンジニア、Node.js、GraphQL愛好家

イドリヒター

役割：コンセプト、デザイン、優れたアドバイス

概要：知識豊富なフロントエンド開発者、CSSエキスパート、絵文字フリーク

カイル・マーティン

役割：このプロジェクトの実行を維持し、セキュリティ関連のプラクティスを確認します

概要： Node.jsプロジェクトとWebアプリケーションのセキュリティに取り組むのが大好きです。

寄稿者✨

このリポジトリに貢献してくれたこれらの素晴らしい人々に感謝します！

スコットデイビス 🖋	エイドリアン・レドン 🖋	ステファノマグニ 🖋	Yeoh Joer 🖋	ジョニーモレイラ 🖋	イアン・ジャーマン 🖋	ハーフェズ 🖋
Ruxandra Fediuc 🖋	ジャック 🖋	ピーターカレロ 🖋	Huhgawz 🖋	ハーコンボーチ 🖋	ハイメメンドーサ 🖋	キャメロンダンフォード 🖋
ジョン・ジー 🖋	AurelijusRožėnas 🖋	アーロン 🖋	トム・ネーグル 🖋	イヴ・ヤオ 🖋	ユーザービット 🖋	グラウシアレモス 🚧
koooge 🖋	ミハル 🖋	ロイウォーカー 🖋	だんげん 🖋	biesiadamich 🖋	ヤンリン江 🖋	sanguino 🖋
モーガン 🖋	Lukas Bischof ⚠️ 🖋	JuanMa Ruiz 🖋	ルイス・アンジェロ・ロドリゲス・ジュニア 🖋	ホセ・フェルナンデス 🖋	アレハンドロ・グティエレス・バルセニラ 🖋	ジェイソン 🖋
オタビオアラウージョ ⚠️ 🖋	アレックスイワノフ 🖋	Yiqiao Xu 🖋	ユビン、スー 🌍 💻