JaSST 2011 Tokyo

2日目を聞きに雅叙園に行ってきた。聞いたのは2つ。
「TDDライブ〜テストとアジャイルのクロスカップリング〜」と「「はやぶさ」をミッション完遂に導いたソフトウェア開発」
1つ目のTDDに関することを書く。

開発者に対するテスト担当について

もしチームにテストだけをやる人がいるとして、その人がTDD、つまり設計段階でいっしょにやれるなら開発がグッとうまくいくだろうし、拡張版TDDはその呼び水になれそうな感じがした。でもそのテストの人に期待するところがテスト技法や知識、経験であり、でもこれらは開発者として持っておくことだろうから、行き着くべきゴールは、テストの人がいなくなりみんなが開発者となって、ただ得意不得意でテストの技法や知識を持って設計する人がいたり、別な得意分野で設計する人がいる、そんな状態だと思う。

悪い傾向への対策として

グループメンバーの一人が、テスト担当者がかなり細かなテストをしてくれるため、自分はそれほどテストをやらずにソースコードをコミットする、と言いだした。これは悪い傾向だ。こういうときに拡張版TDDを導入し、強制的にテストの人の考えに沿った設計をさせ、開発者によるテストの必要性や、テスト技法を理解させるのはいいんじゃないだろうか。

TDDについて

先日、別のグループメンバーが、自分の担当した機能について、その入出力を確認できるテストコードを付属させてきた。見てみるととてもシンプルで理解しやすいテストコードで、そのコードを読むだけで彼の実装部分の使い方がわかる、まさに外部仕様が表されていると言ってもいいものだった。もしこのテストコードを実装前に作っていれば、TDDの概念を使った設計になる。(もちろん彼の作ったコードだけでは実装コードを書ききることは出来ないが、) 別にxUnitを使わなくても、ペアじゃなくても、TDDは普通に成立すると思う。

拡張版TDDについて

上に書いたメンバーの一人が作ったテストコードは、テスト網羅率とか品質を担保するとか、そんな考えとは無縁なものだった。似ているけど別の思考で作られた物に感じる。拡張版はそんなテストコードに網羅率の考えを入れようとしているけど、二兎を追っているように思える。上に書いたように呼び水になりそうだけど、でも所詮TDDはTDDで、その範囲を拡大する必要はないんじゃないだろうか。