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

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

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

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

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

「単体テスト項目作成」とかいう名目だと、何も言われずにスルーされたりする不思議。でもそう謳うと「項目書」を成果物として作らないといけなくなるので別名で誤魔化せないことも多々。

最初は良くても、仕様変更が頻繁に入ると毎回のテストコードの修正が疎かになりそう。ほんとはそういうときのデグレード防止に効果的なはずだけど。

既存の全てのメソッドに今から適用するわけにもいかず、小さな内部メソッドまで作るものなのか？という迷い。作りを変えたら連動してテストコードも弄らないといけない（＝手間）という感覚。

実行時のコンテキストオブジェクトが必要だったり、動的に状態が変わるクラスなどを単体テスト時にどうやってその「テストしたい状態」に持っていくか。

とにかく「急いで作れ」なプレッシャーがかかる。バグ出しはテスターに大きく任せてしまっている。これが一番阻害要因かも。

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

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

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