UnitTestのとらえ方

レガシーコード改善ガイド (Object Oriented SELECTION)*1id:rf0444の研究室で読んでいました。
ちょっと勧められて読んだのですが、正直買うかどうか迷うぐらい自分では欲しい内容でした。

  • テストが無ければ、いくら綺麗であっても、そのコードはレガシーコードである。
  • 早く動けば、そのテストはUnitTest(単体テスト)である。


4章まで読んで、以上の事柄が述べられています。
ここまで読んで、訳書しか読んでないので分からないのですが、単体テストの部位はUnitTestを訳したものだと思いました。


日本語を読んでいて、「複数のクラスやメソッドを使っていても、早く動くのであればそれは単体テストである」と書かれても、言葉を辞書通りに受け取ると、矛盾しているんですよね。そのように単体テストを定義し直しているのですが、やはり言葉に引きずられている感は否めません。

単体テスト(Unit Testing)
単体テスト、あるいはユニットテストとは、メソッドなどの小さな単位で行うテストのことである。単体テストは、ホワイトボックステストを利用して行われる場合が多い。「Unit Testing」の略である「UT」と呼ばれることが多い。また、開発現場によっては「CT(和製:Coding Test)」や「PT(和製:Program Test)」と略されることもある。
Wikipedia - ソフトウェアテスト(wikipedia:ソフトウェアテスト)


確かに言葉はイメージを膨らませて、理解を助けます。
しかし、そのイメージに引きずられ、本質の理解をさせてくれない場合があります。
単体テスト」という言葉はまさにその好例だと思います。


単体テスト」はUnitTestの一部の側面を表しているものに過ぎません。
Unitには、単一だけではなく、1群や構成単位と言った訳もあります。*2そのような感覚を切り捨てて、ただ単に「単体テスト」として名前を定着させてしまったことが、日本におけるテストの普及を妨げている気がしています。

TDDやリファクタリングにおける「UnitTest」も、単体テストと訳されているために誤解されている部分も、少なからずあるように思います。

それが証拠に、前に考察したシナリオベーステストですが、制作者が意図すれば、レガシー改善上での「UnitTest」の定義を満たすようにシナリオを作成出来ます。

これを書いた理由は「単体テスト」ということばに引っかかったからなのですが、(レガシー改善の定義に基づく)UnitTestを(TDDを行う際に)書くとさえ言われてしまえば、何も問題は無いはずです。


なお、先にtwitterで大体同じ内容を呟いたところ、id:t-wadaさんより以下の様なコメントを頂きました。

@a_hisame そうです。だから、テストを大きさや粒度で分類するのは誤解を生みやすいと考えています。私は「誰が、何のために」で分類しています。
http://twitter.com/t_wada/status/5253889616

結局は「何のための」テストかが重要であって、そのための大きさや粒度は重要では無い、ということで多分解釈は間違っていないと思います。
自分もこの意見には賛成です。


と、言うわけで。
今後は誤解を与えないために、出来る限りUnitTestという単語を用いたいと思います。ここでいうUnitTestは、何度も実行されうる軽量のテストを指して言います。
メソッドベースのテスト手法を特定して指す場合は誤解を与えないので、単体テストという名前を用いますが。


………買うかどうか、迷う。

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

*1:レガシー, legacy: (悪い)遺産の様な意味合いでここでは使われているはず。 レガシーコード=悪いコードと考えてお読み下さい。訂正:この本では、ただ単にテストの無いコードを指す。辞書的な意味では「新しいものが出現したが、長年使われ、いろいろな事情で完全に捨てることができない古い技術や仕様など。」という意味もある。出展はEijiro 3rd。

*2:出展:Eijiro 3rd