ユニットテストについて

InfoQのある記事について。

人気のあるテーマは、「開発者のテスト」とそれ以外の人がするテストの間の違いについてである。常にディスカッションを通して、開発者はユニットテストを書くだけだという考えがあった。要望に対するテスト、受け入れテスト、統合テスト、そして他の形式のテスト全ては、誰か他の人の問題である。

これは、ユニットテストのコミュニティの基本的な誤解をはっきりと示している。具体的に言うと、全ての開発者が、他のタイプのテストをすべて扱う QAチームを持つという前提を持っているのだ。残念ながら、数百万ドルの会社でさえ、QAリソースがまったくないことが多く、すべてのテストは開発者とエンドユーザに残されている。
テスト: 開発者が期待されていること対実際にすること

わからない。どこの世界の開発文化のことなのだろう。
確かに大きなプロジェクトになればなるほど、高次元のテストに進むにつれ、また機能要件のテストと非機能要件のテストでは、責任者と担当者は開発者とは別の人が行うことがあるが、ユニットテストが終わったら後はQAチームに任せればいいなんてパラダイムを持つプロジェクト（人）を見たことはない。少なくとも日本では。
どこか狭い領域の開発者のことを言っているのか、僕が見たことのある世界が狭いのか。
開発者は、テストの違いによって大小の差はあれど、責任がなくなるわけはないし、統合テストやパフォーマンステストの結果は気になるし、気にすべきだと思う。

セッションの初めに、データベースが軽視されていることが認められた。大抵のデータベース開発者は、ほんの少しか、または、まったくユニットテストの考えを持たず、彼らをサポートするツールも少ししかない。もっと問題なのは、交渉の場に参加するように聞かれもしないことである。残念なことに、彼らについて言われたのはそれがすべてであった。
テスト: 開発者が期待されていること対実際にすること

データベースだけではない。ユニットテストの意義や重要性はわかっていると、口では言うが、実際にしようとしない、したがらない、ユニットテスト＜統合テスト＜システムテストと、ランク付けしてしまっているプロジェクト（人）が多い気がする。
そんな人達は、打鍵でテストしたり、Selenium や Rational Functional Tester のようなツールを使って、ブラックボックスのテストで済ませてしまおうと考える。
こんな考えの下で開発が行われ、C/Oを向かえ、保守／運用に入ると、残された人達、新たに保守担当者として招き入れられた人達は、残念ながらかわいそうだ。（※１）
「くれぐれもデグレを起こさないように気を付けてね」なんて言われてバトン（現場では最近これをもっぱらチケットと呼ぶ）を渡される。
ところがどんなに気をつけていても時にデグレは起こってしまうから、残念としか言えない。

これはプロジェクトの初期に開発の方針やフローを考えたり、会議の中で決定を下す人達（※２）に（全部とは言えないだろうが）責任がある。
なんでユニットテストはしないと決定がなされてしまうのかは、TCOよりプロジェクト予算が優先されてしまったり（※３）、人が気をつけてさえいれば（運さえ悪くなければ）デグレは起こらないといった考えがあるのだろう。

いやいや、ユニットテストは大事だよ。
後から全てのクラスのユニットテストを書くのは想像を絶するほど大変だと思う。
大抵の場合はもうずっと打鍵テストで押し通すことになってしまうのではないかな。

※１
　決して他人事ではない
※２
　別の畑から異動してきた情報システム部門の部課長がプロジェクトマネージャだったり、別の畑から転職してきた外部のコンサルタントがPMOだったり
※３
　ユニットテストはテストコードやモックを書いたりするのに時間がかかると思われていたり、当初の計画に歪みがでて逼迫し、マイルストーンに無理やり合わせる為に簡単なテストに置き換えられてしまったりするのだと思う