Testing Context(仮)という考え方

ちょっと前Quick JUnitの管理者でもあるかくたにさんとQuick JUnitをどう改良しようか、話してきました。その時に聞いてきたアイディアに名づけるとするならTesting Context。

以前はTesting Pairだけ考えてればよかったのに。

Quick JUnitでは実装クラスに対するテストクラスが1対となって存在するという、Testing Pairという考えを元に作られています。Ctrl+9でテストクラスと実装クラスを切り替えられる、というあれです。JUnit3の時代までは必ずTestCaseクラスを継承しなければならない、テストメソッド名はtest_で始まらなければならないなど、いくつか制限がありました。なので名前で実装クラスとテストクラスを対応づけられるよう、実装クラス名+Testをテストクラス名として検索できるようになっています。実は隠してるんですが、その対応を増やせるようにするための設定画面がありますね。

JUnit4の登場でテストに対する考えがちょっと変わった!?

既にJUnit4が広く使われる時代。@Testアノテーションがメソッドについていればテストクラス、と言う時代です。JUnit3のころでもいくつかのクラスを組み合わせて動くような、機能テストもしますよね。実はテストクラスと実装クラスってそもそも1対1の対応ではないのです。真面目にテストを書いていくといくつかのテストクラスから実装クラスがテストされる関係になるはずです。ちょっと眠くなって来たので論理飛躍しますけど、テストにはテストをしたいコンテキストが存在します。それは一つのクラスだけを扱う場合もあれば、いくつかのクラスを扱って振る舞いを検証することもあります。パフォーマンス要件に達しているのか検証するためのテストクラスもありますよね。テストメソッドが、どのクラスを検証したいのか、コンテキストを示すことができるはずなんです。
そこでそれを僕はTesting Contextと呼んでみました。

Testing Contextとは?

Testing Contextはテストメソッドに対して、どのクラスをテストするのか、アノテーションで記述したもの、と定義します。
テストメソッドが実装をどうテストするのか、ドキュメントとして残っているとうれしいと思うんですが、それを切り替えにも使えるように出来たら結構便利かも!?と思ったわけです。
それが実装クラス上ではマーカーとして表示されれば、テストされているクラスか、そうではないのかすぐに見分けることができます。マーカーからテストへリンクするのです。(正直マーカーをつけるとなるとパフォーマンスに悩まされそうなのでやりたくない＞＜)
テストメソッドに記述できるコンテキストは何も実装クラスだけに留まらず、URLとかMylynと組み合わせてチケット番号を結びつけられれば、障害とテストも結びつけられます。ここまでくればたいしたもんでしょ。すごいでしょ。(作ってもないのに自画自賛)

実際にどんな仕様なの？

上記を仕様としてまとめます。大事なことなので2回書きます。
今考えている仕様はテストメソッドに対してテスト対象のクラスをアノテーションで記述し、Quick JUnitではそのアノテーションを元に切り替えを行います。記述するアノテーションは厳密にはアノテーションではないですが、既存の枠組みで考えるとJavaDocの@seeタグか、@linkタグが一番適当だと考えています。
逆にプロダクトコードの方ではテストコードのタグでリンクが貼られているクラス、メソッドではマーカーが表示され、テストコードとリンクされていることが分かるようにします。
こうすることでテストコードがどのクラスをテストしているのか、またプロダクトコードではどういった観点でテストされているのかを明示できるのではないかと考えています。

アイディアを書き出した、というだけですがどーすかね。しかもTesting Contextなんて名前どう考えても誰か言ってるよなぁ。

追記

• ブクマ米で「(仮)」がついていたのでタイトルを変更しました。
• RSpecだとspecをまとめるのがContextらしいので、素直に直せばTesting Setか？