TDDBC Sendai X に参加した TDD 初心者の感想 → 最初の一歩を踏み出せて楽しかった

2021/3/6 に TDD (Test Driven Development; テスト駆動開発) の初心者ながら TDDBC に参加してきたので、その感想や振り返りを残しておこうと思います。
参加を悩んでる人の参考の１つになると嬉しいです。
（TDD を知っているけど TDDBC は知らない同僚に紹介するつもりで書きます）

忙しい人用まとめ

  • 初めてでも TDD は楽しかった。安心してリファクタリングできることの素晴らしさ。
  • TDDBC は初心者でも安心して参加してOK。大事なのはスキルよりやる気・行動力。（スキルも最低限は必要だけど）
  • 経験豊富な TA に質問できる環境が最高。明確な答えがない質問にも、個々の意見が聞けて勉強になった。
  • 最高なイベントを運営する有志・コミュニティには感謝しかない。

TDDBCとは

TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。

各地のコミュニティの方々が中心となって、全国各地で行われています。
TDD Boot Camp(TDDBD) - TDDBC

TDDBC Sendai X では TDD のサイクルを体験するためのお題が出されて、それを参加者のペアで解いていく（コードとそのテストを実装していく）形式で実習を行いました。

きっかけ

  • TDDという開発の作法があるのはもともと知っていて、2020年に開催された TDDBC 2020 Online の基調講演もリアルタイムで観ていた。
  • 自動テストを社内で当たり前にしたいと思いつつも、自分に普及・推進するためのスキルや経験が無いので、初めの一歩として参加したいと思っていた。 *1
  • 上記のように思っていたところに Twitter (Connpassからのメールだったかも)で TDDBC Sendai がオンライン開催されると知ったので、（スキル的に不安ながらも）参加しようと決めた。

私のスペック

どんな経験・スキルで参加したのかという参考情報として。

  • 都内某 SIer のソフトウェア開発者
    • 最新技術を追うというよりは、枯れた技術・社内蓄積ノウハウを使って仕事をしてきた
  • Java は社会人になってから触れてかれこれ5年くらい。
  • JUnit は書いたことがあるけど、プロジェクトによってはほとんど使わなかったので「JUnit でテスト書けます」とは言えないレベル。

TDDBC Sendai X の流れと感想

参加申込〜準備会前

私の参加から準備会までの流れは以下の4ステップです。

  1. Connpassのイベントページで「募集開始リマインドの受け取り登録」(2/17)
  2. 募集開始の通知後、Peatix のイベントページから参加申込（一般参加費 1,000 円）(2/22　※申込開始は2/21 12:00)
  3. TDDBC Sendai X の Discord への参加(2/25)
  4. 事前アンケートへの回答(2/26)

1.の connpass での登録はあくまでリマインドの受け取り登録なので、必須ではなかったと思います。
4.の事前アンケートでは、当日行うペアプログラミングのペア決めの参考情報として、TDDの経験有無や実習希望言語とその経験について回答しました。
実習言語はJava / C# / Go / JS / その他 ... などからの選択式、経験については自由記述でした。

準備会（2/27）

参加申込時点で、TDDBC本番の１週間前に開催される準備会への参加は必須と明記されていました。
準備会は2/27(土)10:00から Discord 内でのオンライン開催。
やったことは、以下の通りです。

  • 実習ペアの発表など各種事務連絡や Code of Conduct の周知
  • 運営・TA の方によるペアプログラミングのデモ
  • 実習にあたっての質疑応答
  • 基調講演鑑賞会の日程決め
  • 同じ言語で実習をする参加者・TA の方々との簡単な自己紹介
  • ペアに分かれて実習環境構築・動作確認
    • Discord でお互い画面共有をしながら使用する IDE や Junit のバージョンの確認
      • IDE は Eclipse。慣れてはいないものの、勉強も兼ねて JUnit は 5 を使用することに。
      • Java は 11 にしましたが、特に11ならでは、なコードは書きませんでした。
    • Github の実習用サンプルリポジトリを clone して、 push/pull の練習・確認*2

基調講演鑑賞会（2/28）

