j-kbt 備忘録

日々のお勉強や思ったことを残しておくもの

Bonfire Frontend #5 参加備忘録

テスト 勉強会

Bonfire Frontend #5

Bonfire 勉強会に参加したときのメモと後になって調べたこと, 思ったことを綴って行きます. 発表されてい他内容を箇条書きで, 自分の思い etc. を普通の文で書いていきます.

20200205 @Yahoo! Japan

第5回のテーマは「テストと自動化」でした. 個人的に今一番興味があり, 継続できる仕組みを作っていきたいのがテストの自動化です. 継続的に勉強をしていますが, なかなか理想とした自動化にはたどり着けていない状況もあり, 成功している人たちの話を聞いて少しでもヒントになれば良いなと思い今回の参加に至りました.

中期プロジェクトでe2eテストを導入してみて感じたこと

発表スライド

森田 勝駿さん
@texdeath
株式会社ICS

森田さんの現場でのE2Eテスト自動化についての導入事例を紹介してくださいました. なるほどなと思ったのは,

開発が落ち着いたタイミングでE2Eテスト自動化の本格導入に乗り出している

ということです. 開発最初のタイミングから後のことを見据えて取り組むのが楽なのでは? と思っていたため, この意見は割と新鮮でした. 確かにメインの開発中は忙しいですしね. 私も過去の経験上ちょっと落ち着いたタイミングで取り掛かるパターンが多かったのですが, それは妥協の産物なのかなと思っていたというのもあります.

森田さんの現場でのE2Eテストの大きな目的は以下とのことです.

工数削減は意見が分かれるところかなと思いました. ほぼ手の入らない部分のリグレッションテストについては工数削減の効果があると思いますが, ちょいちょい手が入るけど重要な部分についてはメンテナンスコストなども考えると工数的にはトントンか少し多くなるかなと私は感じています.

森田さんは工数削減のターゲットとしては以下を挙げておられました.

  • 人力では厳しいケースの検証
  • 必要なテストだけを自動化する

量が多くなると人力では厳しいケースがどうしても出てきますよね. 数百個のデータを作成してテストするとかそういった部分ですね. 手作業でテストをしている際もそういった部分はスクリプトを組んでデータを作ったりAPIを呼び出す部分を自動化したりはよくやるものです. 自動テストに組み込む際はそういったテストケースを組み込むことは私は多くないですが, 要件として必須の大事な機能であれば毎回やらないといけないので効果高そうですね.
必要なテストだけ実施するのも大事な話です. あまり重要じゃない機能で, 効果が薄いテストを実装しても費用対効果に合わないですし. どこまでやるかは組織の方針によって決める話かなと思います. グーグルの話 Advances in Continuous Integration Testing at Google によると一部のテストを除いてすべてのテストが自動テストになっているといった話ですが……. 日本ではここまでできている企業は聞いたことないですし, なかなかに難しい話かなとは思います.

必要なテストの中でも, 同じことを何度もやらなくても良いというのはQAの心理的負荷の軽減効果はあると思っていて, 実はそれが工数削減につながっているかもしれないというのはそうかも知れません.
私が所属している組織では当たり前かもしれませんが, QAのチェックが入っていないものは原則リリースできないルールですが, 一部簡単な変更についてはQAチェックをスキップすることもあります. この「簡単な変更」の範囲をE2Eテストを整えることにより広げることは可能かもしれません. これがうまく回ればテスト工数の削減やリリースペースの加速につながるかもしれませんね.

次に, 自動テストのモチベーションとして挙げられていたのは品質向上です. 狙いとしては以下の2点がメインでしょうか.

  • 探索的テストにリソースを回す
  • システム稼働中でも一定の品質を担保したい

システム稼働中のリグレッションテストとして自動テストが活躍する部分があるということは間違いないと思います. 工数削減の話と共通的に語られる要素です. リグレッションでバグが出てくるパターンはそこまで多くないですが, この手のテストを気軽にできるのは, 気軽に変更を加えることができることにもなります. 開発を早めながら品質の高いものを届けることにつながるのではないでしょうか. ただ, このリグレッションの範囲を決めるのが面倒なんですよね. 自分が試しているのはバグが発生しがちな箇所にのみ注目している方法です. 面倒なテストを繰り返さなくていいメリットはあるもののカバー範囲が狭いため大きな効率化にはなっていないかもしれません. 探索的テストにリソースを回すのはいいアイディアだなと思っています. テストから見えてくる グーグルのソフトウェア開発 でも言及されていましたが, テスト自動化する部分と探索テストをする部分が分けられていて, 多くの人が探索的テストを実施しているらしいです. ただ, この本によると, 探索的テストがきちんとできるスキルセットを持った人材が非常にたくさんいる場合効果が高い方法かなと思いました. テスターの人数が少ないときにどれくらいの効果が上がるのか少し気になります. ここらへんは自分の所属する組織で自動化が拡大できたときに検証してみたい項目です.

