目次

Webアプリケーションの単体テスト

 アプリケーションサーバーの準備やテスト対象クラスのデプロイ、テストの入力を与えるためのHTTP通信を実現している複雑なクラスが関係してくることが多く、単体テストの定義に捉われて単一モジュールに対してテストを行うと、多くのスタブやドライバを作成する必要がある。その結果、スタブやドライバの開発にコストがかかり、効率が悪くなる。また、開発したスタブやドライバにバグを埋め込んでしまう可能性もあり、テスト結果の信頼性が下がってしまう。

 しかし、Webアプリケーションの単体テストは困難であることから、単体テストを行わずに、結合テストに入る開発現場がある。すると、本来単体テスト時に見つけるべきであったバグが結合テストで多発する。また結合テストなので多くのクラスが関連を持っており、バグの原因を探るのに時間がかかってしまう。

 以上のことから、アプリケーションの階層やクラスの種類によってテストをする順序を決め、段階的に単体テストを行うのが有効である。

  1. スタブやドライバを作るのが困難な場合は、すでにテスト済みのクラスを使用する。
  2. DBを必要とする場合は、DBアクセス用のツールを用いてテスト用のデータの設定・確認する。
    • DBのスキーマが正しいことはあらかじめ保障されていることが前提である。
  3. Webコンテナを必要とするクラスが必要な場合は、モックオブジェクトアプローチを検討する。
    • モックオブジェクトアプローチとはモックオブジェクトを作成して環境をエミュレートすることである。
    • モックオブジェクトアプローチに対して、実際のWebコンテナを利用するテスト方法をインコンテナアプローチと呼ぶ。

[補講]モックはスタブと似ているが厳密には異なるものである。モックはメソッドの呼び出し順序などの振る舞いに着目するテストに用いられる。一方、スタブはオブジェクトの状態に着目するテストで用いられる。 ◇

モックオブジェクトアプローチ vs. インコンテナアプローチ

  • モックオブジェクトアプローチ
    • メリット
      • 利用するクラスが未完成でも、仕様さえ固まっていればテストできる。
      • 環境や他のクラスに依存せずに、毎回同じ条件でテストが実行できる。
    • デメリット
      • 粒度の細かいテストができるが、その分テストは大変になる。
      • モックオブジェクトの作成にスキルが必要となる。
      • 本番環境で完全に動作することは保障されない。
  • インコンテナアプローチ
    • メリット
      • 実際の環境での動作が保障される。
      • 手間がかからない。
    • デメリット
      • テストの粒度が粗い。
      • 環境構築が煩雑である。
      • 利用するクラスをすべて完成させておく必要がある。

参考文献

  • 『現場で使えるソフトウェアテスト Java編』