単体テストやTDDに対して感じていること

Androidのテスト環境について - 日本Androidの会 | Google グループ

Androidでのユニットテストか…、ユニットテストって未だに実践でやってみたことないな、と軽くググっていたら、

「あなたがTDDやユニットテストについて課題に感じていることがあれば、教えてください。」 - @katzchang.contexts

こんなエントリを見つけた。

2010年の段階でTDDやテストコードを書く開発手法自体を知らないという人は、ほとんどいなくなっていると思うのだけど、実際に導入しているかというとまた別の話というのはまだまだ根強い。

私の周りも、テストコードを書く必要性を感じているメンバーは全員では無いがいるものの、以下の点を含め色々なことから実現できていない。

• スケジュールや工数見積もりに「テストコード作成」として作業タスクを載せづらい
「単体テスト項目作成」とかいう名目だと、何も言われずにスルーされたりする不思議。でもそう謳うと「項目書」を成果物として作らないといけなくなるので別名で誤魔化せないことも多々。
• テストコード自体の保守が面倒ではないかという不安
最初は良くても、仕様変更が頻繁に入ると毎回のテストコードの修正が疎かになりそう。ほんとはそういうときのデグレード防止に効果的なはずだけど。
• どこまでのメソッドに対してテストコードを作成するかの基準が難しい
既存の全てのメソッドに今から適用するわけにもいかず、小さな内部メソッドまで作るものなのか？という迷い。作りを変えたら連動してテストコードも弄らないといけない（＝手間）という感覚。
• 様々なクラスのインスタンスを使って処理しているので、テストコード内での事前準備が面倒
実行時のコンテキストオブジェクトが必要だったり、動的に状態が変わるクラスなどを単体テスト時にどうやってその「テストしたい状態」に持っていくか。
• プロジェクトのスケジュール上、「作って簡単に動かしたらとりあえずリリース」という文化が強い
とにかく「急いで作れ」なプレッシャーがかかる。バグ出しはテスターに大きく任せてしまっている。これが一番阻害要因かも。

バグ修正によるデグレードも過去によく起きているプロジェクトで、退行試験の必要性は感じているのだけども。

なんだろう、実際の処理コードとは別の「ソースコード」を作って保守して…ってのが手間だと思ってしまう感覚が阻害しているのかも。かといってExcelで「単体試験項目書」をコツコツと起こすのも（納品物として指定されてるならともかく）、非効率だと思うし…。

意識を変えるのが先なのかなぁ。