これは、asumikam #phpcon_odawara Advent Calendarの15日目の記事です🎄 本日は「オープン・クローズドなテストフィクスチャを求めて」の感想を書いていきます!
📖 スライド speakerdeck.com
感想
- コピペされまくるテストフィクスチャ VS 大統一テストデータ、どちらも辛い、どうする〜〜!?
- 適切にSeederを作って使い回すフィクスチャがいいんじゃないの!?
- \きづいちゃった/ これ、オープン・クローズドじゃね!?
の、ような登壇でした。 テストのトークはいろいろあるとおもいますが、この観点から切り込んだトークは新鮮でおもしろかったです。
プロダクトコードが増えるとともにテストコードも増えていきますが、実際ボリュームがあるのは AAAパターンの arrange
なる部分ですよね〜。
特に何もルールがないとたしかにコピペが横行するし、めちゃくちゃコード量が増えるんですよね...
で、それを解決すべくヒトの頭に浮かぶのは"大統一テストデータ"。はい、私も浮かんだことがあります...し、そのようになっているプロダクトコードもみてきました。 こっち、管理がめちゃくちゃ難しいですよね〜〜、なんというか、脳みそのリソースが、本来割くべきところじゃないところに持っていかれるというか。 なぜかテストデータを適切に保つデバッグがはじまる、みたいなね。これハマると普通に半日〜1日持ってかれるんですよね。
立ち止まって考えてみると、大統一テストデータのつらみより、コピペされまくるテストフィクスチャの方が解決しやすいのでは?となり、実践しているのが"ユースケースごとにテストデータをつくるくん"だそうです。 そして、この時には想像だにしていなかったのですが、asumikam、77webさんの同僚になり、実際にこれらを使っているのですが、めちゃくちゃ使いやすいです・・・!
- テストの可読性が実際に高い
- テストデータを作る部分に名付けされているのはデカい
- はじめての環境でもスッとテストをかける(テストデータをつくれる)
- 実際、テストを書く時になんだかんだ時間かかるの、テストデータを作る部分なので.......
- 複雑になればなるほど、そう
- たしかに、テストが重いは健在ではある
- が、テストピラミッドを適切な形にもっていくのが努力の方向として正しい
- これは77webさんも登壇中に入っていたとおり
テストデータ作成という作業を切り取って考えた時、ここに対してDRYを保ち、その結果open-closed principleだよね〜、みたいなところはすげえ良い気付きだし、登壇という形で言語化されたのありがたいな〜〜と思いました。
菱田裕美さん、登壇ありがとうございました
「オープン・クローズドなテストフィクスチャを求めて」る人と、「単体テストを書かない」人でタイムテーブルを作ったのですが、ちゃんと気づいて触れてもらえてて嬉しかったですw(そして77webさんはPHPカンファレンス小田原2025の前夜祭で、奇しくも「設計をする人」で選出され、「設計をしない人」とバトルさせられることになってます......)
asumikamは、77webさんのスライドに登場できてたいへん嬉しい限りです。 引用ありがとうございます!!!!w
明日も、お仕事でよろしくおねがいします!!!!