「WindowsアプリケーションにおけるMSTestの活用」

[新規作成]→[プロジェクト]から、テストプロジェクト／プロジェクト名を指定します。

ユニットテストプロジェクトに、テスト対象(TargetApp)の参照を追加します。

[追加]→[新しいテスト]でユニットテスト用クラスを新規作成して、テストコードを記述します。
テストコードは、Windowsアプリケーション開発経験のある方であれば、実際のソフトウェアをコーディングするのと同じ感覚で、ユニットテストのテストパターン作成が行えると思います。

下記の例では、TargetApp プロジェクトに定義されたCalculateクラスのテストコード記述例を示します。
※ Calculate クラスの下記3つのメソッドの単体試験を行うテストコードになります。

• Sigmaメソッド … シグマ計算
• Averageメソッド … 平均計算
• StandardDevメソッド … 標準偏差計算

/// <summary> 
/// ユニットテスト１ クラス
/// </summary>
[TestClass]
public class UnitTest1
{
    /// <summary>テスト対象クラス</summary>
    static Caluculate _Target = null;
    /// <summary>テストデータ</summary>
    static double[] _TestData = new double[] { 5.67, 1.23, 4.56, 3.45, 2.34 };

    /// <summary>シグマ計算 期待値</summary>
    static double _TestExpectedSigma = 17.25;
    /// <summary>平均計算 期待値</summary>   
    static double _TestExpectedAverage = 3.45;
    /// <summary>標準偏差計算 期待値</summary>  
    static double _TestExpectedStandardDev = 1.56977705423413;

    /// <summary>
    /// 最初のテスト実行前の処理
    /// </summary>
    /// <param name="testContext">[in] テストコンテキスト</param>
    [ClassInitialize()]
    public static void ClassInitialize(TestContext testContext)
    {
        //テスト対象インスタンス生成
        _Target = new Caluculate();
    }

    /// <summary>
    /// 全てのテスト実行後の処理
    /// </summary>
    [ClassCleanup()]
    public static void ClassCleanup()
    {
        _Target = null;
    }

    /// <summary>
    /// 各テストを実行する前の処理
    /// </summary>
    [TestInitialize()]
    public void TestInitialize()
    {
    }

    /// <summary>
    /// 各テストを実行した後の処理
    /// </summary>
    [TestCleanup()]
    public void TestCleanup()
    {
    }

    /// <summary>
    ///Sigma のテスト
    ///</summary>
    [TestMethod()]
    public void Calculate_Sigma_Test()
    {
        double dActual = _Target.Sigma(_TestData);
        Assert.AreEqual(_TestExpectedSigma, dActual);
    }

    /// <summary>
    ///Average のテスト
    ///</summary>
    [TestMethod()]
    public void Calculate_Average_Test()
    {
        double dActual = _Target.Average(_TestData);
        Assert.AreEqual(_TestExpectedAverage, dActual);
    }

    /// <summary>
    ///StandardDev のテスト
    ///</summary>
    [TestMethod()]
    public void Calculate_StandardDev_Test()
    {
        double dActual = _Target.StandardDev(_TestData);
        Assert.AreEqual(_TestExpectedStandardDev.ToString("F10"), dActual.ToString("F10"));
    }
}

[テスト(T)]→[実行(R)]→[ソリューションのすべてのテスト(A)]の実行で、ユニットテストを実行します。
実行結果は、テスト結果ウィンドウに表示されます。

図5. MSTest:テストプロジェクト実行結果

テストパターン(テスト条件：境界値、エラー)は、実際のプロジェクトに組み込んで使うシチュエーションを想定しながら「テストコード」の対応を行います。この対応時に、テスト対象の「テストコードの記述しにくさ（I/Fの問題）」や「設計時の考慮不足による異常系の処理実装漏れ」などに気づくことができます。
早い段階(結合テスト前)で内在した問題箇所に気づける機会になる点だけでもテストフレームワークを活用する意味があると思います。

