TDD Boot Campについて
TDD(テスト駆動開発)を実際に手を動かして体得するイベントです！
TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。
これまで10年以上に渡り、日本各地でそれぞれの地域のコミュニティにより運営されてきました。
詳しくは以下ページを参照ください。
TDD Boot Camp 2020 Online #1
2020/8/1(土)が本番ですが、今日は本番にすぐテストを書き始めるための準備日でした。
本記事では準備日に参加しての気づきや学びを書きます。ほとんどがペアプロのポイントの話です。
参加の経緯
僕はScrum MasterとしてTDDをチームに導入してみたいという意気込みで参加いたしました。
言語はSwiftで参加。
準備日にやったこと
音声、テキスト、画面共有のツールはDiscordでした。
1. イントロ
2. ペアプロのデモ
3. 開発環境準備
1. イントロ
挨拶やイベント、Discordの説明がありました。
Discordでのコメント量
スライドが見えるか、音声が聞こえるかに関してのDiscordへのスタンプやコメントの量がすごく多い！
業務でも今聞こえてる？みたいな状況はありますが、それとは反対の状況でした。
常に何か流れている感じ。
これだと発表側もやりやすいでしょうし、また参加者の集中や主体性が感じられる場面でした。
雰囲気作りができて、スタンプでもなんでも1つ投稿して反応するぞという気持ちになりました。
2. ペアプロデモ
TDDのペアプロデモがありました。
時間は30分でしたが、参考にすることが多くて一瞬に感じました！
人のペアプロを見るの面白いですね。
ドライバとナビゲータの役割
ペアプロで、ドライバはコードを書く人、ナビゲータはコードを書かずにドライバをサポートしている人です。
ドライバがやること
- コードを書く
- 考える
ナビゲータがやること
- 時間計る
- ドライバが困っていることをwebなどで調べる
- 考える
ドライバは思考を口に出しながらコードを書く
コミュニケーションのため、 ドライバは考えていることを口に出しながらコーディングします。
ペアプロデモでは常になんらかの会話が行われていました。
ドライバもナビゲータも話し続けるのが大事です。
運転のメタファー
ドライバーは基本調べ物はしない感じですか？という質問があり、
ナビゲータが調べ物をすることが多いとの回答。
ペアプロを車の運転に例える話が出て、ドライバは運転手、ナビゲータは助手席の地図をみている人。地図を見ながら運転すると事故するよ！っていうメタファです。
僕の勘違いで、「ドライバはナビゲータのいうことに従う」考え方を持っていましたが、ドライバもナビゲータも考える事が大事です。
参考記事(ペアプロすると眠くなる？)
役割交代の仕方
ドライバとナビゲータの交代のタイミングは以下２通り。
- 時間で区切る方法
- きりの良いところで交代する方法
交代のタイミングはペアで考えれば良い。
最初は時間を短くとるとリズムが掴める
デモでは確か5分交代だったと思います。それでも良い感じで進んでいましたね。
ペアプロ始めたばかりでは固定時間での交代(7、8分くらい)がよく、短めの方がペアプロのリズムを使いやすいとのことです。
頻繁な交代で混乱することもあるので、その時は時間を長くするなど柔軟に対応すると良いとのこと。
テストケースの関数名は日本語
テストのタイトルを見てすぐにわかるのは良いため。
状況把握がすぐできるため、ストレスを軽減できる。
ペアプロはスキルが近いことを前提としていない
ナレッジトランスファー(知識を教える)のためにペアプロをすることも多いです。
僕の所属チームでもナレッジトランスファーの目的でペアプロを積極的に行っています。
しかし、ビギナーどうしのペアプロは唯一機能しないため注意とのこと。
うちのチームはこれを現在やっているためやや注意したいところ、、、
ペアプロの狙い
先ほどナレッジトランスファーの話がありましたが、それ以外にペアプロには以下の狙いがあります。
- ダブルチェックによる品質向上
- リアルタイムレビュー(常にレビューされた状態のコード)
- 速度向上
- 2人でやることで良いアイディアを出す。
ペアプロのパターン
- gitにpush/pullするパターン
- Live shareのパターン
- 一人だけ環境が整っていれば行けるのが強み
- ブラウザのIDEを使うパターン
テスト通った後はコードの匂いの議論をする
デモでは、テストがGreenになって終了ではなかったです。「ぱっと見わかりにくい」ところを潰していました。
-
条件式が複雑だよねと変数切り出し -
変数名もっとわかりやすくならないかと考えリファクタリング -
テストコード名、直感的にわかる日本語にならないかと名前編集したり
テストが通り、仕様を満たせていても、リファクタリングの議論が起きていて素晴らしかったです。
こういうのは言い難かったり、タスクを早く終わらせるためにすぐにコミットしてしまったりすることがありますが、その時点で完璧なコードを目指すのは大事な心構えで、理想的と感じました。
「違和感」を口に出すこと、出せる環境にするのは大事です！
privateのメソッドはテストをしない
前に受けた研修で、レガシーコードからの脱却の著者のDavid Bernsteinさんもおっしゃていました。
公開されている振る舞いをテストするということです。
参考:プライベートメソッドのテストは書かないもの？
参考: Should I Test Private Methods?
命名が決まらない時はとりあえず書く
決まらない時はとりあえず書いてみる。
違和感があればリファクタリングする。
あえて長い名前にしたりして、後から気付けるようにする方法もあります。
3.開発環境準備
Swiftチームに分かれて本番の準備やペアプロの練習をしました。
僕のペアはiOS歴10年の猛者！ 本番でも足を引っ張りすぎないように頑張ります。
準備中も色々教えていただき、助かりました。
主にやったこと
- ドライバー交代時間を10分と決め、問題があれば修正することにした。
- Xcodeの設定
- 画面共有テスト
- Helpの時のメンションのテスト
- pushしてpullしたり
- 足し算のテストコードを書いてみる
- github落ちた時などの対策を考える
終わりに
運営の皆様の努力のおかげで実り多い1日となり本当に感謝です！
本番も楽しみます！