テーマ「TDD…そして Be Agile」
と題し、テスト駆動開発の伝道師、和田さんを初め、豪華講師陣でした。
今回私はスタッフとして参加させて頂きました。
正直、広島という地方都市で、TDDというテーマで人が集まるのか懐疑的でしたが、
結果９３名の方々に集まって頂きました。ありがとうございました。
広島のような地方都市でも、TDDやアジャイル開発に興味関心がある人がこれだけいるという事が示せたのも成果だと思います。
また、参加者の方には学生の方も多く、学校で習うソフトウエア工学では出てこないような「プロの」話が聞けて大変刺激になったのではないかと思います。
正直、これだけの講師陣と会場運営を無料セミナーで行うのは大変でした。
殆ど一人で尽力された実行委員長には頭が下がります。
個人的な収穫としては、DBのようなバッチ処理をTDDで行うにはどうすれば良いのか？という点と、
TDDのテストが正しいことはどのようにしてテストするのか？
という長年の疑問点を和田さんにぶつけ、合点が言ったことが非常に大きかったです。
TDDでは三角測量の話が出てきます。
- 実装する前にテストを実行し、失敗するのを確認（RED)
- テストが通る最小のコードを書く（GREEN)
- 本物の実装を行う（Refactoring)
これの[テストが通る最小のコードを書く]がどうにもモヤっとしていました。
なぜわざわざテストを書くのにそれをごまかすような実装をしないといけないのか？
また、テストコードが実装が正しいことを証明するのなら、テストコードの正しさは何処で証明するのか？
この仮実装ともいうべきステップは正にテストコードが正しく機能するかのテストフェーズなんですね。
あと、TDDの伝道師、TDDの開発者と言われる和田さんも、初めから上手く言ったわけではなく、罠にはまりながらやられていたという点非常に共感がもてました。
GUIなどTDDし難い所を無理やりテストするのではなく、そこは人間の優れている点なのだから人間がテストする。テストしにくい箇所はテストしない。という割り切りも大切だと気付かされました。
ウォーターフロー開発が否定され、TDDが出てきたように、TDDもいつか否定される時代が来るのかなぁと思いながら、まずは目の前の現実を何とかしないと。
0 件のコメント:
コメントを投稿