背景

過去に重要な不具合が長期間放置されていたことがある。例えば以下のようなもの。

• アーキテクチャの以降時にバグが混入し、KdB もどきからのインポートが 3 ヶ月間ほどできない状態で放置されていた
• パッケージアップグレード時にライブラリの仕様が変わり、一部のトグルボタンが半年ほど機能しない状態で放置されていた

これらに対し以下のような対策は現在あるものの、効果的ではない。

• フィードバック機能: そもそもバグがあってもフィードバックをくれる人がすくない
• Sentry でのエラー検知: throw されるようなエラーは検知できるが、そうではない前述の UI の挙動のバグなどは検知できない

またリリース毎に QA などを行うのが理想ではあるが、報酬がなくモチベーションが個人的であり、安定した開発リソースもない Twin:te の開発組織では、毎回 QA を行うのは現実的ではないと考える。

そこでフロントエンドで最低限の結合テストを行い、前述のような重大なバグをなるべく検知できるようにしたい。

テスト方針

テストで保証したいもの

最低限のユーザの行動を妨げる致命的なバグがないことを保証したい。
例えば以下のようなもの

• 授業を検索したら授業結果が表示される
• 検索結果でチェックボックスを押すと授業が選択され、追加ボタンがアクティブになり押せる

反対に網羅性の高さはなどこのテストでは保証しない。

結合テストである理由

• Unit Tests ではテストで保証したいことである「ユーザの行動フロー」を再現できない
• E2E テストが最も「ユーザの行動フロー」を再現できるが以下の理由で採用しなかった
  • ログイン周りなど、現状の仕組みではテストを行うのに難しい箇所がある
  • 過去の傾向を見るとフロントエンド内で完結するバグが多く、その対策としては、バックエンドに依存せず容易に並列化などを行える、フロントエンドで閉じた結合テストのほうが優れている

利用ツール

Playwright を使用する。この他に Cypress, Puppeteer などを検討したが、後発の Playwright が機能や使用感ともに優れていると判断したため。

詳細はこの記事などが参考になる。