こんにちは。
2022年7月27日、「リーダブルなテストコードについて考えよう」という勉強会に参加しました。
非常に勉強になったので、今日はその感想として、明日から実践することを書いていきます。
リーダブルテストコード （株式会社ソニックガーデン 伊藤 淳一さん）を聞いて
↓発表で使用された資料
出典：https://speakerdeck.com/jnchito/number-vstat
テストレビューが不足しすぎていた気づき
ようわからんならapproveしちゃダメです
ギクっとしました。
正直、機能ばかりのレビューに目がいって、テストはおおよそテストケースが網羅されているなと思ったら、ちょっとわかりづらいところもあっても、approveしてしまっていました。
変数を使って自己満足していた気づき
変数を使わずに文字列や数値をベタ書きする
これも「あっ」と思いました。
伊藤さんのageメソッドの例みたいに、変数を使って書いている自覚がありました。
こちらの方がなんだか格好良いじゃんと思って書いていたのですが、伊藤さんの改善版と比較すると分かりやすさが一目瞭然で、自己満足の書き方だったなあと思いました。
コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう/オーティファイ株式会社 末村 拓也さん を聞いて
↓発表で使用されていた資料
ユーザー目線でテストを書くことの副産物
ユーザーが要素を探すときと同じ方法で要素を探したい
これに関しては無意識的に今もできているので、今後これは意識的に継続しなければと思いました。
確かにidがxxxのボタンをクリック、みたいなテストがあったらソースコード見に行って、何のボタン押されたかを確認しなきゃいけないので不都合が多いですね。
アクセシビリティの高いテストはテスタビリティも高い
なるほど！という気持ちです。
確かに「このボタンをクリックして入力して・・・」というのがスムーズにテストができ、レビュワーがそれを直感的に理解できれば、実際の操作も単純明快で直感的になっている気がします。
今までにない視点だったので大変面白いと感じました。
テストコードにはテストの意図を込めよう/株式会社ビズリーチ 風間 裕也さん
↓発表で使用されていた資料
出典：https://speakerdeck.com/nihonbuson/tesutokodonihatesutofalseyi-tu-woip-meyou
テストケース名は、「何をテストしたのか」に加えて「なぜテストしたか（意図）」を表現するべし
個人的に自動販売機の例が刺さりました。
私は「ここで何をテストしているのか書かなきゃ」という気持ちでテストケース名は書くものの、「なんでこのテストをしているのか」まで書ききれていないなーと気づきました。
面白いと思ったのは、これを書いておくことで将来修正が必要になった場合、どういう方針でテストすれば良いかまで明確になる、というのが新しい視点でした。（とある県が統合されたら、、、の部分）
質疑応答&パネルトークを聞いて
伊藤さんが「テストをDRYでなくすると、テストが落ちやすくなる（仕様変更したらその都度テストが大量に落ちるなど）というのはあるが、それはデメリットというよりも仕様変更のインパクトがあるという考え方をした方が良く、仕様変更されればむしろテストはきちんと落ちた方が良い」という旨のことを話されていたのが印象深かったです。
私はついついテストが落ちるのを嫌がってしまうところがありますが、そもそものこういう考え方が大切だなと感じました。
また、テストケース名をわかりやすく表現したい、といった参加者の質問に回答するな流れで、風間さんが「テストケース名を分かりやすく書くのが難しいと感じる場合は、テストしたいことが曖昧だったり、テストしたいことが複数ある場合が多い」とおっしゃっていたのもかなり印象深いです。
自分もRSpecでitの中身が書きづらいと感じた時などがあったら、そもそもテスト対象が十分にシンプルで明確かをチェックするように心がけたいです。
明日からやること
ということで明日からやることは、以下です。
- ようわからんテストをapproveしない
- 変数よりベタ打ちでテストする
- systemテストのクリックなどはラベル名で探す
- テストケース名にテストの意図を込める
- テストケース名がうまく書けない時はテストの対象物が十分に明確でシンプルかを再考する
