事前注文で利用できるもう1つのノベルティであるユニットテストに関する本に注目してください。
本日の出版物の著者は、フロントエンドを例として使用して、ユニットテストとTDDの利点について簡潔かつ明確に説明しています。
読書を楽しむ！
ユニットテストは、すべての開発者が取るべき最も重要なアプローチの1つです。しかし、ユニットテストを実施するのが難しいプロジェクトをたくさん見ました。これにはいくつかの理由があります。たとえば、機能の開発に集中する必要があると誰かが言うかもしれません。この場合、ユニットテストを作成することは深刻な追加の負担です。コード自体が複雑であるため、コードのテストは簡単ではないことに気付く人もいます。どちらの場合も、要点を見逃しています。
この表現を覚えています。ユニットテストを作成する時間があるかどうかを考えるときは、バグや問題が発生するため、同じコードを2回処理するための余分な時間があるかどうかを考えてください。
テスト可能なコードの記述
まず、一般的な間違いがコードのテストをより困難にする原因を定義しましょう。フロントエンドテストに関して、私が知っている最も難しい問題の1つは、ユーザーインターフェイスコンポーネントのテストです。この場合に発生した主な問題は次のとおりです。コンポーネントが「スマート」すぎて、API呼び出し、データの読み込み、イベント処理、ビジネスロジックの実装など、他のコードフラグメントへの依存関係でハングしていることがあります。多くの開発者は、このような「重い」コンポーネントのテストを作成することを好みません。
この問題の最も簡単な解決策は、コンポーネントをロジックとプレゼンテーションに分離することです。この分離により、プレゼンテーションコンポーネントがプレゼンテーションロジックにどのように準拠しているかをテストし、イベント処理とレンダリングを実行し、ロジックを担当するコンポーネントでビジネスロジックのテストに個別に集中できます。
コンポーネントがテスト可能であることを確認することは、コンポーネントが独立していて、再利用可能で、一緒に使用するのに便利であることを確認するための良い方法でもあります。これは、特にBit（Github）などの一般的なツールやプラットフォームを使用してプロジェクト間でコンポーネントを共有する場合に絶対に必要です。）。通常、Bitは各コンポーネントを個別に表示してテストし、共有コレクションに送信するだけで、実際に再利用できることを確認します。それ以外の場合は、コンポーネントを分離可能にすることのポイントです。
例：Bit.devで共有される再利用可能なReactコンポーネントの調査
悪循環：ユニットテストを書かないとどうなるか
ユニットテストを適切に適用しない（つまり、テストカバレッジをメトリックとして使用しない）チームでの私の経験から、ユニットテストの開始が遅すぎるか、最初から開始しましたが、それを実践することを学びませんでした。これには多くの理由が考えられますが、どれがあなたのケースに最も類似しているかを簡単に判断できるように、いくつかの例を示します。
開発中にコードをテストする方法
私の意見では、テストドリブン開発（TDD）に固執しない限り、フロントエンドが常にブラウザーにロードされていれば、機能を開発できます。これはクライアント側の開発の本質であるため、ユーザーインターフェイスで発生する機能と相互作用の視覚化に焦点を当てる必要があります。
その後、すべての機能がすでに機能している場合にのみ、重点がユニットテストに移ります。
直面しなければならない主な問題は次のとおりです。ユニットテストの作成は、機能の開発が完了した後に実行される追加の作業です。このアプローチは、ユニットテストが既製の機能の開発に加えて実行される追加のタスクであるという印象につながります。
この質問の定式化により、製品の所有者と開発者の両方がユニットテストをコストとして分類します。
しかし、TDDに固執すると、すべてが正反対に発展します。テストケースは事前に作成されているため、開発中にコードをチェックする方法が異なるため、変更を常に視覚化してすべてをチェックする必要はありません。この場合、主な検証ツールは、ユニットテストケースに合格するコードを作成することです。
したがって、ユニットテストを実施する前の最も重要な段階は、TDDの実施であると思います。
ユニットテストが実行される頻度
ユニットテストの実行がユニットテストの記述方法にどのように影響するのか疑問に思われるかもしれません。たとえば、テストの完全なセットがあるとします。あなたは時々それを追放します。したがって、開発者がその有用性を確信することはめったにありません。また、テストが失敗した場合でも手遅れです。
したがって、少なくともプルリクエストビルドのすべての段階でユニットテストを実行することが重要です。DevOpsから採用したこのプラクティスに従うことで、追加するすべての新しいコードブロックが一連のユニットテストに合格することを保証します。特定のケースを変更する必要がある場合でも、開発者はコードマージが実行される前に変更を行います。
テストによってコードカバレッジを測定する頻度
テスト実行の場合と同様に、この測定は心理的にも、開発者が記述されたすべてのコードをカバーするのに十分なテストケースを準備しているかどうかを判断するための実践としても重要です。
この場合、ユニットテストの範囲を表示できるダッシュボードだけでは不十分だと思います。ただし、新しいコードを追加するときに測定動作を追加して、テストカバレッジのレベルを確認することができれば、そのような代替手段は、即座にフィードバックを得るのに便利です。データベースに追加された新しいコードは、たとえば80％のテストでカバーする必要があるというルールを作成することもできます。この検証をプルリクエストのビルドプロセスに追加するのが最も適切です。
開発者はコードのユニットテストカバレッジに関するフィードバックを即座に受け取るため、必要に応じてそのようなカバレッジに追いつくための措置を自由に講じることができます。
このサークルから抜け出す
この悪循環にすでに関与している場合、それから抜け出すための最良の方法は、上記の慣行を強化することです。上記は、新しく追加されたコードを検証するための頻繁なテストと、新しいコードのカバレッジのテストに関するものであるため、コードの追加または変更のあらゆる操作に適した手順を開発できます。
新しいコードを作成する前に、（プロジェクト自体が完全に新しい場合を除いて）すべての古いコードをテストでカバーするのに十分な時間がある可能性はほとんどありません。したがって、ビジネスの観点からは実用的ではないため、まったく信頼しないでください。それまでの間、定期的に測定を行い、古いコードの特定の部分をテストで戦略的にカバーすることができます。最も重要なことは、この慣行に従うようにすべての開発者をトレーニングする必要があります。この作業をコストとして学習せず、ユニットテストを作成することの重要性をすべてのプロジェクト所有者に伝えることも同様に重要です。そうでなければ、多くの、特に技術者以外の人は、ユニットテストは余分な作業であり、新しい機能の開発に時間を費やすことができると考えるかもしれません。
それで、このすべての仕事の真の価値は何ですか
ユニットテストは多くの点で役立ちます。正しく適用すると、コードの欠陥数を減らし、既存の機能をテストする際の保険として機能し、コードをリファクタリングするときに損傷を受けず、全体的な生産性を高レベルに保つのに役立ちます。
ユニットテストで十分にカバーされているコードを見ると、誰もがそれがどれほど自信を持っているかを見ることができます。それでは、ギャップを埋めて、DevOpsプラクティスを採用し、テスト主導の開発に固執しながら、優れたユニットテストの作成に慣れることで軌道に戻りましょう。