トップ «前の日記(2010-03-08) 最新 次の日記(2010-03-14)» 編集

2010-03-13 [長年日記]

_ TDD BootCamp 北陸1日目

2日目もあります

イベントに行ってきた

去年の年末にあったTDD読書会&ふりかえり(実はその日記書いてない;)からの流れも含めて、なんと!

あの! t_wada が!

とか書いておくと follower がやってきてくれるかもしれないので名前出しを先にやってしまうけど、

に参加してきました。トラックバックセンターは

TDD Boot Camp 北陸に登壇させていただきました - t-wadaの日記

かな?

会場

白山里のウェブサイト/白山麓の自然に囲まれた天然温泉の宿、体験・研修交流館

で、分かる人は「バードハミング鳥越を越えて花ゆうゆうのもうちょい先」で分かります。ものすごい山奥を想像してたけど、地元民からすればある程度は想定の範囲内。ただし電波的にはかなり孤島で、

docomo, au OK
SoftBank, WILLCOM, e-mobileNG

です。施設の回線も弱く、イベント参加者の tweets が一部の人に偏っていたのはそういう理由からです。

小松駅集合

イベント自体には何も手を出していなかったので、送迎と酒の準備だけしました。朝に高速乗ったらどしゃ降りで前なんにも見えなくなって焦ったけど、洗車しなくてよかったなとか違うことを思ったりしていた。

小松駅で目印のために MacBook を広げてお迎え。なぜかこの瞬間、カバンの紐をまとめていたゴムがちぎれてしまった。まぁもう12年目だもんな、これ。

誰一人面識もないうえに場所もよく知らなかったけど、なんとかなるもんです。Google と Twitter があればボクらはもう平気。なのかもしれない。

内容

  • レクチャー
  • Workshop 1
  • Workshop 2

レクチャー

t_wada 節の初歩*1

現代の開発において

  1. バージョン管理
  2. テスティング
  3. 自動化

以上は

三本柱である。

「三種の神器では切実さが足りない」とも仰ってまして、あーなるほどなぁと。

三本あって初めて自立できる

のだな。

