対象とする人
- TDDの概要は知ってるけどやったことがないという方
- 一人でTDDにチャレンジするしかない方
- t_wadaさんを信奉しているけど普段から関わることができない方
この資料でのゴール
- TDDってこういう感じなのね！という感覚を掴んで、一人でもTDDが練習できるようになること
ことの始まり
そもそもエアペアプロに私が行き着いたきっかけはgolangで開発する案件に携わったことでした。
（どんな案件か、ということは本題には直接的に関係ないのと本記事の内容に影響がないのでここでは省略させていただきます）
ご存知の方も多いとは思いますが、golangでは言語自体でテストが手厚くsupportされており、また所感ですがエラー時の言語標準で出してくれる標準出力の内容もとてもわかり易いです。
https://golang.org/pkg/testing/
更に、様々なgolang製のOSSを見てもテストコードはどれも完備されており、参考となるテストコードに溢れています。
これはとどのつまり「golangで開発するならレガシー（テストのない）コードなんてナンセンスだよね？」というgolangからの暗黙的なあれなのでしょう。
TDDの知識はあれどやったことはない私ではありますが、折角の機会なのでこれを期にTDDで開発をしてみることにしました。
TDDやったことない人が勢いで進めたら速攻で座礁した
「よし、やるぞ！」となった時、まずはどこから手をつけるでしょうか？
事前に要件や仕様が明確に文章化されているなどお膳立てされていればよいですが、多くの方は「どういうことができるものをつくりたいんだっけ？」とまずはゴールについて考えるかと思います。
当たり前ですがTDD云々の前に、何かを「作る/進める」時には
「できてほしいこと」がちゃんと定義されてることが大事ですよね。
もし「ゴールが決まってない」という方がいれば、最初に定義をしましょう。
ゴールを自分で決める権限がなくて決められない、という方は決める権限を持つ方に決めてもらうかゴールを作って提案して早々に決めましょう。
そして「ゴールがある」という状態になってから改めて、TDDの進め方を思い出してみます。
- Red （失敗させて）
- Green（成功するように直して）
- Refactoring（キレイにする）
この３ステップでしたね。
ゴールも決まってるし、進め方もシンプル。
何も問題なさそうに見えるし、では早速TDDの進め方でやってみよう！
...と言ったところで、みなさんはできましたか？
私はできませんでした。
具体的にどこからできなかったというと
「Redを発生させる前段階でどうすればいいか」
という段階で止まってしまいました。
TDDのサイクルが始まってすらいない序盤も序盤です。
「なんでそんなところで止まるの？」
「とりあえず失敗させればいいんでしょ？」
という方もいると思いますが、どうやその時の私には「具体的な分割イメージ」がついていなかったようです。
こちらについて少し掘り下げていきます。
テストケースという最初の壁
なぜ「そもそもRedを発生させる前段階でどうすればいいか」で止まってしまったのでしょうか？
実際の思考順に沿ってまとめていきます。
TDDのサイクル通りに開発するに当たってまず用意しようとしたものは「テストコード」でした。
「テストコード」が用意できればあとは「Red →Green →Refactoring」をいい感じにできるはずだと思ってそこから手を付けようとしてました。
が、そこで「テストコード」を作ろうした時に手が止ります。
それは何故かというと、開発ありきの単体テストに慣れてしまっていたためか、最初にテストケースを作るという重要な作業がすっかり頭の中から抜けてしまっていたためでした。
テストケースがなければ、テストコードが書けるはずもないですし、どんなことを達成させるためのテストコードなのかもわかりませんね。
そんな当たり前の事実を思い出し、いざ「テストケースを作ろう！」となった時にまたまた手が止まってしまいました。
それはテストコードで叶えるべき「テストケースの粒度」をどうすればいいのかわからなかったからでした。
これは不健康なテストをやっていたことへの気付きでもありました。
なぜならば、「ゴールを実現するための機能を実装しているという安心を得るために」テストをやっているのに、実装したものを主体としてテストを考えるとテストがそれを満たしているかどうかは作った実装に左右されてしまう状態になってしまっていたからです。
こんな状態ではTDDはできませんでした。
そこで「エアペアプロ」ですよ
そんな私が出会ったのが有名なt_wadaさんのライブコーディングの動画でした。
（classmethodさんのブログの中にありました）
https://dev.classmethod.jp/study_meeting/read/what-tdd/
この動画を見ることで「なるほど、こんな感じに進めればいいんだ！」と感動しましたが、実際に一人で進めてみると意外と難しい...
そこで気づきました。
わい「せや、t_wadaさんの動画見ながらエアでペアプロをすればええんや！！」
t_wadaさんの動画を再生しながら、自分もコーディングをして対応していくという方法に打ってでました。
そうすると、今まで詰まっていた進め方や疑問点が嘘のようにスムーズに進めれるようになりました！
エアペアプロのやりかた
- 自分の題材となる受入れ要件を準備
- t_wadaさんの動画を用意
- 再生します
- t_wadaさんの進行に合わせてTDDのサイクルを進めていきます
これだけでできます！
いい点
• なんども何度も繰り返し見ながら進められます
• TODOを作る時、どんな項目を作ればいいか迷ったこともあったけどこれなら悩まみませｂ！
• 実際にTDDサイクル回していく時、大きなレベルで作ろうとしてしまったところも参考がいると軌道修正できます！
まとめ
- エアペアプロは一人でもはじめられる
- t_wadaさんは神