1. 序章

この記事では、単体テストとテスト駆動開発（TDD）について説明します。 これらのトピックについて詳しく説明し、比較します。 さらに、ソフトウェアのテストが非常に重要である理由を説明します。

2. ユニットテスト

単体テストは通常、ソースコードのごく一部を検証する方法です。 したがって、単体テストはプログラムで作成された自動テストです。 単体テストは初期データを取得し、それをテスト対象のコードに渡し、実行結果が期待される結果と同じであるかどうかをアサートします。

例を見てみましょう。 2つの数値を合計するメソッドがあると仮定します。

このようなメソッドの単体テストは次のようになります。

ご覧のとおり、シンプルに見えます。 効率的な単体テストの記述は、テストするコードによっては複雑になる可能性があります。 適切に記述された単体テストは次のようになります。

  1. 速い。 1つのプロジェクトに、数百または数千もの単体テストを含めることができます。 さらに、ユニットテストは頻繁に実行できます。 たとえば、リグレッションを回避するための新機能の開発中、または CI /CDパイプラインで。 したがって、可能な限り高速に実行する必要があります。
  2. 孤立。 単体テストは、外部の状態を変更したり、依存したりしてはなりません。
  3. 決定論的。 単体テストは、何度実行しても常に同じ結果を返す必要があります。 もちろん、実行間で何も変更されていない場合。
  4. 読み取り可能。 単体テストは、維持する必要のあるコードです。 したがって、それは明確で理解しやすいものでなければなりません。
  5. 単純。 多くの場合、単体テストには単一のアサーションが含まれている必要があると読むことができます。 議論の余地はありますが、実際には、単体テストでソースコードのごく一部を検証する必要があります。

3. ユニットテストが重要な理由

ユニットテストの書き方はすでに知っています。 それらがもたらす利点について説明しましょう。 まず第一に、コードが意図したとおりに機能することを保証します。 さまざまなシナリオ、エッジケース、およびパラメーターの単体テストを作成できます。

次に、コードの作業中など、必要なときにいつでもこれらのシナリオを実行できます。 これらのシナリオをすべて手動で実行すると確かに時間がかかるため、時間を節約できます。 さらに、コードでの作業中の高速で簡単なテストは、既存の機能のリグレッションを回避するのに役立ちます。

次に、単体テストを作成すると、コード品質が向上します。 これは、テスト可能なソースコードを適切に作成する必要があるためです。 したがって、クラスとメソッドは自動的に小さくなり、より具体的になります。

単体テストの重要な利点は、ソフトウェア開発の総コストと時間を削減できることです。 早期のバグ検出により、後で行う場合よりも簡単かつ迅速に修正できますプロジェクトの成長に伴い。

最後になりましたが、維持された単体テストは、テスト対象のコードの目的を説明する実際のドキュメントを常に作成します。

4. TDD

TDDは、ソフトウェア開発へのアプローチであり、単体テストはビジネスロジックの前に記述されます。 つまり、開発者は、機能を実装する前に、その機能の単体テストを作成します。 TDDワークフローについて説明しましょう。

TDDサイクルは3つのステージで構成されています：

  1. 赤–この段階では、まだ実装されていない機能のテストを作成します。 テストを実行して、失敗していることを確認する必要があります。 そうしないと、誤検知が発生します。これは、テストの記述が不適切であることを意味します。 最も人気のあるIDEのディスプレイは、赤色を使用してテストの失敗を表示します。 そのため、ステージは赤と呼ばれています。
  2. 緑–この段階では、テストをカバーするのに十分なコードを記述します。コードの品質ではなく、テストのカバーに焦点を当てる必要があります。 テストに合格するための最小限のコードを記述します。 IDEは、テストに合格したことを緑色で通知することがよくあります。 そのため、ステージはグリーンと呼ばれます。
  3. リファクタリング–最終段階、ここではコード品質の改善に焦点を当てます。したがって、コードを改善するために必要なすべてのリファクタリングを行う必要があります。 変更を加えている間、リグレッションを回避するためにテストを実行できます。

ロジック開発者が問題とそのドメインの分析と理解により多くの時間を費やす前に、適切な単体テストを作成すること。 したがって、コードはすべての要件とクライアントのニーズを満たす可能性が高くなります。 これは、TDDの最も重要な目的の1つです。

実装がより一般的になる一方で、テストは時間とともにより具体的になるため、サイクルは重要な役割を果たします。

5. 比較

TDDは、単体テストよりも広い概念です。 TDDは、問題のドメインを理解し、要件を満たすことに重点を置いたソフトウェア開発アプローチです。ベアユニットテストは、記述されたソースコードを検証し、バグやリグレッションを回避することを目的としています。 実際、単体テストはTDDサイクルの一部です。

第二に、TDDを使用している間、ユニットテストはそれらがカバーする機能の前に書かれなければなりません。 ベアユニットテストは、機能開発中や開発後など、いつでも作成できます。

最後になりましたが、TDDには、プロジェクトに関係するすべての関係者の協力が必要です。 ベアユニットテストは主に開発者の責任です。

ご覧のとおり、TDDと単体テストは大きく異なる概念です。 それらはある時点で接続されていますが、assTDDは部分的に単体テストに依存しています。

6. 結論

この記事では、単体テストとTDDについて詳しく説明しました。 両方の原理を説明し、それらを比較します。 TDDは、特定の作業サイクルを使用したソフトウェア開発アプローチ全体であるため、単体テストよりも広い概念であることを明確にしました。 単体テストはTDDアプローチの有無にかかわらず使用でき、前述のさまざまな方法でプロジェクトに役立ちます。