みなさんこんにちは！ピクシブで唯一(?)のテストエンジニアの @shimashima です。
6月28日にTDDの伝道師として有名な t-wada こと和田卓人さんを講師として招き、1日かけてのテスト駆動開発(以下TDD)ワークショップを開催しました。
本日はピクシブ株式会社様にて、1日コースのテスト駆動開発ワークショップの講師を務めさせていただきました。ご参加くださいました皆様、誠にありがとうございました！
— Takuto Wada (@t_wada) 2018年6月28日
今日はその様子を紹介したいと思います。
開催のきっかけ
開催のきっかけは、自分が実行委員を務めているJaSST '18 Tokyoにて和田さんによるTDDチュートリアルを聞いたことです。
このチュートリアルの登壇依頼を行なったのも私なのですが、恥ずかしながらそれまでTDDは話に聞いただけで、各地で開催されているTDD Boot Campも受講していませんでした。それまで「TDD＝テストファースト」くらいに考えていた私ですが、和田さんのTDDに関する説明とライブコーディングを見て衝撃を受けました。それは実際のイメージと全く異なっていたからです。
結果「TDDが開発効率向上に役立つ」という考えに至った私は、すぐに弊社VPoEであるbashに社内ワークショップ開催を打診しました。TDD Boot Camp受講者でもあるbashが快く賛同してくれたことで、非常にスピーディに実現することができました。
開催にあたって気をつけたこと
開催にあたって気をつけたのは参加者選びでした。
研修を受けてそのとき学べたとしても、実務で使われなければ「よかった」だけで終わってしまいます。これは会社・受講者ともに勿体無いことですし、次回以降のワークショップ開催を企画する際に説得力が弱くなってしまいます。
そこで、「チーム単位で参加し、かつ今後チームでの実務においてTDDにトライすること」という条件を設けました。もちろん、すべてのチームでTDDがマッチするとは限らないので、使い続けることは前提にしていません。もし駄目だったのであれば、どこが駄目だったか・マッチしなかった理由はどこにあるのかを、フィードバックしてほしいともお願いしました。
幸いにして、16名のエンジニアがこの条件を前提に参加者として手を挙げてくれたので、その方たちに今回のワークショップを受けてもらうことにしました。
午前の部：TDDの概要説明とライブコーディング
今回のワークショップは、午前と午後の二部構成での開催となりました。午前の部の内容は、TDDの概略説明と、TDDを用いた上でFizzBuzz問題を解くライブコーディングです。どちらも和田さんご本人によるものです。
午前中の講義については、和田さんから事前に「ワークショップ参加者に限らず社内だれでも聴講可能」というお話をいただいていていました。エンジニアに限定せずに社内の人間に広く声をかけ、結果多くの人に聞いてもらうことができました。
スライドによるTDDの概略説明の後は、和田さん直々のライブコーディングです。TDDを用いてFizzBuzz問題を解く様子を見せてもらいました。
途中で聴講者から「おー」という感嘆の声があがるなど、非常に盛り上がりました。最後の仕上げの段階では、「2年後に前任者がいなくなった状態でコードを引き取った場合、どういうテストコードが残っていればよいか」という観点からテストコードのリファクタリングが行われ、実際に発生しうるシチュエーションを元にTDDの意義を確認することができました。
午後の部：TDDワークショップとコードレビュー大会
昼食を挟んで午後からは、社内募集に応じて手を挙げた16名を対象としたワークショップが始まりました。セマンティックバージョニングを題材としたもので、二人一組のペアプログラミングによって行われます。
ペアごとに使用言語は自由となっていて、参加者の使用言語はRubyが7割、残りがJavaScriptかJavaという内訳でした。
午前中の講義を振り返りつつの作業で、まずは題材を適切なTODOにするところからはじめ、そのTODOに対してテストを書き、その上でコードを書いて行きます。和田さんは要所要所で全体に対して説明を行いつつ、基本的には会場を見てまわりながら困っているペアに対して個別に助言をしていました。
代表者が前に出て行う全体コードレビューを途中に一回、最後にもう一回行います。その時点での成果物を「なぜこうしたか」という観点から発表し、その後質疑応答を行うという流れです。
レビューでのバグ発生と修正
ワークショップ終盤、2回目の全体コードレビュー時にそれは起きました。コードレビューが終わり次第クロージングに移るはずでしたが、最前列の参加者がプロジェクターで写し出されたコードに含まれるバグを見つけたことから事態は変わりました。
今日のワークショップ、ペアプロ実習後の公開コードレビューで不具合が見つかり、すぐに直そうとする発表ペアをまず落ち着かせ、不具合を再現するテストコードを書いて実際に失敗するところを確認してから直す姿勢をその場で説明できたのがハイライトだった。
— Takuto Wada (@t_wada) 2018年6月28日
和田さんのTweetにあるように、慌てて修正しようとするペアを落ち着かせ、ユニットテストで再現(Red)、修正、テストパス(Green)と手順を踏んで対応しました。
この手順を踏まなければ本当にバグなのか、またバグの発生条件が何なのか不確定なままでしたし、修正したつもりでも本当に直ったのか確証が得られないままだったでしょう。 偶然とはいえ貴重な体験をすることができました。
なお、このとき行われた作業の流れは不具合にテストを書いて立ち向かう - t-wadaのブログで詳細に説明されています。
終わりに
TDDという単語は、ソフトウェアエンジニアであれば大抵耳にしたことがあると思います。ですが、原典を参照し実践している人は少ないのではないでしょうか。
今回、その原典を翻訳し直し、かつ以前より実践している和田さんから直接TDDについて学ぶことができたのは貴重な経験でした。特に、TDD実践上の苦労や「リファクタリング」の扱いの大変さなど、書籍を読んだだけではわからないことを学ぶことができました。
社内の全エンジニアが参加できた訳ではないので、今回受講した人たちがTDDを実践し社内に広め、ゆくゆくは自分たちで社内TDDワークショップを企画・開催し、TDDを広げていければいいなと密かに考えています。
後日談
本日 @t_wada 師の講義を受けた若手スーパーエースが、早速モブプロで既存プロダクトのアサーションルーレット気味だったテストコードを、繰り返しがなくテストケースごとの責務が明確で言語化された形式に鮮やかにリファクタリングしてみせてた。 pic.twitter.com/eCK44EpllB
— †tadsaｍ† (@tadsan) 2018年6月28日
なんと受講当日に早速ワークショップの成果がでました！
ピクシブでは、TDDを実践しているエンジニアはもちろんTDDに興味のあるエンジニアを募集しています。
