「テスト駆動開発(TDD)オンライン勉強会」にオンライン参加してきました。

勉強会 オンライン TDD

はじめに

久しぶりの更新です。
5/4(月)、テスト駆動開発(TDD)オンライン勉強会 #1 「ライブコーディングで体感するTDD基礎」にオンライン参加してきました。

ddd-community-jp.connpass.com

参加動機とか

今僕が携わってるプロジェクトでは、コードを追加した際はそのユニットテスト用コードも添えてPRを出す、という原則で開発が進められてます。
が、具体的な進め方まで明示されたわけではないので、その辺は各人任せな感じです。
僕自身も、コードを作り切ってからテストを書くのがメインで、その段階になってテストのしづらい(=切り出すべき)箇所に気づく…といった苦い経験をしてきました。
また、先述した原則もレビューなどで徹底されているわけではなく、期日に間に合わないなどで省略したり、メインコードを修正してもテストコードを修正し忘れたりといったことが頻発してます。
誰かが気づいても修正コストの大きさから手を出しづらく修正されないまま、徐々にユニットテストがきちんと回されなくなり・・・結果、今となってはユニットテストが形骸化している感が否めません。

僕自身も不慣れだったので、進め方の雛形をある程度決めておくべきだったなぁと反省してます。 で、次はそうしたいという思いと、「そもそもどう実装を進めるとメリットを得やすいのか」というあたりが気になっていました。

そんな中、「ライブコーディングを含むTDDのオンライン勉強会が開催される」という情報を得たので、早速申し込みました。
新型コロナは早く収束して欲しいですが、その影響でオンライン開催の勉強会が増え、大都会岡山在住の僕でも日本全国あちこちの勉強会に参加できるようになったのは嬉しいところです。

いざ勉強会

勉強会はYouTube Liveにて、松岡さん(@little_hand_s)による講義形式で行われました。 TDD勉強会の様子

初学者でもわかりやすいFizzBuzzコードの作成を題材に、レッド・グリーン・リファクタリングの3ステップを踏みながら徐々にメインコードとテストコードを作っていく様子を実演されていました。
入力値が1の場合にテストが転ぶところ(レッド)からスタートし、

  1. 入力値1の時のテストが通るよう、メインコードを書く (グリーン)
  2. 入力値2の時のテストを書く(まだ対応するメインコードがないので転ぶ) (レッド)
  3. 入力値2の時のテストが通るよう、メインコードを書く (グリーン)
  4. 入力値3の時のテストを書く(まだ対応するメインコードがないので転ぶ) (レッド) ・・・

といった感じ。
（あくまでもTDDの進め方を掴んでもらうための刻み方なので、1ステップのサイズはケースバイケースのようです）
コードを追加後すぐに失敗がわかるので、原因箇所の特定・修正がしやすいことが実装の様子からも分かりました。

なお、レッドとグリーンの繰り返しでは、テストを通すことを目的としているので、コードが多少汚いのは気にしなくて良いようです。ある程度出来たところで行うリファクタリングでその辺は綺麗にします。
2つ目のライブコーディング(peingへ届いた質問をGitHubのissueに登録する際の本文作成プログラム)では、レッド・グリーンでは文字列連結でゴリゴリに戻り値を作成していましたが、リファクタリングでそこをテンプレート構文に直して読みやすくしていました。

途中のYouTube視聴者コメントで出ていましたが、TDDで進めていると仕様の考慮漏れに気づけるタイミングが多くある、というメリットもあるようですね。

また、スライドでは、「自動テスト」と「TDD」の違いについても言及されてました。
以下自分メモ

  • 自動テスト
    • テストコードを積み上げて、回帰テストのコストを下げ、品質維持を容易に
    • リファクタリングしやすくなるので、コード品質も上がる
    • テストコードに想定される挙動が記述される（=仕様がある程度テストからわかる）
    • ドキュメントと違って、古くならない（ドキュメントは仕様変更時に修正漏れしたり・・・）
  • TDD
    • メインコードとテストコードがセットで増えていくので、十分なテストが書かれやすい
    • テストを書こうとした段階で、テストを書きにくい設計であることに気づける
      • 最初からクラスの呼び出しを意識できるので、自然と高凝集・低結合なクラスを作れる
  • TDDは自動テストを含むが、その逆は必須ではない（自動テストを進める手法自体はTDDでなくても良い）
  • Clean(綺麗なコード)とWorks(きちんと動作するコード)は自動テストだけでも頑張ればできるが、TDDはその実現を加速させる

（こうしてみると、今携わってるプロジェクトは「自称：自動テスト」なんだなぁと。本当に反省です・・・）

参加してみて

TDDはワード程度にしか知らなかったので、進め方などの思想を知ることができたのは大きいです。ライブコーディングがあるのも理解の助けになりますね。
まずは自分担当分の開発で取り入れて行きたいと思います。手応えあれば、チーム全体としても取り入れて行きたいところです。

また、オンライン勉強会初参加でしたが、何かしながらでも話は聞けるのは良いですね。
ワイヤレスヘッドホンで聴講していたので、そのままお手洗いに行っても、軽く家事してても聞いてられます。
もし聞き逃しても、シークバーを戻せば聞きなおせます。
YouTube Liveだと、他人のコメントが参考になる、理解の助けになるというあたりもメリットです。
（TDDで有名？なサバンナの人こと和田さん(@t_wada)も参加されており、コメントが非常に参考になりました）
岡山界隈だとハッシュタグつきでTwitterにツイートする文化が強い印象ですが、それに近いものを感じました。

逆に、リアル勉強会のような「会場の空気」が形成されないので、自分が登壇者だとしたらその辺り少し不安になるかなと感じました。ボケがスベった時のダメージは抑えられるかも