エキスパートPython勉強会#14に行ってきた

久々の勉強会。そして、ネタはTDD.普段テストとかほとんどしていないダメグラマーなので、非常に興味があった。

TDDやってる？

そもそもの発端は、テストプログラムの質をどうやって維持している？　と言うところから始まった。そして、TDDで使用するテストの意味というのはなんなのか？　

ボク自身の開発スタイルは、こうだ(去年2年間やっていたプロジェクト)。

プロトタイプを高級言語(ここでは、Ruby or Pythonの意)で開発する。ここでの目的は、そもそも実現しようとしている技術が我々のリソースで可能かどうかの検証。
C++で本番プログラムを書き始める。上で大枠のクラス構成なんかは決まっているので、とにかく空のクラスを作りまくり、枠を作る(テストは作っていない)。
その一つ一つを徐々に実装する。テストは用意しないが、ビルド(コンパイル)だけはできることが最低条件。
コードが固まれば、それをドキュメントに落とす。いずれコードが自分の手から離れることを想定して。

いわゆるトップダウン的な開発スタイルだと思っている。

なぜテストを書かないか？それは、@voluntas 先生が指摘した通りだと思っているのだけど、実装がない段階で境界値テストなんてできない、と思っているから。後は、やはり実装の速度を優先する必要があるから、と言うのもある。

話はそこからどんどん先に進んで、「では、漏れのないテストをどうやって実現するか？　テストジェネレータを使うか？」というような知らない世界に進んで行く。

結局TDDって？

今回の勉強会で一貫していたのは、テストの重要性は誰もが認めているところ。バグが出たら、そこに対してテストを書いて、テストが通ることを確認している、と言うスタイルは、皆さん一致知っていたように思う。

なので、TDDをやっている、やっていないに関わらず、テストは皆さん書いているし、それを実行するためにテストスイートも使っている。

結局、テストファーストなのか、コードファーストなのかは、重要な問題ではないんだなぁ、と言うことを実感した。どちらを採用するかは、開発チームの方針によるのだろう。TDDが品質を向上させる魔法のアイテムというのではなく、一つのキッカケに過ぎない、ということがわかっただけでも価値があった、と言える。

では、結局TDDで書いているテストと言うのは何なのだろう？　ボクには、仕様をコードに埋め込む、と言うように感じられた。なので、QAテストである必要はない。要は、後にそのコードをメンテする必要がでたときに、いちいち仕様書を見ないといけないのか(そもそも、仕様書がない場合の方が多い気がする)、コードを見ただけで、だいたいの動作が予想できるか。この差は大きいのではないか？

ということで

技術的には全然ついていけなかったが、テストに対しての姿勢を超1流プログラマの方から伺えたのは貴重な機会だった、と思う。

必ずしもTDDにこだわる必要はない。しかし、テストを残していくのは、後にコードをメンテナンスする人への最低限の思いやりであり、エチケットではないか、と感じた。