[markdown]
こんにちはみなさん、@niisan-tokyoです。 先日 10⁄27 にt-wadaさんをお招きして、TDDのワークショップが開催されました。 t-wadaさんは最近ケント・ベック氏著の「テスト駆動開発(TDD)」についての書籍の翻訳を出版されており、 タイムリーなタイミングでワークショップが開かれたと思います。

言うまでもなく真ん中の方がt-wadaさんですね。 ちなみに、右側にいるのは昔の室長の@remoreです。 随分前に、彼もTDDについて精力的に推進しようと活動していたようです。

## ワークショップの構成
今回のワークショップは以下のような構成でした。

* t-wadaさんによるTDDについての講義とデモ
* ペアプログラミングとTDDの演習
* レビュー
* 懇親会
## t-wadaさんによるTDDについての講義とデモ
内容が盛り沢山だったので、詳細については述べませんが、自分が「おお！」と思った部分について、かいつまんで感想を述べてみます。

### TDDの目的は「キレイ」で「動作する」コードを書くこと
そりゃそうだろって思われるかもしれませんが、「キレイなコード」と「動作するコード」を同じウェイトで考えているところに、とても新鮮味を感じました。 というのも、テストを語る際に、「動作する」「キレイ」のどちらかに重きを置き、もう一方をおまけ程度に考えてしまうことが多かったからです。 昔私が書いた記事でも同じようなことをしており、 テストについて推進する際に、少々「動作する」方面に力を入れ過ぎだったと自戒しております。 実際にテストを書いていると、私の場合はかなりの頻度でリファクタリングを入れてますので、論と行動がずれていたなと思いました。

### テストコードもリファクタリングする
実コードをリファクタリングするのは当然なのですが、一方でテストコードもリファクタリングするべきという考え方で、 これも実際にはやってはいたのですが、実際に言及することはほとんどしていませんでした。 また、特に衝撃的だったのが、不要なテストコードは消すという考え方で、これまではテストは仕様の確かめなので、基本的に消すことはないと思っていた自分にとって、 とても新鮮でした。 冗長なテストコードはメンテしにくくなるうえ、よけいなテストがあることによってテストの実行時間もかかってしまいますので、要らないテストは消しておくに限りますね。 ただし、いらないかどうかは書いた本人くらいにしかわからないので、不要だと判断したら、本人が消しておこうという話でした。

## TDDの演習
こちらがメインパートですね。 TDDをペアプログラミングで実施しようというもので、TDDだけでなく、ペアプログラミングも体験できるというものです。 また、自由な言語で実装することで、各言語におけるテストや実装の方法などを見ることもできる、一粒で３度美味しい企画です！

各ペアごとに実装の方針とか、テストの考え方が違っていて面白いですよ！

### ペアプログラミングのメリット・デメリット
今回、10ペア程度でそれぞれが実装を行いましたが、その中でペアプログラミングのメリット・デメリットが見えてきたような気がします。 簡単にまとめてみました。

メリット
ペアプロのメリットはなんといっても、一方がコードを書いているとき、もう一方がそれを観察しているため、奇妙なコードになったり予期しないエラーが出たとき、 別の視点から助言することができるところにあります。 ネーミングみたいな細かい点も、後のメンテナンス性に影響をあたえるので、予め合意を取れるのはありがたかったです。

デメリット
テストの粒度、コードの規約、その他書き方などについて、ペア内で意見が対立することがあり、この場合は作業が遅滞する可能性があります。 また、そうでなくとも一つのコードを二人で書くことになるので、作業効率が1/2…とまでは言いませんが、ある程度下がります。 特に、意見対立が長引くと、作業遅滞が顕在化するため、揉めた場合のルールとかを用意する必要があるかもって思いました。

## 懇親会
懇親会はピザが出され、少々のお酒も用意され、和やかに行われました。

」

またメシのはなししてる…

もちろんご飯がメインじゃないですよ！ 色々と聞きたいことを聞きまくったので、ここで報告しておきますね。

### ライオンのスタンドについて
t-wadaさんといえば、サバンナのライオンのパロディで有名で、彼が作っているOSS、power-assertにもライオンのシンボルが使われています。 ただ、ライオンはあくまでスタンドであり、本人ではないのだが、そのスタンドのお陰で若者に怖がられているフシがあるとのこと。 実際にもとても穏やかな方なので、怖がらないようにしましょう！

### カンファレンスなどでの講演について
私もPHPカンファレンスで登壇したりしているので、せっかくなので聞いてみました。

やはり登壇するときは緊張するし、会場ごとに特性が違うので、それによる手直しとかも、発表直前までやることがあるようです。 特にスクリーンの位置と大きさはかなり気を使う点で、例えばPiOの大展示ホールとかは広さに対してスクリーンがちっちゃかったりします。

### テストの粒度について
私は最近ではLaravelを使ってアプリを作っているので、テストもLaravelのものを使うのですが、 いわゆるhttpリクエスト単位でテストを行い、リクエストに対してどのようなレスポンスが返ってきているかをテストしています。

Laravelでテストコードを書くためのチュートリアル

ただ、「ユニットテスト」っていうと、一般的にはクラスごとのテストのことで、自分のやり方って実は邪道なのかしら？って思ってました。 で、思い切ってt-wadaさんに聞いてみたのですが、驚いたことにt-wadaさんもhttpリクエストごとのテストをしているとのこと。 むしろ、処理をtraitに移すとか、traitをやめるとか、クラス分割するとか、影響の大きなリファクタリングもできるので、 リクエストごとのテストは良いのではないかとのことでした。

なんというか、「クラスごとのテストをしなければならない」というのはイマドキではかなり原理主義的になっているとのことで、 Ruby on Railsの作者DHHがこれに対して「TDD is dead. Long live testing」と述べたようです。 その辺の経緯がt-wadaさんの訳書「テスト駆動開発」 に書いてありますので、興味を持った人は買ってみてもいいんじゃないかな！

長くなりそうなので、ここまでにしますが、自分の持っていた漠然とした不安が解消されたように思います。

# まとめ
やはりその道を極めたプロは違うな！って思います。私自身もTDDを完全には導入していなくとも、テストは書いていますし、テストに関してはいくつか記事を書いています。 しかし、自分の持っていたテストへの考えは、ネットから得た知識に独自の体験を混ぜ込んだものであり、学術的な根拠に乏しいものが多かったのでした。 今回のワークショップで改めてテストやTDDの考え方や目的について捉え直せたと思います。

今回はこんなところです。

[/markdown]