TDDBC 2020 Online #1参加レポート
8/1(土)に開催された「TDD Boot Camp 2020 Online #1」に参加しました。
TDD Boot Campは10年以上続いているテスト駆動開発を学ぶイベントで今回初めてオンライン形式で開催されたそうです。参加者同士でペアプログラミングしながらTDDを体感できるハンズオン形式というのも特徴だと思います。
私自身はTDDBC自体も初めて参加しましたし、オンライン形式のハンズオンイベントも初めてでした。
オープニング
いよいよTDDBC開幕です！
まずはじめに全員で本日の目標を表明(assert)しました。このassertをGreenにすることを１日通して目指します。自分は以下のような目標を表明しました。
TDDのリズムを体感する！ペアプロで喋り続ける！
基調講演/ライブコーディング
基調講演/ライブコーディングの中で自分が印象に残っている部分を備忘の意味を込めてまとめていきます。
基調講演：スタート
https://youtu.be/Q-FJ3XmFlT8?t=1147
冒頭は「テスト駆動開発とは何か」を原点に立ち返って説明されています。
参考図書；テスト駆動開発
テスト駆動開発での設計
アジャイルプログラミング/テスト駆動開発では「設計をしない」という大きな誤解がされることが多いですが、本来は「常に設計し続ける」ものであることが指摘されています。
では設計書がないのにどうやって設計をしているのかというと、その時アタマの中にある設計/考えを紙やテキストファイルにダンプ/退避させて書き出しておきます。
今回はToDoリストを退避場所として使うのが紹介されています。
ToDoリストの優先順位
作成したToDoリストのどのタスクから手をつけるのかについて解説されています。
タスクを「テスト容易性：高 & 重要度：高」と「テスト容易性：低 & 重要度：低 」の2つに分けることができるというのは驚きでした。
なぜか暗黙的に重要度が高くなるとテスト容易性も下がると偏見を持っていたことに気づきました。
ライブコーディング：スタート
FizzBuzz問題を例にライブコーディングが行われました。
FizzBuzz問題のToDoリストの作成
この基調講演/ライブコーディングの中で特に印象に残っている箇所の1つです。
ToDoリスト作成時に、テスト容易かつ重要なタスクに振り分けることが内部品質を上げるためには必須であると感じました。
今まで自分がテスト駆動開発をうまく実践できていなかったのは、このタスクを振り分けるスキルが欠けていたのだと痛感しました。
スタート地点を確認するためのRed
まず環境が正しく構築できているかを確認することが重要であると指摘されています。
新しい手法を学ぶとついつい勇み足になりがちですが、ちゃんと足場を固めることが重要だということがわかりました。
テストコードを書く順序
テストコードを "assertionから/実行順序と逆から" 書くことによって以下のメリットがあることがわかりました。
- テストの粒度/抽象度が正しいかを最初にチェックできる
- 実装する機能を使う側/呼び出す側の視点から、実装前に、見ることで使いやすさを実現できる
テストコードのテスト
仮実装はテストコードにバグがなく、意図したテストが正しく実行されていることを確認する重要なステップであることを認識できました。
今まであまり意識せず最短のGreenを目指していましたが、はじめにGreenになった時点でテストが意図した通りに動いているかの確認は、忘れずに心に留めておかなければと思いました。
アサーションルーレット
自分もよくテストメソッドに複数のassertionを書いてしまうのですが、複数のassertionはテストの可視性が下がる大きなデメリットがあることを理解して書かなければと強く感じました。参加者のコメントでもよくやってしまうと多く書かれていたのが印象的でした。
状況がコントロールできる
意図した通りに結果が返ってくる状態が、たとえRedになっていても、ベストな状態だとわかりました。そのような時は、ステップを大股にして「明白な実装」をすることが可能になります。
テストの構造化とリファクタリング
この基調講演/ライブコーディングの中で特に印象に残っているもう1つの箇所です。 テスト駆動開発の文脈で言われる「テストコードは動作する仕様書であるべき」とはこの事かとハッとしました。また前半で触れられていた「母語でテストコードを書くことの重要性」もこの観点から納得しました。
ライブコーディングを見ることでテスト駆動開発のイメージが大きく変わりました。
冒頭で紹介されていた「テスト駆動開発」を読んだことがありますが、実装を行う前のToDoリストへのタスク分解の方法と実装を行なった後のテストの構造化の方法をより理解できたと思います。
ペアプログラミング - その１
午後からはペアを組んでテスト駆動開発を体得していきます。基調講演を聞いて得たイメージがある状態で手を動かしながら確認できたのがよかったです。
問題は以下の「整数の閉区間」をペアプログラミングで実装していきました。
問題文をもとに、まずは句点を目印にタスクに分解していきそこからなるべく表現が対称になるよう意識してToDoリストを作成しました。ToDoリスト作成時にハマった点として、急に具体的な設計を議論してしまいました。
実装を始めていくとはじめのToDoリストでは具体的なテストが書けないため、その都度より具体的なテストの例を考えToDoリストを整理しながら実装を進めていきました。
中間レビュー
同じ言語(Javaで参加)の単位でコードレビューを行いました。ペアで議論したことや考えたことなどを画面共有しながら発表しました。 レビュー時に印象的だったのはToDoリストのどの項目から攻略していったのかがペアごとに違っていたことです。
ペアプログラミング - その２
ペアプロ後半戦のスタートです。
前半戦と比べると徐々にリズムよく実装できたのを感じました。特にToDoリストを抽象⇄具体を行き来しながら整理していくと次に書くべきテストが機械的に決まっていくようになるのが書いていて興奮しました。
また通るはずのないテストがGreenになってしまった時は、一度立ち止まって意図した通りにRedになるのを確認しながら実装することで安心しながら実装できるのを実感できました。
ペアプログラミングしているとあっという間に時間が過ぎていき、気づけば終了の時間になっていました。
成果レビュー
最後は言語も混ぜこぜで１日のコードレビューを行いました。以下のコメントが特に印象的でした。
- テストを足すかどうか迷ったらまず書いてみる → テストを追加するコストは少ないため迷うくらいなら書いてしまった方が早い
- 不等号の向きが1箇所違うがそれは意図しているのか？
→実装者以外は他と対称でない部分があると何か意図があるのではないかと感じる
→エラー処理の部分など強調したい部分はあえて対称性を破ることで読み手に注意を促すことができる - テストコードの書式も統一してコメントなどに書いておくと理解容易性が向上する
おわりに
初めて参加するイベントかつオンラインでのペアプログラミングという事で最初は緊張しながら参加したのですが、あっという間に1日が過ぎていました。学ぶ事が多かったことはもちろんの事とにかく楽しかったです。
イベント終了後はとにかくテストコードが書きたくなりテスト駆動開発で実装したくなりました。
基調講演をして頂いた和田さん、運営やTAをして頂いたみなさまに心からお礼を申し上げます。
とても刺激的な1日でした！
