ぐんちゃ
「リーダブルなテストコードについて考えよう~VeriServe Test Automation Talk No.3~」資料置き+一言感想
見出し画像

「リーダブルなテストコードについて考えよう~VeriServe Test Automation Talk No.3~」資料置き+一言感想

ぐんちゃ

イベント概要


「リーダブルテストコード」株式会社ソニックガーデン伊藤 淳一さま


最後のページに貼ってあるリンク

感想

いまE2Eテスト書いていてDRYに書いたほうがいいのかな〜と思ってしまっていたのだが、思考停止して単に原則に当てはめようとしてしまっていたことを反省した。
後日の読みやすさを意識した上で対象に適した判断ができるようになっていきたい。

「コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう」オーティファイ株式会社末村 拓也さま


感想

ちょうど今E2EをCypressでやっているので勉強になった。
想像を減らす、相手の思考コストを奪わない、という視点はテストコードに限らず重要だが、結構コスト奪ってしまっているので色々ちゃんとやっていきたい。
Testing LibraryとContext Enclosureみてみよう。


「テストコードにはテストの意図を込めよう」株式会社ビズリーチ風間 裕也さま

感想

QAと開発者で気軽に対話して意図や認識を合わせる動きは日々できているので、テストコードにおいてもその動きをやっていこうと思った。
ローレベルのものだけ書いてあるとその具体値に意味があるのかが掴みにくくなってしまうと思ったので気をつけていきたいと青森の例を見て思った。意図をしっかり書いていきたいし、そういった動きをチーム全体でできるようになりたい。

パネルディスカッション

  • パラメタライズドテストはエクセル等で整理して、rspecでやっている。

    • 意味のある共通化をして欲しい。

    • 後日の読みやすさを考慮した上で、どうすべきかを考えて欲しい。

  • テスト設計からテスト実行までで意図を繋げるように意識している

  • 仕様書とのカバレッジ

  • 切る時

    • バージョン2が1の影響を受けたりする時に、リファクタする

    • 一番いいのは、テストを書いた瞬間。同じことを確認したいところを重ねてテストをしているところに気づきやすいタイミングであるから、そこを逃さずにリファクタリングすると良い

  • テストコードを実行する際、プロダクションコードの値をコピペしたくなるが、手入力するほうがいいか

    • 消費税計算などを例に考えると、ケースバイケースだが原則は別々のほうが良い

    • 一個一個プチプチ直す必要があるが、

    • プロダクトコードとテストコースが一緒に歩いていくと、バグも一緒に歩いていく。 別行動してもらわないと。

  • いいテストの共通認識を作っていくためには

    • 秘伝のタレ的なものがあり、新たな人もそこに染まっていってくれるイメージ

    • ベストプラクティス、アンチパターンの勉強会などをして、地道にやっている

  • モックすべき内容が多い場合どうするか?

    • プロダクトの状況による

    • mockを使う状況ということは、複雑なことを考えている状況になっている。「もっとシンプルに考えられないか」という視点で考えるといい時もあるかも。

    • テストを分割するというのは確かに手である

  • テストコードにはむしろ初めから日本語で書いて良いか

    • チームによるが、変に英語使って意図が伝わらなくなるなら日本語でいいのでは

    • コードは英語で書いている中で、テストコードだけ日本語になるケースがあるのか

      • ドメイン特有の用語が、言語の揺れに巻き込まれるのでは

      • contextの記述で英語で書いて、以降を日本語で書いており、結果困ってない

      • 誤訳を重ねるリスクがあるものはローマ字で逃げたりする

  • 実例マッピング

  • ハイレベルテストケースとローレベルテストケース

    • ハイレベルテストケースとローレベルテストケースは2段階でなく、グラデーションがある。実際の実装の仕方もそうなっていく

  • テストケース名で工夫していること

    • 「わかりやすく書く」

    • うまくテストメソッド名が書けないのは、テストの意図が曖昧、または意図を複数込めてしまっているから。

    • 意図をもう一度見つめ直すのが大切

    • 「何をテストするのか」「どうテストするのか」

      • テスト分析、テスト基本設計

      • の学び方

      • 『マインドマップから始めるソフトウェアテスト』

      • BDD

        • どう自動化するのかの話はしていない

        • 自動化するために何をテストすればいいのかを書いている

      • 風間さんチャットボット作りたい

        • JaSST Reviewの実行委員で思考を質問攻めにされる

        • うまく言語化できればチャットボットできるかも

      • VSTEP、ヘイスト法、湯もつよメソッドの一歩目で何をしているかを見るといいかも

  • ID、Class指定

    • 素早くは探索できるが、可読性を犠牲にしてでもスピードを追求したいか

    • スピードのボトルネックは他にもあるかもね

  • 皆さんから一言「明日からリーダブルなテスト書こう!まず何から?」!まず何から?」

    • 伊藤さん:コードレビューだいじ。わからないものをわからないと言える勇気。自分もできていないんだけど、自分のことを棚に上げていくこと。

    • 末村さん:読みにくいから触るのやめたいところに立ち向かう勇気

    • 風間さん:まずは自分でやってみる。そのために、モチベ維持した状態でまず明日何かしら一歩動き出す。


この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ぐんちゃ
加速中のQAエンジニアです。 ソフトウェアテストの基礎を学びつつ、ドメイン知識やスクラム・アジャイルについての知識を吸収中です。DevLoveのDiscordに結構います。