以降は個人的に刺さった部分だけ箇条書きメモ。

  • バグの発見は早ければ早いほどいい
    • (最近、自分はこの言葉を自明として端折る傾向がある)
  • テストパス率を計るとか、そういうんじゃないんだ。一つずつ進むんだ。
  • TDD の「黄金の回転」
    • (JOJO成分が足りなかった。一瞬分からなかった。)
  • テスト手法の観点から「書くべきテスト」を挙げることはできるのだが、TDDのテストはまず「不安」の部分をテストすることが大事
  • スピリチュアルプログラミング(笑)
    • 祈ることでなく確かめることが大事
  • 「デバッガではダメです。再現できないから。」
  • 書籍売り込みモード(違
  • Fragile Tests (一部の変更でドガーンとコケるテスト)
    • 内部構造に依存しちゃダメ。(同じことがプロダクトコードの結合にも言えるな。)
  • FakeIt
    • テストコード自体の間違いを生まないために、無駄っぽいテストを軽視しちゃダメ
    • (テストファーストに徹しきれていないので、ときどきポカをやっちゃうんだよな)
  • 三角測量
    • GREEN のテストにテストを足して RED になることを確認して、コードを書く
  • Obvious Implementation
    • (「えいや」)
  • TDDに才能は必要ない
    • 「オレのは『技術(ワザ)』だ」
小さい単位

小さい単位に分割すること自体はスキルであり、慣れが必要であるという点が個人的には実はとても共感できるポイントだった。自分のコードが testable になってきたと感じられるまでに恐らく1年くらいは掛かっているから。

ちなみに読めるものは以下のものが該当するので、もしかしたら2年掛かっているかもしれません。

テストの書き方
assertEquals( expect, actual )

実は、この書き方、今まで逆にしていた。確認したい動作を先に書いて、期待する結果を後に書いていた。考え方次第なのかもしれないけど、

ゴールを先に書く

ということが大事だと、急に目が覚めた。反省した。

Feedback 重要

「決まっているものを変えない」「動いてるコードに触れるな」は No Feedbacks だよなと思った。そうか、そうだな、Feedback があることも安心感に繋がるんだ。

Workshop1 - 簡単なワードフィルタ実装

ワードフィルタの実装をペアプロ & TDD で行う。

Ruby で憧れの @ukstudio たんとペアだお。でへへ。と思ったけど、ここでいきなり宗教戦争勃発。Ruby というキーワードが同じだけで、Emacs vs Vim、日本語キーボード vs 英語キーボード、Test::Unit vs RSpec、もう何もかも違う。がーん、uk たんとは分かり合えないお。

ということで、あんまりよくないんだろうなと思いながら全面的に @ukstudio さんにおんぶにだっこ。rspec を丁寧に教えてもらう。

  • rspec すげぇ! 絶対使う! レポート見やすい! pending 超ステキ!
  • 普段テストの名前に頓着がないことが発覚

これまでも TDD ライクではあったんだけど、入り口が「とにかくユニットテストを行う」だったので、まずは網羅的にメソッドのテストを書くということしか意識できていなかった。単純に「test_目的のメソッド()」という形で作ってゴリゴリテストするというスタイルで、実際、プロダクトコードの読みやすさには気を使っていたけどテストコード自体はお世辞にも読みやすいとは言えない状態だった。

またこの形では確実にテストしにくいメソッドが出てくるのも気になっていた。普段は敢えて private などは作っていないのでテストできるが、でもこいつだけテストしても仕方ないよな、というメソッドは出てくる。このとき、単純にプロダクトのメソッドとテストメソッドの関係を 1:1 にするのではなく、意図とテストコードの関係を 1:1 にして記述できていればよいのではないかと思い至った。実際には他のペアを含めたペアプロ後の発表を聞いていて思ったんだけど。

この気づきは大きかった。すぐに活かすことはできないけれど、徐々にテストコード自体、あるいはテストの実行結果を設計書として読み下せる状態を目指したいと思う。

Workshop2 - 大変だ! 仕様変更だ!

ペアを変えて仕様変更に取り組む。

Ruby組4人のうち、@mitukiii と @wtnabe は両刀だったこと、PHP組が2人しかおらず、ペアの変更ができなかったこともあり、このセッションは PHP にスイッチした。

今度は逆に自分の方が TDD のスタイルに慣れていたのでいつもの SimpleTest + Terminal 上のテスト実行の形で引っ張る。Workshop1 の C# ペアだったかがやっていたのを真似して git に突っ込みながらやることに。

ただ、説明しながら書きながら思ったのは、やっぱり自分はテストファーストじゃないんだなぁって辺り。事情があって急いでいたのもあって、いつもの要領でプロダクトのメソッド2つ書いてテストメソッド2つ書いて、みたいなこともやってしまった。悪い例を見せてしまったかもしれない。ごめんなさい。

この仕様変更ではある程度何をどう実現するのかは自由だったので、ペアで設計を議論した。これもやりたいやりたいと思いながらも普段なかなかできなくなっていたことなので、とてもよかった。インターフェイスをどう決めるかによってステップの大きさが変わるケースだったので、より小さいステップになる方法を選ぼう、と言えた自分を誉めたい。そういう発想ができる程度にはイテレーティブにやれているんだなと振り返れた。

※ ところで、この仕様変更では「NG ワードを複数設定できるようにする」という変更があったのですが、他の組の発表で、filter そのものはいじらず、filter を複数に増やすという方法を採用しているところがあって、こーれはやられたなと思いました。


発表の際にちょっと勝手なことを言ったんだけど、もう一度まとめておこう。

  • PHP は標準でテスティングフレームワークが付属していない
  • 「Java にとっての eclipse」のような絶対的な環境がない
  • (フルスタックフレームワークが個別にテストツールも持っている*2

ため、「Terminal でテストを動かすのはあまりやらないんじゃないか」という旨のことを言った。これはやっているところが「ない」という意味じゃないんだけど、一般的な「PHPのコードを書いている人」にとってはテスティングフレームワーク自体があまり馴染みがないのかなということは感じている。

BootCamp 会場では Rubyist, Pythonista に比べて PHPer が少なかったわけだけど、いわゆる「現場」で PHPer の方が少ないっていうのはかなり考えにくいことで、その比率だけ見ても違和感はあるし、このセッションでペアを組んだ方も ZendFramework は使っているがテスティングフレームワークは使っていない様子だったし、これまで PHP の仕事を発注した経験からも、TDD というかユニットテストを揃えて早期に自動テストを回し始めるスタイルでやっているところはかなり少ないんじゃないか。他の言語での開発を発注したことはないので、PHP だけの特徴かどうかは分からないけど。

こうした話とはまた別な理由で PHP ではテストのやりにくさを感じているんだけど、これはまた後日書けたら書きます。

合宿 - 新たな「黄金の回転」の誕生

ご飯と自己紹介。仕事で GAE ! Python ! 何それ都会ってすげぇ!

持ち込みました。「白山」とふぐのぬか漬け。概ね好評でした。白山とぬか漬けの回転、ビールとビーバーの回転。回る回る。

自分はこの夜の部ではもう一切機械には触れず、酒を飲みながら @yuuitiro さんと酒談義したり、どうしても生で聞きたかった @ukstudio さんの職業プログラマ観を聞いたり、最後の方はなんか愚痴ったりしていました。おっさんにはきつい時間でしたが、とても楽しく、またためになる時間を過ごせました。ありがとうございます。

2日目に続くよ。

Tags: TDD Study

*1 @nagise 談

*2 これは当日言わなかった

本日のツッコミ(全2件) [ツッコミを入れる]
_ kumonopanya (2010-03-18 05:21)

<br>書籍売り込みモード(違 <= わからない <br>Implemantation => Implementation <br>RED になることを確認して、コードを書く <= これは納得 <br>Rspecで日本語の参考書が欲しくなった。(英語は・・・orz)

_ wtnabe (2010-03-18 09:38)

コメントありがとうございます。書籍の紹介はが続いた部分は正直ちょっとあまり覚えていないのです(笑) 書籍メモはたぶん他の人がやってくれるだろうと思って別なこと考えてました。 <br> <br>rspec はちょうどいい教材がこんなところに :-) http://d.hatena.ne.jp/t-wada/20100228/p1