最後のモチベーションとしては, ベストプラクティスを模索して別案件にも活かせるようにしたいといった部分です. これは私の組織でも一部のチームではできているものの展開できるような形になっていない部分もありなかなか組織全体に行き渡らない現実があります. 先駆者がこういったことを頑張ってくれるのは非常にありがたいことだなと思います.

  • テストベストプラクティスの模索
    • 別案件にも活かせるように動きたい

テスト環境は以下.

  • テスト環境
    • Lang: TypeScript
    • View: React
    • Test:
      • Jest
      • Enzyme
        • React に力を入れている Airbnb が開発したテストユーティリティ
      • puppeteer
        • DevTools Protocolを介してヘッドレス Chromeを制御するためのNodeライブラリ
      • jest-puppeteer

導入にあたって気をつけていた点として以下を挙げられていました.

  • 自動化に比重を置きすぎないようにする
    • クリティカルな部分のみ
  • テストピラミッドを意識した設計

自動テストを適用するときによく話題になることがテストピラミッドに沿って実施するテストを全体で考えましょうといった話があって, E2Eテストの比重を大きくしてもテストの実行速度が遅いであったり, E2Eテストは画面のちょっとした変更でよく壊れるため不安定, といった話があります. 最終的にはブラウザやアプリで動いているものなので, ブラウザテストを頑張りたい気分もわかりますが, ここでは安定しているテスト = ユニットテストを多くしてE2Eテストの比率を下げましょうといった話が出ていました.

森田さんが発表していた通り, クリティカルな部分(機能的に重要な部分, 効果が上がりそうな部分) を自動化し, テストピラミッドに従った動きにすることは大事かなと思います.
また, 同じテストを重複して書かないということはテスト全体で計画しないと忘れてしまうことが多く, 重複するのであればまだマシな方で, どこでもテストされないといったパターンが一番怖いです. エンジニアがユニットテストまで, そこから先をQAがテスト実施みたいな組織だと予めどこからどこまでテストをするか決めておかないと重複しますし, テスト漏れが発生します. 当たり前ですがテスト計画は非常に重要です. それは自動化しようがしまいが同じことですね.

最初の方で発表されていたとおり, 自動化したい観点は「人力では辛い」, 「最低限必要な観点(多分ここだけは外したくないポイント)」であり, 以下のポイントを挙げられていました.

  • インプットフォームの操作
  • 最小・最大ケースでの正常送受信
  • シナリオの前提条件があるケース
    • 複数項目操作によって要素が変わる
    • データの仕込みや状態の準備が大変なもの
  • フォームのバリデーション発火後の動作
  • 送受信データの対称性確認
    • これは案件特有の観点らしいです

そして, 上記に従い自動テストを導入した感想として以下を挙げられています.

  • 導入までなら簡単
  • 自動化するとモチベーションが上がる
  • 正しく書くことができればそれなりに効果的

ただ単にテストを動かすだけだと結構できてしまうのは同意で, 難しいのは継続的に運用したりメンテナンスしたりすることが大変かなと思います. また, 効果を出す(やってよかったね)を継続的にすることも難しいのではと感じています. 結局の所, 良いテストをする人が良いテストを書けたりするので, そもそものテスト設計能力が求められるんだよなと思う次第です. 皆さん, 教育とかどうやってるんですかね.

感想と対になりますが, 苦労している点です. これは途中から導入した場合の苦労のポイントに一致するなと思いました. これがどうにか解決してくれないですかね, と私も思います.
結果の出力はどんな形が最適なんでしょうか. これも組織の成熟とともに検討する項目なのかなと思いました.

  • 現状のコードではセレクタがほとんどclass属性しかついていない 選択肢が少ないと抽象化が大変
  • コンポーネント作成の時点でdata属性を付与するなどの対応をする必要がある
  • 結果の出力にも工夫がいる

最後に, 今後についてもお話をしてくれています.

VRTは自分も実践したことがないのですが, いろんな方がすでに実践されているため, 効果が高い方法なのかなと想像しています. 今度試してみよう……. クロスブラウザ対応は大変です. 今私は手動でやっている部分が大半なのでこれをどうにかしたいなという気分があります. うまくいったら記事にしてみたいですね. 技術スタックは異なる部分も多かったですが, 非常に参考になる発表かなと思いました. 私も一旦基本に立ち戻って自動テストに取り組み直してみたいなと思いました.

Vueのテスト手法とVRTのすすめ

発表スライド

おとべ/unotovive @unotovive ◆ 株式会社ゆめみ

おとべさんは Vue の VRT(Visual Regression Test) についての発表をしてくださいました. 最初に, テストをどれだけ書くか(実施するか) についてを話されていました.

  • フロントエンドに自動テストは必要か
    • 案件の重さとテストの重さで判断する
    • 必要なテストかどうか取捨選択する必要あり

勝手な予想ですが, あくまでも自動テストの話かなと思いました. いくら小規模の案件でも手動でテスト実施しますし, テスト実装してまで確かめたいかみたいな感じかなと思います. 大規模案件になると実はテスト実装の量が多くなり取捨選択が必要になるため難しいのもそのとおりかなと思いました.

