Windowsアプリの受け入れテストを自動化しよう：特集：受け入れ検査の自動化手法の考察（5/5 ページ）

単体テストの次は、エンド・ユーザーへの納品時の受け入れテストも自動化したい？ それを実現する手法を紹介する。

[石川達也，株式会社Codeer]

Codeer.Friendlyを使ってAPIを実装する

　ここまでに説明してきたように受け入れテストの自動化は、.NET標準のWCFやUIオートメーションを駆使して行えるが、もっと手軽に行う方法はないのだろうか？ 筆者が知る限り、この目的に合致するオープンソース・ソフトウェアやサードパーティ製品は見当たらなかったので、筆者が所属する株式会社Codeerで独自に作成した。せっかく開発したので、広く使っていただけるように無料で公開することにした。それが「Codeer.Friendly」というテスト自動化ライブラリである。

　Codeer.FriendlyはCodeer社のWebサイトからダウンロード可能である（「CodeerFriendlyAndTools」というページ内の［ダウンロード］にあるリンク先からダウンロードできる。ダウンロードしたら、.zipファイルを展開して、32bit環境の場合は「x86」フォルダ、64bit環境の場合は「x64」フォルダ内にあるsetup.exeファイルを実行し、インストール・ウィザードを使って開発環境やテスト環境内にインストールする）。Codeer.Friendlyの詳細に関しても同サイトを参照願いたい。

　このライブラリを使うと、テスト・プロセスからテスト対象プロセスの持つ.NETのフィールド、プロパティ、メソッド、ネイティブDLLの公開関数を指定・実行することができる。

　メリットとしては、テスト対象プロセスに変更を加える必要がないということが挙げられる。また、ネイティブDLL公開関数もサポートしているので、ネイティブ・アプリに関しても有効である。もちろん、GUI層のメソッドを呼び出すことによりUI操作のエミュレートも可能である。

　しかし、前述したWCFやUIオートメーションはマイクロソフト純正の機能なので、サポートやMSDNなどの技術情報が充実しており、安心して使えるだろうが、Codeer.Friendlyの場合、正直なところ、マイクロソフト製品ほど充実しているわけではない（もちろんCodeer.Friendlyでもメールでの問い合わせ窓口やオンライン・ドキュメントを提供している）。

●APIの実装

　次のコードは、Codeer.Friendlyを使ってManagementSystemクラスを操作するためのAPI（＝EmployeeManagementAppクラス）の実装例である（前述のWCFの場合と同様にクラス・ライブラリのプロジェクト内に実装する）。

using System;
using EmployeeManagement;
using System.Diagnostics;
using Codeer.Friendly;
using Codeer.Friendly.Windows;
using System.IO;

namespace EmployeeManagementAPI
{
  public class EmployeeManagementApp : IDisposable
  {
    // 開始。
    public static EmployeeManagementApp Start()
    {
#if DEBUG
      string path = Path.GetFullPath("../../bin/Debug/EmployeeManagement.exe");
#else
      string path = Path.GetFullPath("../../bin/Release/EmployeeManagement.exe");
#endif
      return new EmployeeManagementApp(Process.Start(path));
    }

    WindowsAppFriend app;
    AppVar managementSystem;

    // コンストラクタ。
    public EmployeeManagementApp(Process process)
    {
      app = new WindowsAppFriend(process, "4.0");
      IntPtr handle = Process.GetProcessById(process.Id).MainWindowHandle;
      AppVar mainForm = app["System.Windows.Forms.Control.FromHandle"](handle);
      managementSystem = mainForm["system"]();
    }

    // 終了。
    public void Dispose()
    {
      Process process = Process.GetProcessById(app.ProcessId);
      app.Dispose();
      process.CloseMainWindow();
    }

    // 登録。
    public bool Add(string name, string age, string post)
    {
      return (bool)managementSystem["Add"](name, age, post).Core;
    }

    // 検索。
    public EmployeeData Find(string name)
    {
      return (EmployeeData)managementSystem["Find"](name).Core;
    }
  }
}

リスト6　Codeer.FriendlyでAPIを実装する（EmployeeManagementApp.cs）
EmployeeManagementプロジェクト／Codeer.Friendlyアセンブリ／Codeer.Friendly.Windowsアセンブリへの参照を追加する必要がある。Visual Studioでは［参照の追加］ダイアログの［.NET］タブから追加できる。

　あとは、WCFの場合と全く同じ単体テスト・プロジェクトを使ってテストを実行すると、受け入れテストが実施される。注意点として、テスト対象アプリのプロセスとテスト・プロセスはプラットフォーム・ターゲットを合わせる必要がある。Visual Studioのテスト・ホストはデフォルトではx86で動作する。x64で動作させたい場合は設定の変更が必要となる。設定の詳細に関しては「方法: 64 ビット プロセスとして単体テストを実行する」を参照願いたい。

まとめ

　いかがだっただろうか。APIの実装手段を変更しても、テスト・シナリオには影響が出なかったことは興味深い。これは、「操作」と「テスト」を分離したからこそ実現できたことだ。

　API実装手段としては、ほかにもSendMessage関数でWM_COPYDATAメッセージを使う方法や、メール・スロット、名前付きパイプなどさまざまな方法が考えられる。また、場合によってはキャプチャ＆リプレイ・ツールを使って出力したコードを基にして実装してもよい。これらは、無理にどれか1つに絞ることなく、実装対象のAPIによって、都度最適なものを選択することができる。

　重要なのは「操作」と「テスト」の分離である。

　受け入れテストに限らず、テストの自動化は非常に難しいプラクティスである。それはソフトウェア開発そのものだからである。なので、プロダクト・コード同様にテスト・コードも設計、リファクタリングを実施し、常に可読性、メンテナンス性を高める必要がある。

　ここで挙げた手法は、その一例なので、プロジェクトごとに最適なテスト設計を目指してほしい。

「特集：受け入れ検査の自動化手法の考察」