「フロントエンドのテストは“不安定さ・壊れやすさ”との戦い」　和田卓人×倉見洋輔×古川陽介が語る、アクセシビリティの重要性

今活用しているツールを紹介

古川陽介氏（以下、古川）：今、具体的にいくつかツールや考え方が出てきました。今聞いているみなさんはおそらく、「じゃあ、どれを使ったらいいんだろう？」とか「何をしたらいいんだろう？」となっているかもしれないですが、倉見さんにお聞きします。ずばり私たちは今何をやっているでしょうかというところで。例えば……。

倉見洋輔氏（以下、倉見）：すごく話を誘導されている感もありますが（笑）。

古川：そうですね（笑）。誘導しているんだけど。

例えば、先ほど言っていたHTMLとかそういうのをスナップショットでテストしているとか、もしくは、見た目の部分でテストをしているとか、そういうところでどういうことをやっていますかと聞いてもいいですか？

倉見：宣伝の場をいただきありがとうございます（笑）。特に見た目に関する層のテストではいくつか活用しているツールがあります。

1つはやはり、「Storybook」ですね。これは、与えられた入力に対して与えられたHTMLを再現するためのテストコードとして使っています。

それに組み合わせて、自動テストをするためのツールとして自分で用意しているものがいくつかあります。「Storycap」と呼ばれる、Storybookを自動実行して、スナップショットを吐くためのツール「reg-cli」という、それらを比較してCIで通知をしたり、いわゆる普通のテストの開発ワークフローとして扱うためのツール。

これは僕が作ったというよりは、僕と昔の同僚で作っているツールなんですが、このあたりを組み合わせて、現場に導入しているケースがけっこう多いです。

あと、たまたまなんですが、今入っている現場に関しては、僕が行く前から、先ほどの画像のスナップショットを比較するツールが勝手に入っていて、けっこうありがたかったですね。

古川：そうですね、倉見さんが今、実際にやっている現場では入っていましたね。

倉見：勝手に入っていたのでびっくりした。

古川：勝手に入っていた（笑）。しかも倉見さんが使っているツール「reg-suit」「reg-cli」的なところが入ってくれていた。

倉見：そのあたりを使っています。

古川：出力のところはそれを使っているというところで、通信部分というか、データをモックしなきゃいけないというところは、今は何をやっているんですか？

倉見：一番根っこで使うツールとしては、いくつかはあるんですけど。僕が今やっている現場は、先ほどのスキーマの話で言うとGraphQLが大部分を占めています。GraphQLって、やはり型が最初からついているのがすごく特徴的で、間違ったJSONを書いた場合、TypeScriptが怒ってくれるんですね。

例えば、年齢というものは、数字なのか文字列なのか。1個間違うとけっこう悲しいことになるところも、GraphQLが守ってくれる。先ほどt-wadaさんがおっしゃた静的な型検証と組み合わせて、人間がJSONみたいなものを書いているという感じで作っていますね。一部、GraphQLじゃない通信もあって、そういうところはスキーマがけっこう弱かったりするので、先ほどのMSWみたいなものを使って、そのテストで「こういうリクエストとかを期待しているんだよ」ということをなるべく増やしていく感じで補助的に使っていますね。

古川：スキーマを定義するGraphQLとかって、モックとしてスキーマの例を出すのがMSWという位置付けで合っていますか？

倉見：あぁ、いえいえ。そこはぜんぜん分離しています。GraphQLとMSWは関係なくあって、すべての通信がGraphQLであればいいんですが、一部、GraphQLの手前で行わなきゃいけない通信は、そういう型のガードがなにもないので。

古川：あぁ、そういうことか。

倉見：MSWを使ってテストを書く時に、少なくともフロントエンドはこういう期待をしているんだよということを、なるべくコードでわかるようにしているぐらいの話です。

古川：今の現場が、全部GraphQLというわけじゃないということですね。一部は残って……。

倉見：そうですね、本当に一部、GraphQLじゃないものを使わなきゃいけないシーンが出てきた時に、という感じですね。

古川：その時に、GraphQLにできればいいけど、必ずしもできるものではなかったり。

倉見：そうです。

古川：既存のAPIが残っているとそうなっちゃいますよね。それが基幹的に使われているAPIだとなかなか難しいところもあり、そういうのはMSWとかと併用してやっていこうとしているという。なるほど。

私たちの開発の現場で言うと、だいたいそういう感じになってきている気がしていて。GraphQLを必ずしも入れているわけではありませんが、それに類するスキーマみたいなものを定義した上で、モックも含めて開発をして、わりとフロントエンドはフロントエンドの中だけで完結できるように作っていったり。

かつ、先ほど倉見さんの紹介にもあったとおり、Storybookというツールを使ってコンポーネントをカタログ化していて、そのカタログの内容に差分が出ないようにビジュアルリグレッションテスティングを、Storycapとreg-suit、reg-cliをうまく併用して実施しています。

それに加えて、スナップショットテスティングもおそらくやっているのかなと思います。

フロントエンドテストとアクセシビリティの関係性

古川：ちなみに、今後でいくと、わりと倉見さんや、ここにはまだ来ていませんが、Takepepe（吉井健文氏）さんが、最近アクセシビリティをけっこう推している気がしています。

その部分について、テストの文脈でどうやって担保していこうとか、そういうことはあったりするんですか？　これって、どっちに聞いたらいいかな？　じゃあ、和田さんに聞いてみましょうか。

