コンテンツにスキップ

単体テスト ( UT0 )⚓︎

単体テスト ( UT0 ) は、静的テストと動的テストで構成します。

静的テスト ( UT0 )⚓︎

静的テスト ( UT0 ) の目的⚓︎

  • コーディング規約に準拠したソースコードであるか検証し、開発者間でのバラツキを抑制する
  • ソースコード内の潜在的なバグを自動検出し、品質の向上に役立てる

静的テスト ( UT0 ) で利用するツール⚓︎

上記の目的を達成するため、 AlesInfiny Maia OSS Edition （以降、 AlesInfiny Maia）では以下のツールを用いて静的テストを行います。

  • Checkstyle
    • コーディング規約に準拠した Java コードとなっているか自動的にテストするツールです。
    • 分析ルールは、 Google が提供している「Google Java Style Guide 」をベースにし、警告がなくなるまでコードを修正します。
    • 日本語コメントや IDE とミスマッチするルールは修正して使用します。
  • SpotBugs
    • Java コード内の潜在的なバグを自動検出するツールです。
    • SpotBugs の既定の分析ルールを使用し、警告がなくなるまでコードを修正します。

静的テスト ( UT0 ) のテスト対象⚓︎

静的テストは、すべての Java コードを対象に行います。

静的テスト ( UT0 ) の実行方法⚓︎

IDE および CI ツールを利用して、自動的に各ツールによるテストを行います。 各ツールの報告する警告は、原則コードを修正して対応します。

動的テスト ( UT0 )⚓︎

動的テスト ( UT0 ) の目的⚓︎

  • 業務機能が仕様通り実装されていることを確認する
  • 機能の追加・修正によってデグレードが発生しないことを短時間で確認できる
  • 特に業務機能の中核部分を手厚くテストし、重要機能の障害発生率を下げる

動的テスト ( UT0 ) で利用するツール⚓︎

上記の目的を達成するため、 AlesInfiny Maia では以下のテストフレームワークを用いて UT0 を行います。

  • JUnit
    • Java のテストフレームワークです。
  • Spring Test
    • Spring で構築したアプリケーションのテストを実行するためのツールセットです。
    • 主にモックの作成に使用します。

動的テスト ( UT0 ) のテスト対象⚓︎

動的テスト ( UT0 ) のテスト対象は以下の通りです。

  • アプリケーションコア層 ( ドメインモデル / ドメインサービス / アプリケーションサービス )
  • システム共通部品 ( 全機能 )

他の層の単体テスト

アプリケーションにおいて最も重要なのはアプリケーションコア層に実装される業務ロジックです。 ドメインモデルやドメインサービス、アプリケーションサービスに実装されたロジックが、仕様通りに動作することが最重要です。 アプリケーションコア層以外は、 UT0 でのテストの優先度が相対的に下がります。 特にプレゼンテーション層とインフラストラクチャ層は、 UT0 より高いテストレベルでも、十分にテストを行うことができます。

UT0 は日常的に繰り返し実行するテストであるため、テストが素早く完了することも重要です。 プレゼンテーション層やインフラストラクチャ層のテストは、依存するミドルウェアの初期化に時間を要することが多く、日常的な繰り返しには不向きとも言えます。 UT0 で他のレイヤーのテストを行う場合は、モック化やテストケースの絞り込みなど、短時間でテストを完了できる工夫を施すようにしてください。

動的テスト ( UT0 ) の実行方法⚓︎

動的テストは JUnit 上にテストコードを作成し、 IDE および CI ツールを利用してテストを実行します。 テストは業務ロジックの機能性を担保することを目的にします。 テストコードは AAA パターン に従い、どの環境で実行してもテストが成功するように実装します。

特定の環境でのみ成功するテストを作成してはいけません。 また、テストの事前準備が必要であれば、その作業もテストコードとして実装します。 テストの実行前に人手のテスト準備が必要ないようにします。 テスト対象のクラスが依存するコンポーネントやミドルウェアは、必要に応じてモックを作成し、可能な限り疎結合なテストを実現します。

自動生成コードなど、品質の担保されているコードは、正常動作の確認にとどめます。 業務ロジックに対するテストは重点的に行い、 C2 カバレッジが 100% となるようテストケースを設計します。 重要なコードのテストに十分なコストをかけるよう、濃淡を工夫しましょう。

テストケースの作成には、ブラックボックス技法、ホワイトボックス技法を組み合わせます。 入力パラメーターの組み合わせが多岐にわたる場合は、デシジョンテーブルを用いて整理します。

入力パラメーターは、境界値をそのクラスの代表値として使用します。 また null などの特殊な入力値もテストデータとして追加するようにします。