続いて Vue のテストについてのお話です. まずは単体テストです. このあたりはあまり取り組んでいない部分だったため, 初耳な部分が多かったです. 単体テストで効果がある部分, ない部分については概ねそのとおりかなと思いました. Vue Test Utils が非常に有用に使えるといったことを説明されていました.

続いてはE2Eテストです.

  • E2Eテスト
    • Vue独自のなにかがあるというわけではない
    • QAを介さない場合についてはあると便利かもしれない

E2Eテストについてはなかなか面白い観点で話しているなと思いました. 私の所属する組織でも, 単体テストまでは開発が行い, そこから先をQAがテストしているため, E2Eテストについてはお任せになっています. そのため本発表でもE2Eテストについてはサラッと話されていました. そして最後にE2Eテストの一部ではあると思っていますが, VRTの説明です.

  • VRT(Visual Regression Test)
    • 今のスクショと前のスクショを比較して見るもの
    • 1pxのずれを検知
    • 予期せぬ差分検知もある.
    • ブラウザを開いてスクショを取るのでそこそこに重い

VRTは実践したことがないので, 以前から少し興味に思っていたテスト手法です. 画像差分を取るものであるため, 非常に細かい単位(1px単位)での差分を検出できます. 他の発表でも言及されていたのですが, Webページにランダムに表示される部分などがあるとそれだけ多く検知されてしまうものでもあり, 運用法はきちんと検討しないと難しいみたいです. ただし, おとべさんがおっしゃるようにうまく使えばよきせぬ崩れを発見することができ非常に便利なツールとなりそうです. この方法をVueで適用する場合について主に紹介してくれていました.

  • Vue では？
    • Reg-suit + storycap いい感じにVRTをやってくれる
      • レポートを S3 などに上げて自動共有してくれる
      • 日本人がまとめてくれている部分もあり, ドキュメントがとても充実している
    • Storybook のストーリー単位で見ることができる
    • PR時にCIで動作して GitHub や Slack にレポートを送信してくれる
    • VRTが適しているのは
      • 中規模以上のアプリケーション
      • 大量にコンポーネント分けしている場所
      • 新規メンバーが居る場合
        • これは最終的な気付きとして利用

新規メンバーが居る場合, ちょっとした修正でもレイアウト崩れが起きる場合があるため, 確かにこの仕組で検知できるのは便利だなと思いました. 後は, 実行時の負荷や実行時間を考えてどこまで導入するかを決めれたらいい感じかなと思いました.
ただ, ランダム要素があるページだと少しテスト難しいなとも同時に思いました. そういった場合, 皆さんどう対処されているんですかね.

Yahoo! JAPAN トップページ リニューアルとテストについて

発表スライド

西村 宗親 ◆ ヤフー株式会社

まずは, Yahoo! Japan トップページをどのように作り変えたかの説明となりました.

次に, テスト方針についてのお話です. 自動テストを考えるときにやはりどの組織でもテストピラミッドの話は出てきますね. カバレッジ100%を目指すかどうかはプロジェクトごとに決まってくる話かなと思いました. ただ, 100%にするために労力ばかりかかりリターンが少ない場合も多々あるのでそういった観点だと程々にを最初に表明することはプロジェクトメンバーにとってもいいことかなと思います.

テストの技術スタックについてもお話がありました.

  • Unit Test
    • Jestを採用
      • razzle test実行=jest実行 であるため
    • Jest
      • jsdom利用によりブラウザ不要で高速なテストが可能
      • スナップショットテストが可能
      • test-runner, mock, coverage, assertionのすべてがある
    • React Component Test
      • react-testing-library
    • React Hooks Test
    • スナップショットテストの工夫
      • Storybookを利用しているのでStoryshotsを利用
      • コンポーネントテストとStorybookの両方の記述は無駄

また, おとべさんと同様に reg-suit のお話がありました. 予期せぬ変更の検知や時系列による変化があるものだと意図しない検知となるため, 工夫が必要そうです. また, 内容として驚いたのは, 画像のロード遅延により, 画面のスクリーンショットが変化するため, 差分検知されてしまうものです. この手の環境関連の問題は自動テストとして運用していると, 非常に不安定な部分でありなかなか取り扱いが難しい部分なのかなと思いました. この事象への対処はどのようにやってるんですかね.

  • 実際の見た目の比較
    • reg-suitにより UI変更の差分を検知
    • 予期せぬ変更の検知
    • 時系列により変化するもの
    • 画像ロード遅延による検知もある

E2E テストについては簡易に実施されているみたいです. クロスブラウザチェックは実機確認がメインのようです.

  • E2E テスト
    • jest-puppeteerにより簡易的に実施
    • クラスブラウザチェックは実機で十分可能であるため, 実施していない

最後にテスト自動化部分の技術スタックを教えていただけました.

  • CI/CD
    • GitHub Enterprise
    • Hosted Danger
    • Screwdriver.cd
      • Yahoo! Inc. で開発された CD パイプライン用の OSS

おわりに

どこの会社でも自動テストが普及してきたかのように感じます. いろいろなフレームワークや技術があるため, 一つ一つキャッチアップしていくのは大変かなとは思いますが, これからも精進していきたいですね.