うさぎ組

kyon_mm with software

このエントリーをはてなブックマークに追加

アノテーションを基本とするテスティングフレームワークは使いにくい #SWTestAdvent

はじめに

このエントリはソフトウェアテストAdventCalendar2014の29日目の記事です。

http://connpass.com/event/4544/

きっかけ

RestfuseによるREST API自動試験まとめ(その1) - Taste of Tech Topics http://acro-engineer.hatenablog.com/entry/2014/01/15/114604

上記エントリにあるRestfuseというライブラリを見たのですが、とてもじゃないと使う気になれなかった。その理由を書いておきます。

アノテーションの悪夢

上記のライブラリは機能の大部分をアノテーションで提供しています。これはおそらく既存のテストコードに手を加える必要が少なくなるというメリットはありそうです。

ただ、Javaにおけるアノテーションというのは、「利用者からすると拡張性が低い」わけです。つまりライブラリをラップするというのが、メソッドベースより面倒です。となると、「必須項目だけれど拡張する必要がほとんどない」「デフォルトの挙動をちょっと変えるもの」といった機能に限定したほうが、利用者からすると便利と感じることが多いと思うのです。

例えば、よくWebMVCのフレームワークである、Model<->Viewのバインドとかは比較的限定的なので概ね使いやすいと感じるわけです。

テスティングフレームワークでアノテーションを使うときは、テスティングフレームワーク自体である程度「こういった書き方をしてアノテーション以外の拡張はこうやります」っていうのを導けないと「便利そうだからアノテーションでやりました」になってしまって、「書きたいテスト書けない!!!!」っていうのが発生します。

何がいいたいかというと、JUnit4やNUnitは本当に最悪なわけです。我々がプロダクトコードであれば楽にできる様々なパターンがかなりの割合で使えません。そこで僕なんかはかなりの割合でテスティングフレームワークを作り変える勢いでよく拡張というかJUnitやNUnitのAPIを使ったオリジナルをつくります。

件のものはライブラリなのでそこまで困る事はなさそうですが、よくテスティングフレームワークを自作する身としては、チェーンメソッド、λ、テンプレートパターンとかを活用した感じのAPIのほうが楽になりそうだとは思うわけです。

制限のきついライブラリ/フレームワークを使うときには「制限を超えたときの書き方」が頻繁に出る可能性があるということで、それを統一しておかないと、保守性は下がりやすくなります。非常に難しい問題であり、人数やスキルに依存する(つまり、少人数とかハイスキルであるとかに依存する)のでできれば避けたいわけです。

というわけで、アノテーションベースの何かをつくるときは注意が必要で、JUnit4やNUnitを早く駆逐したいと思うのであります。それでもJUnitやNUnitから学ぶことはたくさんあるので、勉強するのオススメですよ。はい。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

The Art of Unit Testing: With Examples in C#