単調で、同じようなテストの繰り返しの場合、テストフレームワークを利用したユニットテスト環境を構築すれば、テストコードに沿って確実に繰り返し試験を実行することが可能です。
単体試験項目書を作成する感覚で「テストコード」を作成すれば良いので、実行するテストパターンが作成できれば、テストは自動で行えることがメリットに感じます。

例えば、外部非公開のPrivateメソッド／プロパティについても、「PrivateObject」クラスを利用することで、試験対象とすることが可能です。このような機能により、テストのためにテスト対象のモジュールを変更するといったリスクを負わずにすみます。
クラス内でのみ共通利用するモジュール系は、外部非公開のメソッドである場合がほとんどだと思いますので、試験対象の内部処理が複雑なケースでは、外部非公開I/Fを試験対象とすることで品質向上が見込めるような場合は積極的に対応していきたいところです。

単体試験を自動実行できるので、繰り返し(回帰)テストで大きなメリットが得られると思います。
共通モジュール部に変更を加える場合などに、該当モジュールをコールしている箇所への影響がないことの確認が容易に行えます。
長期にわたってメンテナンスが行われ、定期的な改修が見込まれる場合などにも有用です。

テストコードは論理的に記述すべき性格のものなので、入力に対する期待値が一意に決まらないものは試験対象にできません。

テストフレームワークは試験対象のクラスI/Fの単体試験を目的としたものになりますので、UI操作／表示確認周りの試験は行えません。該当試験フェーズは結合試験時になると思いますので、UI操作／表示部の機能実現に使用されるクラスI/Fの品質を、テストフレームワークを使用した単体試験によって担保するのが本来の利用方法になります。

前述しているように、テストフレームワークを活用することでテスト対象のクラスI/Fの単体試験を自動実行させることが可能ですが、対応できるからといって全てのクラスI/Fをテスト対象とするのはテスト環境(テストパターンの検討＆テストコードの作成)の構築コストの観点から現実的ではありません。
また、テストフレームワークで対応するよりも、人手で確認した方が、対応が容易で時間がかからないケースも存在します。

単体試験を組み合わせたテスト条件を構築することで、結合試験前にある程度、複合的なパターンによる試験を実行することも可能です。
ユニットテスト用に作成したテストコードを組み合わせて実行させることで、様々な使用場面を想定した試験を自動化できる点が魅力です。
例えば、テスト対象クラスが管理している内部情報／状態が、複数のI/Fをコールする順番などで挙動が変わるようなケースで利用シーンが見込めます。

図6. MSTest：順序指定テストの追加

様々なテストパターンデータ(入力値)でテストを実現するのに、パターンデータを全てテストコードで記述するのは労力が伴います。
このようなケースでは、テストパターンデータを外部ファイル(エクセルやCSVファイル)や、DB（データベース）で読み込んだ情報を利用することで、効率良く対応できる場合もあります。
注意点としては、テストデータの作成に効率化／自由度を見込める変わりに、試験条件がテストプロジェクトでクローズしなくなるため、試験に使用するテストパターンデータ(外部ファイル or DB)をきちんと管理していく必要性が生じます。

PC OSが管理するシステムタイム精度の制限はありますが、試験対象のモジュール処理時間を計測して、想定時間内に処理が完了するかのテストが可能です。

using System.Diagnostics;  //Stopwatchクラス利用

    /// <summary>
    ///StandardDev の処理時間テスト
    ///</summary>
    [TestMethod()]
    public void Calculate_StandardDev_TestTime()
    {
        Stopwatch swTime = new Stopwatch();
        //ターゲットモジュールの処理時間
        swTime.Start();         _Target.StandardDev(_TestData);
        swTime.Stop();

        //処理時間が100msを越えていればエラー
        if (swTime.ElapsedMilliseconds > 100)
        {
            Assert.Fail("Calculate_StandardDev(...) 処理時間100msオーバ");
        }
    }

図7. MSTest:テストコードの記述例 (処理時間テスト)