Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

テストコードの目的と意味

twop.agile.esm.co.jp
とにかく良記事! だいじなことが書いてあると思うので、しっかり引用。
(赤文字は私がかってにやってます。大事なことばを太字にしました。)

和田:(中略)でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてしまって、テストは書かなければならないので書く、みたいな感じになってしまった。
  
家永:「不安を取り除くために自分が自信を持って」のはずなのに。
  
和田:「不安が退屈に変わるまでテストを書く」とか「壊れそうな、危なかしいものに対してテストを書く」みたいな、ちょっとフワッとした言葉で初期アジャイリストたちが言った言葉が、今は「テストを書かなければならないからテストを書かされる」になった。
 
つまり(TDDは)権利じゃなくて義務になっちゃっているんですね。今の若者にとってテストというのは、やらなきゃいけない、まさに「テスト」みたいに義務化されてしまったもので、自分たちの不安を取り除くためにテストコードを書いているんじゃなくて、やれと言われているからしょうがなくやっている。内発的じゃないんですよ
 
家永:本来は、自分自身が、コントローラブルなものを増やしていくという活動の中にテストの自動化があって、そこにリファクタリングというのを自信をもってやりながら、要望に応えていくというところを作っていきたいはず。それが、嬉しい気分の維持のために(自分自身の意思で)前のめりにテストとリファクタリングをやっていくというよりも(誰かに言われて)やれとなっている
  
和田:やれと言われるからやる。だから、得てして変化を助けるテストコードになってないんですよ。実装の追認でしかないテストコードになっている。「私はこういうふうに実装しました」というテストコードを書いてしまいがちなんですね。
 
家永:よくカバレッジだけ追っかけて。

家永:(プログラマーが)内部の設計やリファクタリングに関して、あまり思い入れの無いまま。
 
和田:リファクタリングが射程に入ってないテストコードになっちゃっているソフトウェアの内部の質は、テストコードを書いても基本的に変わらない。リファクタリングしないと内部の質は上がらないのにリファクタリングを行うという発想がそもそも無くなっちゃっている。テストコードは増えるし、テストカバレッジは増えるんだけど、ソフトウェアの設計自体は全然良くなっていないという結果になってしまう。「私はこういうふうにコードを書きましたというような、こういう仕事をしました」という証明のためだけのテストコードみたいな。

家永:(中略)無理やりコードは変えずにテスト通してしまうとか、それは確かに起きている。
 
懸田:それは、テストという側面しか見てないからそうなっちゃうんだと思います。
 
家永:キーワードとして、テストというキーワードが前面に。(リファクタリングや設計が後ろに)
  
和田:前面に出ちゃうとそうなる。例えば、検収要件としてカバレッジ何パーセントという条件が出てくるとかは、既存の実装に対してその動作を保証してほしいという重力が強いんですよね。
  
既存の実装の現状肯定じゃなくて、未来のコードベースに対して発展と成長の可能性をキープしていく意味合いでのテストコードの価値というのは、ほとんど話題に上らない。既存の実装に対して、みんなこだわり過ぎという話はある

TDDが「テスト手法」と思われていたり、テストコードがそのまま「単体テスト」となってしまうから、なのだと思う。
TDDは「テストコードを使って、動かしながら設計する」こと、という本来の目的や考え方が理解されていないと、
「ただの単体テスト」になってしまうのだろう、と思う。
リファクタをどうやろう・どう使おう、というところも難しい話。
小さくつくりながら、「Red/Green/Refactor」のごく小さなサイクルを回しながら、というところ。
テストコードを使いながら、その上に「次のコード」を重ねていこうとするところ。

尤も、私自身ちゃんとTDDをやっているわけではないので、ぜんぜんまったくエラそうなことは言えんのですがね。
seichi23.hatenablog.com