プロジェクトにおけるTDDの重要度の話

Satoshⅰ Nakagawa @Psychs

成功したサービスを作り始めた時に、どのくらいの割合のプロジェクトが最初から TDD とかやってるのか気になる。

Satoshⅰ Nakagawa @Psychs

成功したサービスを作ってる人たちのプライオリティの置き方は、絶対そういうところではないはずだと思うんだよね。

KOIZUKA Akihiko @koizuka

@Psychs 同意

Satoshⅰ Nakagawa @Psychs

@koizuka やっぱそうですよね。

Morihiro Ryu @garyu

@Psychs TDDは、明確にプライオリティを置かないと実現されない性質のものなのでしょうか。

Satoshⅰ Nakagawa @Psychs

@garyu なくてもサービスは動かせるし、それなりにコストがかかるので、それを上回るメリットがなければやる理由がないんじゃないでしょうか。

Morihiro Ryu @garyu

@Psychs 一度慣れれば特別なコストなしに続けられるものかと思っていましたが、常にコストを払い続けなければいけないならば確かにそうですね。最初にテストを書く時点で仕様が決まっていただければいけないというのがコストでしょうか？

Satoshⅰ Nakagawa @Psychs

@garyu 何かを変えるときに必ずテストを更新しないといけないので、常にコストがかかりますね。

Satoshⅰ Nakagawa @Psychs

@garyu あと、サービスの開発の初期は試行錯誤の連続で、仕様があらかじめ決まってることはないはずなんですよね。

Satoshⅰ Nakagawa @Psychs

@garyu そもそも初期はユーザを増やすことが一番大事なので、他のところにコストをかけてていいのかと思います。

Manchun Milky Naomi Tåkãnø🏊 @honten

@Psychs @garyu 実際テストのメインテナンスは頭の痛い問題ですが、それでも規模が大きくなっていくと、自分の知らないうちに自分の書いたコードが壊されることがあるので、そうならないためにテストを書いているというのが今の自分のテストに対する考え方です。

Satoshⅰ Nakagawa @Psychs

@honten @garyu 規模が大きくなってくると必要だと思います。ただ、開発の最初からはやらないほうがいいと思うんですよね。

Manchun Milky Naomi Tåkãnø🏊 @honten

@Psychs @garyu たしかに。問題は一体どのタイミングで「規模が大きいからテストを書こう」という決断がとれるかだと思うんですよね。往々にして誰もやりたがらないし、、、

Tatsuhiko Miyagawa @miyagawa

@Psychs @honten @garyu 大規模だからテストがいるかどうかと、TDDするかは別の話じゃないすかね。コードを書くときにこれがグリーンになれば終わりだ、っていうゴールをつけるためのツール。

Tatsuhiko Miyagawa @miyagawa

@Psychs @honten @garyu 実装に密結合したテストをコミットしてCIまわすと、あとでリファクタリングするのにも邪魔になるし、っていうのは同意。

Satoshⅰ Nakagawa @Psychs

@miyagawa @honten @garyu 作るときはそれでいいんだけど、そのあとそのテストのメンテナンスがちょっとしんどいな気がする。特に開発の初期とかで、全体のデザインを試行錯誤してるときね。

Tatsuhiko Miyagawa @miyagawa

@Psychs @honten @garyu TDDで書いてグリーンになったらそのテストを捨てる（というか最初からコミットしない）というのもありでは？ 手動でどうせテストするんだしそれを自動化するツールと考える。

Satoshⅰ Nakagawa @Psychs

@miyagawa @honten @garyu なるほど。それならありかも。

Tatsuhiko Miyagawa @miyagawa

@Psychs @honten @garyu 僕は今APIレベルを全部BDDでかいていて、specを先にかいてこけさせてグリーンにしてコミットしている。リファクタリングしたりAPIの変更するとこけるテストとかでてくるけど、ちゃんとテストされてる安心感はあります :)

Satoshⅰ Nakagawa @Psychs

@miyagawa @honten @garyu たぶん、サービスが今の状態になってからだとメリットは大きいと思うんだよね。ぼくのポイントは、サービスをこれから立ち上げようっていう初期の段階でそれをやるメリットってどれくらいあるんだろうってことなんだよね。

Kenn Ejima @kenn

@miyagawa @Psychs @honten @garyu グリーンになったら捨てるってのは面白いね。ぼくは @Psychs と同意見で、試行錯誤が重要な初期にはテスト書かない。ドメインロジックが固まってきたらユニットテストが増えていくけど、テストは必要最小限派。

Tatsuhiko Miyagawa @miyagawa

@Psychs @honten @garyu 初期の試行錯誤の段階で、テストを書くオーバーヘッド＋メンテナンスコストが、テストのないコードの負債を上回るなら、書かないほうがいいよね

Tatsuhiko Miyagawa @miyagawa

@kenn @Psychs @honten @garyu かくいう僕も個人のものにはほとんど書かないね。TDDで書くとその日のタスクが最初に定量化されるので終わりの見えない漠然とした不安とかがなくていいし、定量化されてうれしい。けど、サイドプロジェクトにはそれいらないし。

Tatsuhiko Miyagawa @miyagawa

@kenn @Psychs グリーンになったら捨てるのは、単純に複数ページまたがった動作試験とか、ブラウザ閉じてcookieクリアとか面倒なときにrspec/capybaraでサクッとかいたほうが手でやるより楽、っていうこともあるかなと。

Kenn Ejima @kenn

@miyagawa @Psychs ぼくはケチなので、そこまで書いたらコミットしちゃうなｗ まぁでも将来テストのテストに時間食われる（本質的でない問題で時間食われることはよくある）ぐらいなら思い切ってテスト自体を捨てる（消す）という考えはありだと思う。