TDDについてちょろっと調べてみた

なぜ調べる経緯に至ったか

勉強会でサービスを作っていまして、そのプロジェクトでふと、単体テスト書けてなくね？となりました。

あれ？最初は書くようにしてたのにいつ間にか形骸化してるじゃん。どうしよ。ってなって、じゃあTDDでやったらいいかも！と提案したのが始まりです。

じゃあ次からTDDでやろう！と決まったは良いものの、TDDについてはよく知らない。ユニットテストから書いていくことだよね？ぐらいの知識でした。

なので、TDDってどんな問題を解決するものなのか、そもそもテスト書くの忘れるからTDDって訳でもなさそうな気がする。と思って調べてみました。

どう調べたか

ググりました。「TDD やり方」「TDD メリットデメリット」「TDD 目的」とかで調べました。

見つけた記事

基本的にQiitaの記事は荒れてる印象でした。TDDについて書くの怖くなった。笑

技評の和田さんの連載が素晴らしくて、まだ第3回までしか読んでないけど、これ無料で読めて良いんだろうかと。

なぜTDDでやるのか？

色んな記事を見る限りは「開発者のため」なのかなーと。

当たり前だろ！と思うかも知れませんが、これ結構誤解されがちなんじゃないかなーと思います。僕も誤解していたかも。

TDDは素早いフィードバックと開発者の安心のためとどこかの記事に書いてました。

そして和田さんの連載では

Developer Testingは，開発者が開発者のために，自分自身のために，もしくはチームメンバーのために行うテストです。

このように書かれてます。

和田さんの連載によると、テスト駆動開発におけるテストとは、品質保証ではなく、Developer Testingという開発者のためのテストであるということでした。

完全に品質保証のテストをやるものだと誤解してました。

Qiitaで盛り上がってる記事もこの辺を誤解しているように見えます。TDDでテストカバレッジを100%に近づけるのは無理だ。的な。

話は逸れますが、テストカバレッジは80%以上になれば100%にしようと大きな効果はないといった記事を見つけたので、その辺りも勉強したいところ。

TDDどうするのか

RED-GREEN-リファクタリングのサイクルを回すのだ！これは前の現場で実は教えてもらってて、改めてそうだったなー。と思い出しました。最近できてなかったや。

まずプロダクトコードを書く前にテストコードを書いてテストをこかす。
テストが通るように実装する
テストが通る状態を保ちながらリファクタリングする

簡単に書くとこんな流れ。詳しくは和田さんの連載をみてください。

TDDをやるときの心構え

素早いフィードバックを得るためという目的があるので、テストは速い状態を保たないといけない。

あとはわかんない。ちょろっと調べただけだから。

TDDが白熱するところ

雑に書きます。

テストしにくいところどうするの？
開発コストでかくなるんじゃね？
遅いテストを書くんじゃねえ
全体的に極端に捉えられがち

なんか議論が白熱してるところはこんなところなのかな。

TDDは死んだとかあまり何が言いたいのかよくわかんなくて。原文読んだらわかるのかな。

Mock化しまくってテストするべきところができねーじゃん。って言いたいのはなんとなくわかった。

開発コストは、デバッグとかも考えるとむしろ最終的にコストが小さくなるんじゃないのかなと思ってます。

まとめ

テスト書くの忘れる防止のためとかではなかった。

でもTDDやってみようと思います。安心したいし。

深く調べた訳ではないので、次はもう少し議論白熱してるとこに焦点当てて調べて行きたいです。

BDDとか、テストファーストとかってワードも出てきたのでそちらも合わせてちょっと調べれれば。

TDDやる上での仮説

開発者が安心できるはずだ
素早いフィードバックを得れるはずだ
開発コストは膨らまないはずだ

検証できない仮説ばかりを立ててしまった。。。

はぶあぶれーく

IT技術の勉強に関して記録していく備忘録的なものです。