いつかの飲み会での話。
急にTDDに関する信念を誰かと語りたくなっていた。
ユニットテスト無用なのでは？
shypk :
急な話ですけどUnittestって必要ですか？
私も昔からTDDとかうるさい方でunittestとかintegration testとかいっぱい書いていたんですけど実際にその周りのコードの修正することなく次のバージョンとかを作る羽目になって無駄が多いなと思いましたね。なので今はintegrationかe2e testだけ書くようにしているんです。
monamour555さん :
規模と目的によって違うんですけど基本はつけた方がいいです。TDDを考えても開発してる過程で安定できるじゃないですかそれだけでも十分価値はあります。
もしshypkさんが部長になって触ることがなくなるとします。後任の方が一行だけ修正するとしましょう。そのときの動きの保証になるじゃないですか。
shypk :
その為に動きの保証はintegration testでカーバすればいいじゃないでしょうか。
monamour555さん :
それでは他のモジュールと結合した後の話になるので不具合が起きた場合に追跡が難しくなります。
shypk :
まぁそういうところはありますね。でもintegration testだと基幹コードが変わっても同じ動きを目的としているなら簡単にテストを適用できますよ。
monamour555さん :
こう考えてみたらいかがでしょう。会社はすごく大きいプロジェクトのなかで一つのモジュールを担当を任されたとしましょう。結合するモジュールは他社のものとします。このときに何らかのテストが失敗した場合どうなりますか？
shypk :
なるほど。それは問題点を探しにくくなりますね。どこの責任なのかもはっきりしませんし。
monamour555さん :
それもそうですし、すくなくともこちらが担当のモジュールではこういったテストが通っているので、ってことで話が進められます。
shypk :
なるほど、他社との協業経験が豊富な@monamour555さんからこそのいい例でした。
それではユニットテストをどう付ければ？
shypk :
それではぶっちゃけ以前話していたpongoは入れた方がいいですか?
monamour555さん :
はい、絶対入れた方がいいと思います。
shypk :
すでにe2eテストでpytestいれてるのにですか?それってcoverage的な理由でですか？
monamour555さん :
現状のpytestもe2eとして残しずつやるといいですよ。
もちろんcoverage100を目指せ。ともいえるんですけど、それが負担でしたら最初はたとえば60を目指すのです。
shypk :
というと？
monamour555さん :
で次そのファイルをさわるときはcoverageが下がらないようにするだけです。
shypk :
なるほどう。修正があって下がるならテストを追加する。そうなると右肩上がりになりますし、そこまで負担にもならないですね。
monamour555さん :
それです。