[コラム] Web サービスのユニットテスト

TechEd 2009 初日の BoF-02 「Visual Studio 2010 で進化するテスト環境」 に参加してまして、 そこで、 アレっ と思う話が出ました。
Web サービスのユニットテストを数千ケース ( 二千件だったかな ) 書いたはいいけど、 テスト実行にすごく時間が掛かった、 と。

「入り口」 から全部のテストを網羅しようとすれば、 テストケースの数が爆発してしまうのはあたりまえで、 だからこそロジックの中の細かいメソッドごとにテストファーストで作って積み上げていくのですが、 その話はここでは置いといて。

テスト実行にとても時間が掛かったというのは、 ひょっとして全部のテストを Web サービス経由で書いてたりしたんじゃないでしょうか? Web サービスがちゃんと呼び出せるかどうかのテストは、 もちろん必要ですが、 Web サービスで動くロジックのテストは、 直接叩いてしまえば良いのです。

つまり…

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
public class WebService1 : System.Web.Services.WebService {
    [WebMethod]
    public string WebServiceFoo(string bar) {
        // 認証とか、クライアント情報の収集とか、ここでやるかも。

        return FooLogic.Foo(bar);
    }
}

public static class FooLogic {
    public static string Foo(string bar) {
        // …複雑なロジック…

        return hoge;
    }
}


…こんなふうに、 Web サービス自体のコード ( WebServiceFoo() ) は、 ほんの薄皮だけにしておいて、 Web サービスに依存しない、 いわば POCO であるロジッククラスのメソッド ( Foo() ) をテストするようにしてやれば、 テストに掛かる時間も短くなるし、 テストが失敗したときの原因調査も楽になることでしょう。