テスト駆動開発(社内講演)

f:id:nemorine:20180921080921j:plain弊社の山梨事業所に和田卓人(t_wada)さんをお呼びして、テスト駆動開発についての講演をしてもらいました。

3時間でしたがDemoの圧倒的なライブ感が凄かったです。 和田さんの深遠なる知識と実務感を感じました。

今回もたくさん気づいたところあったので、忘れないように書き留めておきます。

TDDは単なるテストファーストではない。

プログラミングテクニックではあるけど、設計テクニックでもある。

ToDoリストからの選び方

一番重要 or 一番簡単なもの
和田さんは一番簡単なものを選ぶ

リファクタリングの終了条件

  • 時間
  • 数(重複が解消されたら)

重複派は2out派 or 3out派がある。和田さんは3out派

リファクタリングをするためには、All Greenが必須。

All Greenではない場合は条件を満たしていないので、まずAll Greenにすること
All GreenのときのみリファクタリングしてもOK。

テスティングフレームワークはランダムに実行されている。

テスト自体に依存関係が入らないようになっている。依存があるとテストの並列作業が難しくなり、時間が極端にかかるようになる。

テストの時間を減らすためにやること

  • 力とお金で解決する(=サーバー増設+並列実行など)
  • 全件実行しないなど件数を絞っていく

クラウドではなく、オンプレで力押ししているところもある。

テストコードの品質

テストコードの品質はプロダクトコードと一緒にする。静的解析をかけている場合はかけるし、コードレビューもしていく。
昔はテストコードはプロダクトコードほど力を入れなくてよい、と言われていた。その結果、プロダクトコードとテストコードの割合が1対10とか1対20になった。 今となるとそれは間違っていたといえる。

t_wadaさんのレビューの仕方

まずは全体の構造=構造化されたToDoリストをじっくり見る。それがOKであればプロダクトコードやテストコードを見る。



せっかく和田さんと話す機会ができたので、札幌でTDDBCを開催したい件を相談しました。札幌でもTDDBCできるといいなぁ。

f:id:nemorine:20180921080921j:plain