Try T.M Engineer Blog

多摩市で生息するエンジニアが「アウトプットする事は大事だ」と思って初めたブログ

書籍「テスト駆動開発」を読んで、これからはテスト書こうと思えた話

うちの会社には、小さな図書館があります。
ある日「何か図書館に置きたい本ない?」と会社からアンケートが回ってきました。
以前から、t_wadaさんの書籍「テスト駆動開発」が読みたいと思っていたので、希望したらすんなり図書館に置いてもらえたので、さっそく手にとって読んでみました。

ちなみに、以下の本です。

テスト駆動開発

テスト駆動開発

後悔? 写経しなかった・・・

いきなり後悔からです。
写経はしていません。借りた本なので写経する時間はありませんでした。

でも、個人的には写経しなくて良かったとも感じています。
この本は、写経するだけでも少し難しそうな感じがしたので、写経に時間と手間をかけるよりも、まずは1回さらっと読んでみてテスト駆動開発(以降、TDD)について理解を深める事が大事だと思いました。

なので、1回さらっと読んでみて、2回目で写経するのが個人的に良いと思いました。(私はまだ写経してないですが・・・)

TDDはテスト技法ではない!

TDDでよく言われている言葉です。
とは言え、私はこの言葉の意味をちゃんと理解していませんでした。

本にも書いてありましたが、TDDは自分でテストコードを書いてテストするので第三者からの観点がありません。
また、パフォーマンスのテスト等もやりません。
なので、コードレビューもテストも別で実施する必要がある。ここは私も「ぇ、そうなの?」と思わされました。

じゃあTDDとは何なのか・・・
私は、てっきりテストを事前にやるからテスト漏れを未然に防ぐことができ、品質の高いプロダクトができる技法かと思っていました。

でも、この本は「TDDを行う=バグゼロにはならない!(そんな魔法ではない。)TDDをするからといって、テストエンジニアが不要になるわけではない。」と書いてあった。

TDDはコードを書く技法

この本を読んで、TDDはコード書く技法だとわかった。
TDDは以下の流れでコードを書いていくのだが、ポイントは3.のリファクタリングにある。

  1. テストを書く
  2. コードを書く
  3. リファクタリングする

テストをして、ちゃんと動く状態を保ちながらコードを書いて、リファクタリングで綺麗にしていく。 そういったコード書く技法だとわかった。

本にも「綺麗なコードと動くコードを同時に満たすのは難しい、まずは、動くコードにして、綺麗なコードを心がけよう」と書いてあった。

TDDは必ずしも必要ではない?

必要ではないそうです。
TDDはプロダクトに必ずしも影響を与えるものではないし、本来のテストも別で実施する必要があるので、TDDが絶対に必要ということはないそうです。

本にも「テストをしながら開発をするのであれば、プログラマが書くコード量は2倍になり、それだけ時間が掛かるのでメリットは感じ辛いだろう」と書いてありました。

では何故TDDが流行るのか?

本にも書いてありましたがTDDはプログラマにとってメリットがあるんですね。
(t_wadaさんもこの本で「テストは質をあげない。質をあげるのはプログラミングだ!」と仰っておりました)

  • テストを書く習慣ができる。
  • 書くコード量は2倍になるので、よりコードと向き合えるようになる。つまり、リファクタリングに目を向けられるようになる。
  • TDDはスキルなので、アピールできる!

これらに加えて、最近は本でもTDDを使った説明や写経本が増えているように思えます。
なので、TDDを知っておかないと(テストの書き方を知っておかないと)せっかく読みたい本でもTDDがあって読めなかったり、避けたり、挫折したりしてしまうかもしれません。

なので、私もTDD頑張ろうと思います!

最後に・・・そういえば、t_wadaさんと言えば・・・

以下のAAが有名ですね。

f:id:special-moucom:20190221232115p:plain

この本を読んでも、何故ライオンなのか?何故このAAが産まれたのか・・・わかるかなぁと思ったのですが、わかりませんでした。
残念。