こんにちは、freee人事労務でQAエンジニアをしているkairiです。freee QA Advent Calendar2024 21日目です。 今回はプロジェクトの中で実際にあった、不足しているテスト（自動テスト）をQAが書いてサポートした事例、およびそこからシステムの内部構造に踏み込んだ改善提案をした事例を紹介します。
きっかけ
複雑な表示ロジックを持つUIのリファクタに関わることになった際に、パターンが多すぎて目でチェックすることが非効率に感じたことがあり、なんとか楽ができないかと考えました。
しかし該当箇所には複雑な表示ロジックを持つ割に自動テストが存在しておらず、自動テストを書いてもらおうにも開発エンジニアメンバーの工数には余裕がありませんでした。QAエンジニアもプロダクトコードにアクセスできるため、それならば自分で書いてみようと思い立ちました。（その是非には色々ご意見があることと思います）
E2Eも候補になりましたが、今回はあくまでUIコンポーネントの表示ロジックの確認なので除外となりました。またコンポーネントの単体テストも同様に強力な候補に挙がりましたが、その後のメンテナンスコストも考慮してすでにプロダクト内に広く採用されているスナップショットテストを採用することになりました。
スナップショットテスト is 何
知ってるよ、という方はこの項を飛ばしてください。
スナップショットテストとは、UIの出力が意図した通りであることを検証するためのテスト手法です。特にフロントエンド開発で使われることが多く、出力結果の「スナップショット（瞬間の状態）」を記録し、それを基準に変更がないかをチェックするテストです。
UIに意図せぬ変更が入ってしまった場合に、自動で検出することが可能です。
スナップショットテストを書くまで
私自身前職までは開発業務に携わっていたのである程度コードを書くのには慣れているのですが、Reactのテストに触れるのは初めてだったため色々勉強しながらの作業になりました。テストにはStorybookおよび、そこから生成できるスナップショットを使用しています。
スナップショットテストを書くにあたって、該当コンポーネントがテストしやすい構造になっていないという問題に当たりました。DB通信などテストの時起動していない外部依存がコードに存在するとテストは落ちてしまいます。これについてStorybookの公式がモックのやり方を提示してくれているのですが、これを実現するにはプロダクトコードに手を入れる必要があり少々リスクがあります。そのため人事労務内では基本的に外部への依存は別のクラスに出し、UIコンポーネントは与えられた値を表示するだけにしています。今回実装対象としたコンポーネントはこの構造になっていませんでした。 これについては開発エンジニアにテストの必要性を説明し、テストが書きやすいようにコードを手直ししてもらいました。
その上で、実際のコードを読みながらStorybookのパターンを作成していきました。結果として、一つ一つデータを用意して目視で確認するよりは遥かに早く確認することができました。Storybookさえ作ってしまえば、スナップショットはコマンド一つで作成することができるので簡単です。スナップショットテストはCI/CDに組み込まれているので、スナップショットが作成されていれば自動でテストされます。
これについて、テストコードが将来的に役に立つ以外にも良かったと思うことがたくさんありました。
- スナップショットテストに対する知見をえた
- プロダクトコードの内部構造に詳しくなった
- 手動のテストケースを一部省略できた
など。
コードの構造がバグを生みやすくなっている
該当のUIコンポーネントは障害とまではいかないものの、バグ（フリーではハッピーと呼ばれます）が発生しやすい箇所となっていました。そもそもの話フロントにそこまで複雑なロジックを持たせるべきではないのですが、現状としてそうなってしまっています。 本来であればその箇所をリファクタリングして表示に必要なロジックを切り離し、切り離したロジックに対して単体テストを書くべきです。…という旨を開発チームに提案もしました。
同意は得られた一方でやはりなかなか工数がない関係上すぐに対応するのは難しいのですが、品質に関わる問題でもありますのでQAからも後押しをしていきたいと思っています。
また、そのリファクタにおいてもQAエンジニアという枠は超えてしまいますが必要であれば自ら行えるように知識を身につけていきたいです。
テストコードから開発に貢献する
周囲のQAエンジニア内で「単体テストを含む自動テストについてもっと詳しくなりたい」「内部構造に詳しくなりたい」「コードが書けるようになりたい」という話を聞くことがありますが、そういった需要をテストコードは満たすことができるように思います。
QAが関わることが多いテストといえばE2Eテストが挙げられますが、より内部に深く食い込んで品質に関わりたい場合は単体テストやスナップショットテストもおすすめできます。
たとえば、テストで使うデータのパターンを組むのにはQAは慣れているはずですから、テストすべきパターンが漏れていないかを確認するだけでも開発に貢献できます。さらに、実際にテストコードを変更してみたところでプロダクトコードに影響は基本的にありませんので、バグを起こしてしまうリスクも避けられます。さらに、前の方でも書きましたがテストコードを書くにはある程度内部構造が読めていないと書けないので、コードを読む訓練になります。
もちろんプロダクトコードを読むのには一定のハードルがありますが、それが出来ると結構なアドバンテージになりますので、トライしてみる価値はありそうです。
終わりに
まだまだプロダクトコードの理解がし切れていない部分もあるのでその部分については勉強しつつ、他のメンバーにも技術を伝えていきたいです。
明日はコアエンジンのina-chanが「新卒QAのすゝめ」について書いてくれます。お楽しみに！
それでは、良い品質を〜
