こんにちは、あるいはこんばんは。すぱ..すぱらしいサーバサイドのエンジニアの(@taclose)です☆

弊社では先日テスト駆動開発（以降、TDDと呼ぶ)ハンズオン勉強会を開催しました！

今回の記事の内容はズバリ２つ

誤解してる!?テスト駆動開発の良さ！学ぶ事の意味！

TDDハンズオン勉強会を開催する意図や実施内容、感想！

読者のターゲットは

TDDを誤解している人
TDDハンズオン勉強会を弊社でもやろう！とか思ってる人

を想定していますっ。

誤解されがちなTDD、記事にするには書ききれないTDD...なるべく小難しい内容は省いて興味を持ってもらうための記事を書いてみようと思います！

テスト駆動開発（TDD）は良い物だ！
- テスト駆動開発（TDD）とは何か？
- TDDに対する誤解
TDDハンズオンについて
まとめ
最後に
参考文献等

テスト駆動開発（TDD）は良い物だ！

テスト駆動開発（TDD）とは何か？

プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き、そのテストが
動作する必要最低限な実装をとりあえず行なった後、コードを洗練させる、という短い工程を繰り返すス
タイルである
(Wikipediaから抜粋）

よくTDDについて調べてみると、だいたい上のような説明に始まり、Red/Green/RefactorのサイクルがTDDであると学んで終わってしまう。でも、この記事に辿り着く読者は「そんな事はわかっている」という人が大半だと思うので、あえてここではこう説明しておきます。

「動作するきれいなコード」。Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発（TDD）のゴールだ。
動作するきれいなコードはあらゆる意味で価値がある。
（「テスト駆動開発」著 Kent Beck 訳 和田卓人のまえがきから抜粋）

TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング 2020年にあった和田さんによる基調講演も「TDDとは何か？」という話はここから始まります。是非この動画は見て頂きたいのですが、抜粋して言うと、「動作するきれいなコードを書く事は、品質・コスト・開発速度どの側面から見ても重要な要素であり、それを実現するのにTDDは１つの解である」といった内容に感じました。

このゴールから始まる「まえがき」の書き方も、よくよく考えるとTDDっぽくて感慨深いですね！グレイトっ（笑）

では、「そんなにTDDが良いのならなぜもっと普及しないのか？」少しだけTDDに対する誤解について話しておこうと思います。

TDDに対する誤解

テストコードを書く事が一般的になった昨今ですが、そんな中で「TDDは先にテストコードを書く事」という偏った認知が広がっていったようです。これは誤った認識だという事は声を大にしてお伝えしたいです。

TDDがテストファーストである事には複数の意味がありますが、私が一番しっくりきた解釈としては、詳細設計と実装の狭間に「どんな風にクラスを分けて、どんなメソッドを定義してあげると良いだろうか？」というのをテストコードという形で箇条書きしている開発フローだと感じました。

思いつきで書いた動作するコードは、得てしてテストコードが書きづらく、既存実装に対して書きやすさで実装が進んでしまいます。なので、先にどのクラスにどんなメソッドが存在していてほしいかをテストコードとして記載していく事で、本来あるべき実装・振る舞いを実装できる。

また、「TDDはテストコードの開発に時間がかかる」というのもよく聞く話ですが、先ほど紹介した動画の中でも最後に解説されていますが、テストの経済性というのは実際そんなに悪くはなく、少なからず担当者が離職する間隔よりも短いタイミングで元は取れるようです。

また、ここであえて「離職する間隔よりも短い」という言い回しをさせてもらったのは、実体験的に当事者意識を持てるか？というのが案外大事なのではないかと思ったから補足させてもらいました。内部品質の高いコードを書く事の見返りは自分にもある事を知っていてほしいです。

※上の画像は、先ほど解説した動画の最後の方で出てくるグラフです。無駄にメンテナンスが困難なテストコードを量産しているとメンテナンスコストが高くなる事もあるので注意です。

※本来のテスト駆動開発をやればこうはなりませんよ！深く考えずテストを後から書くような開発してるとこうなっちゃう現実が待ってるという注意喚起です。

TDDハンズオンについて

ある意味、ここからが本題ですねっ！

TDDハンズオンの趣旨

「TDDの良さを知ってもらって、普段の開発に活かしてほしい。」という事で開催されました。

先にも記載した通り、TDDというのは名前からしても誤解されがちな傾向にあり、本当の良さって伝わりにくいものです。実際に手を動かしてはじめて「あ、確かに開発の流れがしっくりくる！安心感がある！」そんなTDDだからこそハンズオンをやる意味があるのでは？と考えました。

TDDハンズオンの計画

事前準備

TDDを実施する開発環境としてJavaが動く開発環境が必要になりますが、手間であればCodinggame.comのようなサイトでやってもらっても良いかと思います。

www.codingame.com

※弊社も一部の社員はこちらを使いました。普段PHPで開発していてJava環境がない社員等。

スケジュールと概要

１日目：

弊社では１日目をTDD Boot Camp 2020 Online #1 基調講演/ライブコーディングを一緒に視聴する時間に費やしました。ハンズオン本編以外の部分をスキップしたり、1.25倍速で再生して1時間半に無理矢理短縮しました＾＾；

まずは基礎知識としてTDDの流れについてちゃんと理解してもらいたかったためです。

２日目：

うるう年問題は以下としました。

入力した整数がうるう年かどうかを判定するプログラムを書け。
うるう年のときは「true」、それ以外は「false」とプリントすること。

うるう年の定義
・西暦年号が4で割り切れる年をうるう年とする
・ただし、西暦年号が100で割り切れ、かつ400で割り切れない年は平年とする。

私の所感としては、１時間半でやるハンズオンであれば、丁度いい難易度かなと感じました。

タイムスケジュールとしては以下としました。

うるう年についてのTODOリストの整理（１０分）
２チームからTODOリストを発表（６分） ※これを参考に後半タスクを進めてもらう
テストコードのサイクル開始（Red/Green/Refactor)（３０分）
２チームからTDDの結果を発表（６分）
バッファ（２０分）

TDDハンズオンの感想（反省点や振り返り）

動画は事前に見てもらうべきだった

参加者から頂いたコメントにも「開催回数が増えてもよいのでビデオは早回し再生ではなく通常再生が良かったです。」といったご意見がありました。確かに1.25倍速で抜粋して見てもらったのは苦肉の策で、計画段階でも悩んだポイントでした。「参加者は事前にこれを見て来てください（倍速で見るとかはお任せ）」とした上で、重要ポイントだけピックアップして解説してから始めるぐらいにした方が、円滑に進んだかも！

TODOリストの作成にもう少しゆとりを持つと良い

動画を見てもらうとわかるかとは思いますが、TODOリストとは「どんな振る舞いをしてほしいのかを箇条書きにした仕様書のようなもの」です。

TODO作成時間に時間を割いても良かったように感じました。
TODOがしっかりできていれば後はそれ通りに実装するだけなので、
割合的にはTODO作成時間が多くなるイメージだと個人的にはもう少しうまくできたのかなと思いました。

上記のような意見も後日アンケートで頂きました。確かに１０分なんかじゃ全然足りなかった！初回のTODOリスト作成は２０分ぐらいはせめてあるべき、３０分でも良いと感じました。３分クッキングみたいに「出来上がったTODOリストはこちらです」って提示するのは一案かもしれないんですが、ハンズオンの意味が色褪せちゃいますよねOrz せっかくのハンズオンなのでもう少し時間にゆとりがあれば良かったです！反省！