これまでの TDDBC Sendai では当日の午前に基調講演の聴講 → 午後に実習の流れだったようですが、今回はより多くの実習時間を取るために、事前に各自で基調講演の動画を見ておくことになっていました。
その動画をみんなで見ましょう、というのが鑑賞会の位置付けです。（任意参加）
ちゃんと覚えていませんが、運営・TA・参加者の半分以上は参加していた印象です。

動画の鑑賞は「せーの」で再生開始して、同時並行で Discord のテキストチャットで質疑応答する形でした。

基調講演の内容はもちろん（良い意味で）シビれるものでしたが、それ以上にすごかったのが講演者の t_wada さんはじめ TA の方々によるリアルタイム解説・質疑応答です。
講演中に言及された概念やポイントにすかさず解説や参考文献の紹介が入ってくるんです。
また、参加者から（ときどき TA から確信犯的に）出てくる質問にも素早く明快な回答が返ってきます。
そしてその質問も実践を見据えてるからこそ、という感じで他の方の質問も「確かに自分も知りたい！」と思うものばかり。

なんだこの豪華すぎる鑑賞会は・・・（褒め言葉）

事前練習（3/3）

基調講演鑑賞会で色々と分かった気分にはなったものの、やはりペアプロは初めてだし当日いきなりは不安・・・
ということでペアの方と相談し、事前に 1 度ペアプロデモと同じお題でペアプロ・TDD の練習をすることにしました。

準備会と同様、Discord 上で画面共有 / ボイスチャンネルを繋ぎながらの練習です。
平日の仕事の後に 2 時間程度。準備 30 分、練習 30 分、あとの 1 時間は振り返りと雑談みたいな感じでした。

事前練習しての気付き

  • 基調講演にならって、まず TODO リスト作ってみたものの、結局コードを書くタイミングで手が止まった。
    • テスト容易性の高い設計イメージがついてなかった。（残酷な瞬間）
    • あと「TDD の正解」のようなものを意識しすぎてコードを書くのを躊躇していたと思う。
  • 準備会のペアプロデモを真似て 7 分区切りでドライバー / ナビゲーターを交代したが短く感じた。
    • ある程度まとまったところまでやりきらないと、進め方が良かったのか悪かったのかの判断もできないまま交代になってしまう。
    • でもこれはペアプロ / TDD 初めて、かつ人となりもまだ掴めていないペアだったからなのかも。
  • ↑のようなことに事前にハマった / 気付けたのは収穫だった。

練習後の感想ツイート。

この後、TDD 自体の進め方にも少し慣れておきたいなと思い、練習に使ったお題を少しだけ一人で進めてみたり、Kent Beck の TDD 本を頭から 9 章くらいまで読んでみたりしました。

TDDBC 当日（3/6）

当日の流れは、以下の通りです。

  • 10:00 に Discord に集合 → 各種連絡
  • 基調講演や TDD についての質疑応答
  • お題の説明（最初の 1 つのみ）
    • 当日はお題が解けたペアに順次お題が開示されていく形式でした。
  • 実習 / コードレビュー / 質疑応答を交互に繰り返し
    • 45 分の TDD 実習 * 4 回
      • 各ペアに最低 1 人の TA がついて適宜アドバイスや質問対応をする形式でした（贅沢！）
    • 30 分のコードレビュー * 3 回 + おかわり 1 回
      • コードレビューの場では他言語のペアとも一緒になりましたが、知らない言語のレビューを見るのも勉強になりました。
    • 質疑応答 * 2 回
  • ふりかえり
  • クロージング
  • 懇親会

実際には実習 → 質疑応答 → 実習 → コードレビュー → 実習 → ... のようにして実習の合間に質疑応答やコードレビューが入った形でした。

当日のふりかえり

気を付けていたこと

実習をするときに気を付けていたのは、「お題をガンガン進めるよりも、TDD / ペアプロの型を学ぶことを重視」です。
TDD / ペアプロ / Gitの操作がおぼつかない状態だったので、ペアのいる TDDBC だからこそ学べることに注力しようという考えです。

