[社内イベント] 和田卓人さんによるテスト駆動開発ワークショップの参加レポート [札幌編]

札幌だより

#イベント

#TDD

#イベントレポート

小室啓

2017.08.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

2017/08/01クラスメソッド秋葉原オフィスにて、t-wadaさんこと和田卓人さんによるTDDワークショップが開催されました！

先日、Nulabさんで開催されていたTDDセミナーを見て羨ましいなーと思っていたところ、クラスメソッドでも開催してくれる運びとなりました。ありがとうございます！

ワークショップ開催の主会場は秋葉原本社でしたが、リモートで札幌、大阪をつなぎ地方のメンバーも参加することが出来ました。東京では一番大きな会議室が満員になるほどのメンバーが参加し、地方では札幌と大阪でペアを組んでペアワークに参加するメンバーもいたり、とても盛況でした。小室からは地方オフィスからの参加ということで札幌の様子を中心にレポートします。

札幌オフィスはモバイルアプリサービス部2名、製品開発部のメンバー2名の合計4名での参加でした。会議室にたくさんの人達が入っている東京とは異なり、こちらは４名の参加者に一番大きな会議室ということで比較的ゆったり参加することができました。

前半は和田卓人さんによるTDD再入門

前半は座学という形で５０分間みっちりと、基本的な知識を改めてお話してもらいました。今まで何となくぼんやりと理解していたテスト駆動開発の内容でしたが、改めて中心となる考えやプロセスについて確認することができました。 ^*1

テスト駆動開発の本質

テスト駆動開発のゴールは「動作するきれいなコード」これを目指してテストコードを中心に機能を開発していくプロセスです。必要最低限の実装コードを作成し、それをリファクタリングして改善していくことでコードの品質を保つことができるようです。

テスト駆動では次のプロセスを何度も回します。

目標を考える
目標を示すテストを書く
実行して失敗させる(REDの状態)
目的のコードを書く(コードの汚さは関係なし)
テストを成功させる(GREENの状態)
テストが通るまでリファクタリングを行う

仕様に対する問題（というか機能）を小さく分割統治して、1つずつ片付けて行くのが正しいとのこと。

例えばテストの対象が10項目あっても、1項目ずつテストと機能を作成していきます。一つずつ倒していくのが基本的なセオリー。ただ、リファクタリングのフェーズでは基本的に終わりがないため、どこで切り上げて良いかはさじ加減のようです。いつまでもやっていても仕方がないのである程度で次のサイクルを回す必要があるとのこと。このあたりは、自分はとても苦手なところです。

このリファクタリングのプロセスは外的な要因によって、様々な阻害を受けます。スケジュールや動作するからもういいじゃないかという思いなど、こういった要因によってリファクタリングのプロセスが短くなっていくと、コードの品質が低いものへなっていきます。これらを避けるために、

リファクタリングのプロセスは大ごとにしない
小さく回し、必ず実行していく

上記の姿勢が大事なようです。

また、とても参考になったのが「バージョン管理システムとTDDのタイミング」の話でした。Commitの粒度とテストコードの粒度をどのように合わせるか、いつも何となくCommitしていたので以下の指針はとてもためになりました。

テストコードがREDの状態（つまり機能が未実装） => Commit
テストコードがGREENの状態（最低限のコード実装が完了している） => Commit
リファクタリングの何箇所かで => Commit
テストコードがREDの状態でPushしない（当然だけど）

IMG_20170801_130757

およそ１時間の座学の後、実際にペアに分かれて手を動かすワークショップを行いました。

ワークショップ

整数閉区間オブジェクトを実装するという想定の元、与えられた条件からテスト駆動開発を体験しました。前段の座学で学んだように、若干遠回りに見えるようですが、１つずつステップを踏んでいくことで確実にプロセスを回す経験をしていきます。二人一組でチームを組み、様々な言語で課題に挑みました。Java, Scala, Go, Rubyなど多岐に渡るチームが結成されていました。札幌はJavaのチームが一組、札幌と大阪のリモートチーム（！？）でGoのチームが一組の計２組での参加です。

非常に単純な要件のように見えたのですが、実際に境界条件などを考慮してテストを考えていくうちに、もりもりとテストケースが増えていきました。テストコードを書くうちに実装が徐々に修正されていくのを実感することが出来ました。問題を小さく分割統治していくことで小さく小さく成功を積み上げていくのは、なかなか普段の業務では意識できないところです。

中間発表、最終発表で様々なチームの実装やテストコード、仕様からのテストケースを作り出す考え方などを見ることができとても勉強になりました。