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

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

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

powered by Insider.NET

連載目次

受け入れテスト（＝受け入れ検査）の自動化は、ユニット・テスト（＝単体検査）の自動化より難易度が高い。

　一般的にはこのようにいわれている。

　なお受け入れテストとは、エンド・ユーザーが使うのと同じシチュエーションでアプリやシステムをテストすること、つまりシステムの検収のことである。ユニット・テストがメソッドなどの最小の実装単位でその内容をテストするのに対し、受け入れテストではユーザー操作単位でテストするという違いがある。特にアジャイル開発では、小さく機能を追加しながら頻繁にリリースするので、検収の回数も増えてしまい、エンド・ユーザーの負担になってしまうことがある。

　このような課題に対処する1つの案として、受け入れテストの自動化の手法が考えられているわけだが、その手法を現実に実装する段階では、冒頭のとおり、「その実現は難しい」と一般的に考えられている。しかし、例えば社員管理アプリ（＝Windowsアプリ）を作っているとして、その受け入れテストに次のようなテストが記述できるとしたらどうだろうか？

using Microsoft.VisualStudio.TestTools.UnitTesting;
using EmployeeManagementAPI;
using EmployeeManagement;

namespace TestProject
{
  [TestMethod]
  public void Test()
  {
    // アプリの起動。スコープを抜けるときにアプリ終了。
    using (EmployeeManagementApp app = EmployeeManagementApp.Start())
    {
      // 社員情報の登録。
      Assert.IsTrue(app.Add("山田太郎", "28", "係長"));

      // 年齢は数値のみ入力可能。
      Assert.IsFalse(app.Add("鈴木次郎", "32才", "部長"));

      // 同一名称の登録は許容しない仕様。
      Assert.IsFalse(app.Add("山田太郎", "30才", "次長"));

      // 検索 ヒットしない
      EmployeeData findSuzuki = app.Find("鈴木次郎");
      Assert.IsNull(findSuzuki);

      // 検索 ヒット
      EmployeeData findYamada = app.Find("山田太郎");
      Assert.AreEqual("山田太郎", findYamada.Name);
      Assert.AreEqual(28, findYamada.Age);
      Assert.AreEqual("係長", findYamada.Post);
    }
  }
}

リスト1　シンプルな受け入れテストのテスト・シナリオ（AcceptanceTest.cs）

　上記のEmployeeManagementAppクラスは、社員管理アプリをテスト・プロセスから操作するシンプルなインターフェイスを備えている。このクラスを使うことで、テスト・シナリオをユニット・テストのようなイメージで記述できるようになっている。

　このように、GUIアプリをコードから操作するためのAPI（＝プログラミング・インターフェイス）が存在すれば、可読性の高いテスト・シナリオを書くことが可能となる。

　本稿では、上記の例に示したようなAPIを使ってWindowsアプリの受け入れテストを自動化する方法を筆者なりにまとめる。なお、本稿ではコードは全てC#で記述する。本稿のサンプルは、こちらからダウンロードできる。

受け入れテストの自動化でよくある問題点

　受け入れテストを自動化した際に、よく問題となるのは、メンテナンス性である。何らかの仕様変更が入った場合、作ったスクリプトをメンテナンスするのが困難であるため、せっかく作成したスクリプトを破棄するという話もよく聞く。

　このようなスクリプトには、難しい2つの処理が混ざって実装されていることが多い。

　その難しい処理とは、「テスト仕様」と「GUI操作」の2つである。

　特にキャプチャ＆リプレイ・ツール（具体的にはVisual Studioのコード化されたテスト機能など）を使って作成したコードは、必然的にこの2つの処理が混ざってしまう。

　「GUI操作」のコードは複雑でボリュームが大きく、重要な「テスト仕様」の情報がそれに埋もれてしまう。そのため、しばらく時間がたってから、テスト・シナリオを読み返すとき、何を検証したくてそのコードを書いたのかを理解するのに時間がかかってしまう。場合によっては誤解を招き、正しくメンテナンスできないこともある。

●問題点解決へのアプローチ

　重要なのは「テスト仕様」に沿ってアプリをテストすることである。「GUI操作」はその手段にすぎない。場合によっては「GUI操作」ではなく、テスト用に実装された特殊インターフェイスを使用するように置き換えても構わない場合もある。GUI層とビジネス・ロジック層を分離して実装していれば、GUI操作部分のテストまで自動化しなくてもよいのだ。

　そのため、本稿では「GUI操作」ではなく「アプリ操作」のインターフェイス（API）を使う方法を提案する。APIを使ってテスト・シナリオを書くことにより、そこにはっきりと「外部仕様」が読み取れるようになるのである。また、ささいな仕様変更であれば、API部分の実装を修正するだけでテスト・シナリオの修正が必要ない場合もある。

　それでは次のページからは、具体的にどのようなAPIを設計＆実装すればよいのかについてサンプル・コードで示しながら説明していこう。