TDD (テスト駆動開発) 研修を通して学んだこと

カルテットコミュニケーションズ開発部でインターンをしている山本と申します。私は普段、大学生として機械工学を学んでいます。 FizzBuzz問題のテストコードをPHPとPhpUnitで実装した際に気が付いたことを紹介します。

目次

  • はじめに
  • テスト駆動開発の大切さ
  • タスクを分割する
  • プログラムを書いていく際の順序 (red・green・refactoring)
  • コミットを細かくする
  • おわりに

はじめに

今回僕がTDD (テスト駆動開発) 研修をするにあたって参考にさせていただいた動画がこちらです。 https://www.youtube.com/watch?v=Q-FJ3XmFlT8 この動画で話をしている方は和田 卓人さんという方でテスト駆動開発をあみ出したKent Beckの出版した「テスト駆動開発」という本を翻訳した方です。とても分かりやすい動画ですので、ぜひご覧ください。

テスト駆動開発の目的

テスト駆動開発をする目的は綺麗な動作するコードを書くためです。別に綺麗なコードを書けなくたって動けば使えるから別にいいでしょと思う人もいると思います。絶対に自分しか見なくて,過去にどんなコードを書いたか忘れないならそれでもいいと思います。ですがそれはとても難しくてレアなケースです。例えば複数人で働いていて今自分が任されているプロジェクトを他の人に任せないといけなくなった時に自分のコードがとても分かりにくいものだったらどうでしょうか。プロジェクトが始まったらまだどうにかなるかもしれませんが、終盤の場合は期日も守らないといけないので初めから書き直すと言うことはできません。この様な場合でも対応できるためにテスト駆動開発は必要だと思います。

問題解決に向けてタスクを分割する

タスク分割はテスト駆動開発をするときに何をすべきかを道しるべをしてくれる大切なものです。自分の想像していたよりもタスク分割することはとても難しい作業でした。下にあるものは今回のテストを実装したFizzBuzz問題です。試しに問題文のタスク分割をしてみて下さい。

1から100までの数をプリントするプログラムを書け。
ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。

次に僕のタスク分割と見本としたタスク分割を紹介します。

- [ ] 3の倍数を「Fizz」に変換する
- [ ] 5の倍数を「Buzz」に変換する
- [ ] 3と5両方の倍数を「FizzBuzz」に変換する
- [ ] 出力する

テスト容易性：高 重要度：高
- [ ] 数を文字列に変換する
　- [ ] 1を渡すと文字列"1"を返す　-> 仮実装
　- [ ] 2を渡すと文字列"2"を返す　-> 三角測量

- [ ] 3の倍数のときは数の代わりに「Fizz」に変換する
　- [ ] 3を渡すと文字列"Fizz"を返す　-> 仮実装 -> 実装

- [ ] 5の倍数のときは数の代わりに「Buzz」に変換する
　- [ ] 5を渡すと文字列"Buzz"を返す -> 明白な実装
- [ ] 3と5両方の倍数のときは数の代わりに「FizzBuzz」に変換する
　- [ ] 15を渡すと文字列"FizzBuzz"を返す -> 明白な実装

テスト容易性：低 重要度：低い
- [ ] 1からnまで
- [ ] 1から100まで
- [ ] プリントする

僕のToDoリストは容易性や重要度を深く考えずにできそうなことをなんとなく箇条書きにした形になっています。それに比べ見本のToDoリストは問題文を細かく分割した上にそれを自分なりにわかりやすい文に書き換え、テスト容易性や重要度を考慮して並び替えてあります。タスク分割は想像よりも難しく、テスト駆動開発をする時以外でもタスク分割をする癖をつけてスムーズに安全で綺麗なプログラムを書ける様になれるよう練習していこうと思います！

プログラムを書いていく際の順序 (red・green・refactoring)

今までエラーの沼にハマって直った時になんだこんな事かよって思ったことありませんか？redの作業はそのような無駄な時間をなくすためにエラーも予想通りに出せる様にします。一番気づきやすいのでいちばん初めにやります。 僕は今までコードを書くときはエラーが出たらそこで止まりで足踏みすることも珍しくありませんでした。知識が乏しいことが原因なことの方が多いですが、見やすいコードを目的として止まることもありました。greenの作業ではそのような無駄な時間は後に回してとりあえず動く様にします。 refactoringでは動くこと確認したら、とりあえず動くことだけを目的としたコードなので修正できる箇所はあると思うので、それを綺麗にします。 これを繰り返すことで僕がしてきた無駄な時間が減り、誰がみても簡単に解るコードを効率よく書く順序を改善できました。

コミットを細かくする

テスト駆動開発とは少しずれてしまいますが、研修中に気づいた大切なことなので共有させていただきます。僕は今までコミットがとても雑で作業がひと段落した時のみにしていました。それをコミットを細かくすることで過去の変更箇所がなんで変更したのかを明確にできることができ、自分がやったことある作業を振り返りたい時に検索できたりするのでとても便利だと言うことを教えていただきました。実際にやってみると次の週に忘れていたことも簡単に思い出したりできてとても便利だったので、もしコミットをあまりしないよって言う人がいましたらやってみて下さい！

おわりに

今回の研修ではコードを書く時に大切な知識を、たくさん知ることができました。なかなか言葉だけでは感じ取ることはできないと思うので、今回僕がやったような簡単なテスト駆動開発をやってみて下さい！ 最後まで読んでくださりありがとうございました。