結果的にお題 1 を完成させたところで時間切れとなってしまいましたが、

  • 常に「なぜこの作業をやるのか」を言語化しながらコーディングできた
  • ペアで作業方針の意思統一をしながら進められた
  • 「自分が気付かなかったことにペアが気付く」「知らなかった IDE の機能 / ショートカットを共有できる」などペアプロだからこその良さを体感できた
  • RED → GREEN → REFACTORING のサイクルを楽しく思えた

ので、初心者として学べたものは十分あったと思っています。

「手を動かす」と「会話する」のバランス

とは言いつつも、手を動かしている時間よりも会話している時間の方が長くなってしまったのは、今後の改善点だと感じました。
今回で言えば、リファクタリング済みのコードが増えてきたタイミング（実習 2 〜 3 巡目あたり？）から、「方針の共有重視」→「実装の推進重視」にギアを変えて、TDD の歩幅を少し大きくしても良かったのかもしれません。

印象に残ったレビュー、質疑応答

特に明記ない場合は自分のからの質問です。

  • 過去のテストコード資産にテストケースの重複を見つけたら、重複を減らす手順はあるのか？（鑑賞会質疑応答）
    • xUnit Test Patterns: Refactoring Test Code 参照
    • テストコードの削除はプログラミングの延長線上でできる。
    • 対してテストケースの削除は難しい。消したテストケースが他のテストケースでカバーされていることの担保が、注意深くプロダクトコード / テストコードを読むことでしかできないから。
    • テストケースは秘伝のタレ的なものもあるので、意図が分からない時は削除しないのが良い。
    • なのでテストケースを書く / レビューする時に意図を表現できているかどうか意識したい。
    • また、意図を聞ける人がいるうちに聞いておきたい。
  • テストケースからは関心がないが、実行上必要なパラメータをどう扱うか？（Ruby ペアのレビューでの議論。自分は聞いてただけ）
    • 固定値にするにしろ、ランダムにするにしろ「関心がない」ことが分かるように書く
    • （他にももっと色々いい指摘があった気がするけどメモしてなくて覚えてない・・・）
  • TODO "リスト"と TODO "コメント"の使い分けはどうしてる？（コードレビューにて）
    • 人によって TODO（あとで直す、など） を書く場所は「コードのみ」「TODO リストのみ」「両方」で分かれる
    • 「両方」の方から教えていただいた例
      • 「遠い未来まで残す」→コード内、「比較的近いタイムスコープ」→TODO リスト
      • その時近い場所（コード / TODO リスト）に書きがち
      • TODO リストには仕様上必要な機能のTODOを、コードの関心事のTODOはコードに
      • （参考）https://twitter.com/t_wada/status/904916106153828352
  • 変数名やメソッド名に適切な名前を思いつかなかった時どうしてる？（ふりかえりにて）
    • 変更しやすければ立ち止まらず進む（そうでなければ立ち止まって考える）
    • 長くても全ての情報を詰め込んだ名前にする
    • 名前が浮かぶまで泳がせる
    • 違和感のある名前をつける
    • 業務 / プロダクトに詳しい人に相談する

最後に

準備会や鑑賞会のときから感じていたのは、運営・TA の皆さんは、参加者の不安を払拭して学びを最大化することに本当に尽力されている、ということでした。
イベントから得られる学び・体験からすると「もっとお金取れるでしょう」と思わざるを得ないレベルです。

これは、TDD の普及と業界全体のレベルアップを目的とした活動に賛同する方が多いからこそなんだと思います。（個人の意見）
本当に運営・TA の方々には感謝しかありません。

と同時に、恩を貰っただけにならず、自分も職場で TDD を布教したり、おもむろにペアプロしてみたり、勇気を出して TA などの形でコミュニティに貢献したりしていきたいです。

まずは

  • テスト駆動開発の写経や、TDDBC の過去のお題を解く。
  • 職場で TDD を実践してみる。

あたりから始めて実力を伸ばして行こうと思います。

*1:これについては自動テストの目的が品質保証なのか開発の加速なのか混同していた部分があるので、両者に重なる部分はあるけど同一視してはいけない、というのが参加後の今の考え。

*2:終わりきらなかったので、後述の基調講演鑑賞会の後に続きをやりました