参加希望者114名、参加可能36名という熾烈な競争を勝ち抜いてTDD Bootcamp 1.5 in Tokyoに参加してきました！
目次
TDDBCで起こったことのまとめ
- TDD Boot Camp in Tokyo #tddbc – ものすごい勢いでトゥギャられる光景に圧巻。
- TDDBC 東京 1.5 – 講演の内容についてはtomykairaさんのページを見れば大体把握できる。
個人的に講演から感じたこと
教科書的に言われるテストコードと、実際に現場で書かなければならないテストコードのギャップ
「さあ、TDDをはじめよう！」と思ってもできないのは、やっぱり教科書コードと現場コードのギャップなのだと思う。
例えば「OAuthを利用してログインを作っているけど、これはどうやってテストすればいいの？」というモックを利用したテストにおける問題だとか、「口座集約して節約できた振込手数料を逆仕訳して総勘定元帳に連携する」という実装の抽象度の問題だとか、そういった「この問題に対してはどうやってテストコードを書けばいいのか？」という部分が次のネックになっていく。
この辺の問題は一重に「修行が足りん！」で片付けられる問題だとは思うのだけど、継続的なフォローが必要な部分だと思っている。特に私はRailsのテストで悩んでいるので、Rails Test Prescription読書会だの、Railsテストパターンの勉強会だのしてみたいなー、と思うのです。
DeveloperTesting等といった分類に対する違和感
これは、恐らく、私がSIerの人間だから。恐らくこういった分類は、製品を作る上でのロールに基づく分類なのだな、と思う。受託開発ではSEがDeveloperTestingとQATesting両方をやると思うので。
テストの脆さ
「環境が変わったら動かない」「privateな部分を変更しただけなのに何故かテストが落ちる」
あるあるな問題だと思うので、テストコードの書き方だけで一冊の本があっても良いと思った。xUnit Test Patternsがこの溝を埋めてくれるのかな？
個人的なKPT
Keep
- 「プロトタイピングでは別にTDDしなくても良くない？」と思っていたけど、その通りであることが確認できた。ただ、後からテスト書けるぐらいには綺麗に書いておきたいね。
- 言語別の席分けはナイス。名札にも使用言語書いてもらえば良かったかもね。Groovyの人はうさみみをつければ良かったと思う。
Problem
- Rubyの基本的な文法やRSpecでの基本的な書き方の訓練をしていなさすぎて、普通のコーディングができていなかった。。大反省。
- 「リファクタリング」という言葉の誤用について怒られた。。ちゃんとリファクタ本を読み返します。。（Rubyエディションだけど）
- 黄金の回転を回しているようで回せていなかった。テストをGreenにした後のリファクタリングができていない。結果的に「テストは通るけどその後が難しい」感じの設計になってしまうことが体感できたのは収穫だったかな？
- 「SQLとか混ざるとTDDって難しいよね」という話あり。SQLだったら、条件に合致するようなテストデータをDBに設定してテストするのかな？ fixture作る壁が厚すぎるな。。
Try
- 「テスト駆動開発入門」は写経しなければなるまい。
- Ruby技術者認定試験の話があった。基本仕様をおさえるために試験勉強しても良いかな、という気になった。
- WindowsならTortoiseHgが激アツという話を伺えた。凄く良い環境になっているらしいので、導入を検討してみよう。#scmbcでMercurialにしようかBazaarで参戦しようか迷うなぁ。。
最後に
TDDBC in Tokyo1.5関係者の皆様、素敵なイベントをありがとうございました！
