日付に対する単体テストはよく議論の対象になる。つまり、テストケースの中の固定の日付に依存するようなテストではテストにならないという点がしばしば話題にのぼる。特定の日付に依存するテストがパスしても、結局それはその特定の日付でだけパスするということでしかない。この問題に対する標準的なアドバイスとして、依存性注入を使う方法がある(BigVisible社のAdam Sroka氏)。
いくつかの日付をテストする必要がある場合、それらの日付を計算メソッドにわたしてやります。このメソッドは日付に対して計算処理をしますが、メソッドの内部から、計算対象の日付を取得しないようにします。日付型から現在時を取得するのも、データベースから日付を取得するのもユーザの入力から取得するのもだめです。高いレベルで日付を取得し、計算メソッドに渡してやります。
この方法が単体テストでどのように動作するのか、確認するのは簡単だ。しかし、まだ問題は残る。すなわち、受け入れ/システムテストではどうするか? Andreas Ebbert-Karroum氏は、まさにこの問題に直面し、次の３つの選択肢を思いついた。
- テストケースの期待される結果も日付/時間に依存するようにする。
- アプリケーションを変更してシステムの現在日付を使わずに、現在日付とは違う日付をリモートから設定できるようなサービスを使う。
- システムの日付をリモートから変えてしまう。
xUnit Test Patternsの著者であるGerard Meszaros氏は、#2として知られているバーチャルクロックパターンを使っている。
私たちの場合は、現実の時間を取得できるサービス(システムの時間APIの呼び出しのインターフェイス)の上に抽象レイヤをかぶせています。そして、テストの時にはテスト用のスクリプトを使って抽象レイヤの実装を変更可能な時間取得サービスに置き換えます。既定では、抽象レイヤには、実際に利用する実装がセットされています。We use an abstraction layer over top of the real time service (read: hide the calls to the system time API behind an interface) and then replace the implementation when testing with one controllable by the test scripts. By default, the real implementation is plugged in.
良い点: すべてのテスト条件が確実にテストできます。時間の競合状態のテストもできます。
ソフトウエア開発のコーチであるGeorge Dinwiddie氏は、単一の時間リソースを使えば、複数のマシンの複数の時間リソースを参照しているシステムで起こりうる厄介な問題を回避できる、と述べている。複数の時間リソースを参照しているシステムというのは、例えば、あるマシンではそのマシンの時間リソースを使い、他のマシンではデータベースの時間を使っているというようなシステムだ。
Ward Cunnigham氏 (wikipedia)は別の方法を採用している。“"swim"というフレームワークを使って、ここ最近までテストをしていました。このときは、$nowというグローバル置換文字列が入ったSQL文を作成し、テストのときに式でその文字列を置換するようにしていました。その式は、時間の経過を、時、日、週で表します。こうすることでトレースしたSQLがとても見やすくなるという利点が得られました。”
Mike Stockdale氏はFitSharpの開発者だ。氏が言うには、FitSharpは相対日付変換をサポートしている。例えばtoday+2というような値だ。FitLibraryの開発者であるRick Mugridge氏が書いているのは、FitLibraryには、“一般的に使える日付生成"DSL"があり、これを使えば異なったタイムゾーンの中から任意の相対日付を選択できますし、また様々な書式が使えます。例えば、月の最終日とか、月曜日などという指定の仕方で日付を選択できます。この機能は、未来の日付の選択する機能がとても重要な役割を果たし、テストする時にはテスト用のデータ(とテスト用の日付)を使わなければならないような予約システムで広範囲に使われてきました。”一方、テスト自動化アーキテクトのMartin Gijsen氏はこの問題を解決するためにANTLRを使っている。
Andreas氏が挙げた選択肢のうちの1番目と2番目の方法が広く使われているようだが、あなたはどうだろうか。これらの方法にはどんな利点と欠点があるだろう。