🖥️

勉強会「リーダブルなテストコードについて考えよう」に参加した

2022/07/27に公開約1,700字

勉強会「リーダブルなテストコードについて考えよう」に参加してきたので気づきや感想をアウトプット

https://veriserve-event.connpass.com/event/243280/

勉強会の資料

勉強会で発表されたお三方がスライドを公開してくださった、ありがたい

https://twitter.com/masa_okamoto1/status/1552271420503506944?s=20&t=DOtabg49w8lvavEDQW6gVw

気づき

プログラムを書くというよりはドキュメントを書くつもりで

https://speakerdeck.com/jnchito/number-vstat

https://twitter.com/masa_okamoto1/status/1552244963811131394?s=20&t=DOtabg49w8lvavEDQW6gVw

テストは仕様書という言葉はよく聞くと思うしそのとおりだと思う。
非エンジニアが見ても理解できるように書かれてのが理想形だ。(もちろん完全には難しいが)

  • 過度にDRYにしない
  • 変数展開少なく上から下へ読める方が脳内メモリ消費少ない
  • APIドキュメントとかが参考になる

DRYにしてはいけないというのではなく、過度に DRYにしてはいけないというのが重要
Shared examples とか無意味に乱発して、オレかっこいいやってない?

シナリオテストでは想像をなるべく減らす

https://speakerdeck.com/tsuemura/kontekisutotosemanteikusuwoyi-shi-siteridaburunae2etesutokodowoshu-kou

https://twitter.com/masa_okamoto1/status/1552246764346183681?s=20&t=DOtabg49w8lvavEDQW6gVw


参照元

  • 画面遷移などを伴うので、今どこのページにいるのか、どのケースなのかという文脈がわかると良い

テストの意図を込める/引き出す

https://speakerdeck.com/nihonbuson/tesutokodonihatesutofalseyi-tu-woip-meyou

https://twitter.com/masa_okamoto1/status/1552255109777993728?s=20&t=DOtabg49w8lvavEDQW6gVw
  • テスト実装者は自分の頭の中で考えて意図を込めてテストを書いているつもり、でもそれちゃんと伝わるかな?
  • テストコードレビュー者は会話を通じて真意を引き出せる
  • QAエンジニアとも連携してもっといろいろできるのではないかと思った

まとめ

発表後のセッションの締めくくりに「明日からリーダブルなテストコードを書くには」というお題で発表者より一言ずついただいた。

https://twitter.com/masa_okamoto1/status/1552268462428659712?s=20&t=DOtabg49w8lvavEDQW6gVw

学んだことは素早くアウトプットを!ということで早速サラッとこの記事を書いた。
あと、テストに関わらず、コードレビューでは自分のことは棚に上げて良い これめちゃ大事。

素晴らしい勉強会開催&発表ありがとうございました。

Discussion

ログインするとコメントできます