はじめに
Ateam Hikkoshi Samurai Inc. Advent Calendar 2017の13日目です。
本日はエイチーム引越し侍の今年5月入社のRubyist、 @ex_SOUL が担当します。
背景: なぜTDDについて書こうと思ったのか
以前、CodeRetreatイベントに参加した際、周りのRubyistが当たり前のようにテストを書いていたため、このままではいけない…！という危機感を持ったことが始まりでした。
そして先日新訳版の「テスト駆動開発」を購入しました。
翻訳に和田卓人さん( @t_wada ) が携わった本です。
@t_wada さんといえば、以下のイメージで有名だと思います。
※上記画像はここで言及されている通りライセンスはパブリックドメインです。感謝
「TDDは死んだ」のか
TDDでGoogle検索を実施すると、TDDを薦める記事、逆にTDDは死んだ、という記事もあります。
特に、Ruby on Railsの作者でもあるDHH氏のTDD is dead. Long live testing.(意訳:TDDは死んだ。テスティングよ栄えよ。)という記事の存在は大きいです。個人的にはDHH氏の「TDD is Dead.」は「私はTDDが大嫌いだ」くらいの意味だと認識しています。
この記事の内容について
ここでは、どのようなサービス、どのような開発手法の際にTDDは輝き、あるいはほぼ意味を成さないのかを、
私が「テスト駆動開発」を読んだ上での意見を交えながら書いていきたいと思います。
ここで一点断っておかないといけないのですが、まだ私は本著を完読していません。なので、もしかしたら本著に記載している重要な要素が抜けていたり、もしかしたら異なった事を論じている可能性もあります。そんな記載を見つけた際は、コメントにて補足して頂くか、編集リクエストを送って頂けると非常にありがたいです。
本著を読む前の私のTDDへの認識
TDDで開発をするからと言って、一般的に言うテストが無くなるわけではない
これは2016年に実施されたRubyにおけるTDDの基礎と題した勉強会で学んだものです。
TDDにおけるテストとは、任意のメソッドが仕様、想定通りに動くことを証明するためのものであり、一つの開発手法に過ぎません。実際の動作を保証するものではない(ちょっと言い過ぎかもしれませんが)という認識です。
TDDにおけるテストは、あくまで開発を支援する、継続的な開発を楽にするものであり、製品の仕様の確からしさ(いわゆる一般的なテスト)ではありません。あくまで開発手法の一つだと考えています。なので当然一般的なテストも必要です。
付録Cについて
まず、本著においてはおよそ普通ではない読み始めとして、巻末の付録Cから読み始めました。何故かと言うと、すでに本著を読み進めた感想を書いたブログがいくつもあり、その中に、このような記事があったからです。
本著を読み終えた人には、この本は付録Cから読むべき。付録Cはいいぞと語る方が多いそうです。ガルパンはいいぞ
この付録Cは原書には無い、訳者解説、つまりt_wadaさんの視点で本著の読み方とこれからのテスト駆動開発について書かれています。
TDDからBDDへ
多くは記述しませんが、付録Cには、TDDからBDDへというセンテンスがあります。
私もTDDという名称には齟齬があるのではないか、と考えていたのでこのアンサーは私の疑問を氷解させるに十分たるものでした。気になる方は是非実際に読んでみてください。
t_wadaさんの考えるTDDとは
付録Cに書かれています。当該部分を読んで、TDDについて再認識しました。TDDの本質についての言及部分は、哲学にも似た気づきがありました。
TDDにおいて、何がメリット、デメリットたりえるか
開発のスピードは速くなるのか
まず間違いなく言えるのは、開発のスピードは遅くなるということです。実際に書くコードの総量が増え、失敗するテストを書きそれを成功するようなコードを書くことを繰り返すことも、実装への最短ルートとは考えにくいからです。
頭の回転が早く、実装のゴールが既に見えている人は、「何てまどろっこしい開発手法なんだ！」と考えると思います。
では長期的に見るとどうか。申し訳ないのですが、私はこれに明確に答えることはできません。しかし、以下の事が考えられます。
TDDで積み上げられたプロダクトコードは、以下の点で優れているといえます。
リファクタリングが(テストが無い場合と比べて)容易
本著を読めばはっきりと感じ取る事ができる点として、TDDはリファクタリングと共にあるという点があります。
TDDには、小さいテストを実装し、そのテストを動かし失敗させ、実装そのテストを成功させる。そしてそれをリファクタリングしていくという流れがあるのです。
もちろんリファクタリングの過程でテストコード自体の修正が必要になる場合もあります。
しかしそれは、そのリファクタリングがどのような影響範囲を持っていて、どこのテスト(機能)に影響が出るのかが明確になっているとも言えると思います。
システム・機能がどのように動いているか・動くべきかがテストコード内で表現されている
システムを運用し続けていると、いわゆる仕様書と実際のコードに齟齬が生じ、ドキュメントが役に立たなくなることがあります。
例えばそんな時に新しい開発メンバーが参画した場合、実コードから仕様を理解し、何らかの修正を加えることは危険を伴うでしょう。しかし、そんな時にテストコードにその機能がどのように動くべきかが記述されていれば、その新メンバーのシステム理解への一助となります。
開発のスピードは下がる、ではTDDは何のためのものなのか
ここが重要な点になるかと思います。
本著には以下のような記述があるので引用します
TDDをやっていると、テストコードとプロダクトコードの行数は、同じくらいになる。つまりこれまでの2倍コードをかけるようになるか、半分のコード量で同じだけの機能をかけるようになるしないと、TDDはのメリットは得られないということだ。
かなり厳しい事が書かれており、ここを読んだときは正直驚きました。
ただしこれは、開発のスピードという点においての話でありと考えています。
もう少し引用します。本著の32章TDDは誰のためのものかの部分です。
優れたエンジニアリングがプロジェクトの成功に占める割合は20%といったところだろう。(中略) 残りの80%がしっかりしている限り、プロジェクトを成功へ導きうる。
さらに同じ章には以下のような記述もあります。
筆者がまだ若いエンジニアだったころに最もストレスを感じたのは、大きな夢とともに始まったプロジェクトのコードがだんだんと腐ってゆく光景だった。1年経つ頃には、もう腐臭のするコードを投げ捨てて新しいプロジェクトに行くことしか考えていなかった。(中略) 私の目標は、プロジェクトが1年経っても開始直後のようにキラキラした目でいられるようにすることだ。TDDならそれができると考えている。
プロジェクトを成功に導くための一助にはなるかもしれない。しかしそれ以上に、TDDはエンジニアのためのものである、という強い思いが感じられました。
現時点での私のTDDへの認識
TDDは一つの開発手法です。そこは変わっていません。
今回新たな個人的な認識として、TDDは開発におけるタスク管理手法を開発手法に昇華させたものなのかもしれないというものがあります。
おそらく、頭の回転が早い人や俗に言うワーキングメモリが多い人には不要かもしれませんが、
Xという入力でYという出力が必要、Jという場合はKという処理も必要、といった小さな仕様、タスクをテストコードという形で書き出し、常に頭の中で考える必要をなくすための、GTDの思想に似た開発手法なのではないかと考えるようになりました。
現在私は、Railsのプロジェクトに参加しており、そこではRspecでテストを書く運用となっています。
私はまだこのプロジェクトに参加して間もないですが、TDDの原則に則った開発手法をここで実践し、学んでいく予定です。
まとめ
TDDは一つの開発手法です。そして、おそらくそれは向き不向きがある、万人に合うわけではない開発手法だと思います。
そして、ここに私が書いた事が(当然ですが)本著の全てではない事にご注意ください。
本記事を読んでTDDについてに興味を持たれた方、もしくは元からTDDに興味のある方、是非「テスト駆動開発」を実際に読んでみることをお薦めします。
実際に読むことで初めて知ること、感じること、理解できることが必ずあるはずです。
以下に主なオンラインショップを記載しております。(別に出版社やt_wadaさんの回し者というわけではないです…)
オーム社eBookStore
※上記eBookStoreは来年1月末で終了します。購入したい方はお早めに！
Amazon
最後に
Ateam Hikkoshi Samurai Inc. Advent Calendar 2017 13日目でした。読んで頂きありがとうございます！
明日はエイチーム引越し侍の新卒デザイナーの@teiiiさんです。
お楽しみに。
また、株式会社エイチーム引越し侍では、一緒にサイト改善をしてくれるWebエンジニアを募集しています。エイチームグループのエンジニアとして働きたい！という方は是非、以下のリンクから応募してください。
皆様からのご応募、お待ちしております！！