和田卓人氏（以下、和田）：フロントエンドのテストの今後の話で言うと、ここまでで、再現性があって比較的安定するCIを回すという基盤はできてきたんですが、それでもやはりフロントエンドのテストというのは、基本的には「不安定さ、壊れやすさとの戦い」なんです。

不安定さというのは2つあって、1つは実行基盤による不安定さ。テストコードもプロダクトコードもまったく1行も変えていないのに、成功したり失敗したりするようなテスト。こういうテストを「フレーキーテスト」というんですが、そういうフレーキーさというのを、例えば全体としてどうやって1パーセント未満に抑えるかというような戦いであったり。

あと、もう1つは、プロダクトコードのほうがどんどんどんどん、いい意味で変わっていく、画面がどんどん変わっていくから、既存のテストコードが失敗してしまう。当たり前ですね。テスト対象が変わったから失敗する。

コードは悪くないのにテストが失敗するフレーキーさは、より安定した実行基盤や、タグを付けて別枠で管理するとか、そういったかたちで避ける努力をしていくわけですが、プロダクトがどんどんどんどん変わっていきたい時にテストが壊れちゃうと、「テストが壊れちゃうからこっちの画面を変えるのをやめようかな」って思ったり、「テストが壊れちゃうからそのまま放っておこうかな」って思ったり、そういった良くない力が働きます。

いい意味で変わっていくテスト対象に対して、どうやって影響されにくいテストコードを書いていくかがとても大事で、その観点で非常に今アクセシビリティに光が当たっています。

アクセシビリティが高い＝テスタビリティも高い

古川：そうですね。見た目だけテストしようとするとフレーキーになりがちなところを、見た目ではなく、きちんとアクセシビリティ上で意味のあるもののまとまりとして考えていくというところで、やはり、アクセシビリティにテストの光が当たっているんですね。

和田：従来、アクセシビリティはどうしても、大事なことにもかかわらず優先度が下がりがちな要素だったのですが、アクセシビリティの高い画面は、壊れにくいテストが書けるようになってきたんですよね。

そうなると、アクセシビリティが高いということは、つまりテスタビリティも高いということです。テスタビリティは、開発する速さや安定さに強く影響する要素ですから、回り回って、アクセシビリティを高めるということは、チームの開発を速くするし、安定させるというかたちになってきたというのは、とても大きいですね。

古川：アクセシビリティと聞くと、やはりどうしても目があまり見えない方とか、手があまり使えない不自由な方に向けてとか、そういう話になりがちではあるんですが、それだけじゃなく、単純にメンテナンス性能を上げるためにも、HTMLの意味の部分にきちんと沿った内容を組んでいけば、それに対してのフレーキーを防げるわけだから、加えて言うと、そういうところにも効果はある。

障がいを持っている方にも多少の効果はあるというところもあって、一挙両得なんだし、やっていくほうがいいよねという流れが今来ているのかなと思っていて、個人的にそれは、すごくいい流れだなと思っているんですよね。

アクセシビリティという非機能要件だけではなく、開発の生産性を上げていく

古川：それはそれとして、今、倉見さんがやっている案件の中では、そういうこともやっているんでしょうか？

倉見：昨日、Storybookを自動で動かすテストをちょっとみんなで書いてみようぜと話をしていた時に、自動で動かすというところの技術要素に、いわゆるアクセシビリティに関するもの、「Aria」とかそういうやつを使おうとしていて。

それをやったメンバーはあまりそういう技術のことを知らなかったんですね。その人から「それを学んでみたいと思ったという気づきがありました」みたいなフィードバックをもらいました。

逆なんですよ。テスタビリティから攻めていったら、フロントエンドエンジニアがアクセシビリティを勉強する機会になったといういい話がちょっとあったので、紹介しておきます。

古川：そうですね。午前中のセッションの鉄平さん（佐藤鉄平氏）の話もすごくいい話だなと思いました。会社のビジョン、ミッションから、会社の哲学である「チームワークを大事にしよう」というところを踏まえて、そこからアクセシビリティという非機能要件に対してアプローチをしていった。そういうことがわかってくる。

それはそれですごく大上段からのアプローチで、メチャメチャいいアプローチだなと思う一方で、やはり戦い方は1つじゃないよなと思っていて。アクセシビリティを担保するためのもう1つのアプローチは、「開発の生産性を上げたり、そういうところにもすごくいい影響があるんですよ」というところから、ボトムアップに上げていくという活動。これができるようになると、結果、トータルも良くなってくるし、それが2種類の意味で良い影響があるなと思ってはいるんですよね。

だから、ボトムアップ、トップダウン、両方のアプローチできちんと、アクセシビリティという非機能要件だけではなく、開発の生産性を上げるというところですごくいい事例が作れていっているなと僕は感じていますね。リクルートの中ではというところではありますけど。

ありがとうございます。ちょっと時間がね（笑）、あと20秒になってしまって。もっと話したかったんですけど、ここでいったん切ろうかなと思います。

僕としては非常に、前半とはまたぜんぜん違うおもしろいトークができたなと思っています。引き続き、こういうかたちでまた話せればなと思います。

以上でいったんこの「テスト最前線」のセッションは終了いたします。どうもありがとうございました。

和田：ありがとうございました。

倉見：ありがとうございました。