はじめに
こんにちは、CommuneのGlobalチームのテックリード、Alekseiです。この記事では、アーキテクチャ変革に続くテスト戦略について説明します。アーキテクチャの決定について詳しく知りたい方は Series #2 を、管理の観点についてはチームリードのyoshifumi.kondoが書いた Series #1 を参照してください。
前回の記事では、レイヤードアーキテクチャをコロケーテッドアーキテクチャに変革し、並行開発を可能にし、Next.jsの規約とベストプラクティスに沿って開発できるようになった経緯を共有しました。しかし、アーキテクチャだけでは成功を保証できません。良いコードには良いテストが必要です。
この記事では、戦略的なテスト概要を紹介します。各テストタイプの詳細については、専用の記事で説明します。また、この記事は自動テスト戦略のみに焦点を当てています。手動テストとQAプロセスは、QAチームが担当しており、この議論の範囲外とさせていただきます。
出発点：初期のテストアプローチ
管理画面置換プロジェクトが開始されたとき、テストは私たちの強みではありませんでした。複雑な機能に対していくつかのユニットテストと統合テストがありましたが、一貫した戦略が欠けていました。明確なガイドラインがないため、各開発者は異なる方法でテストにアプローチし、一貫性のないカバレッジと実践につながりました。
プロジェクトの初期段階では、この非公式なアプローチは迅速なプロトタイピング段階と一致していました。何が可能かを探求し、迅速に反復し、各デプロイメントから学んでいました。いくつかの問題が本番環境で発生していましたが、グリーンフィールドプロジェクトとして、これは「早くリリースして後で修正する」開発プロセスの一部でした。
開発者の観点から見ると、このアプローチは士気を下げかねないものでした。問題が発生したとき、適切な知識を持つ誰かが修正するのに数日待つこと必要性がありました。このフェーズにはコストがかかり、開発者にとってもはストレスの一つでした。
プロジェクトが成熟するにつれて、状況は劇的に変化しました。今や実際にユーザーにサービスを提供する本番環境対応のコードがあり、改修においてそれに影響を与えることは、許容できない状態になっています。さらに今後1〜2年以内に、コンポーネントライブラリ全体を新しいものに置き換える可能性があることがわかりました。適切なテストインフラストラクチャがなければ、この移行には、たとえ自信を持って完遂できる場合であっても、無数の手動テストが必要になります。
私たちは最終的に、現在のアプローチではスケールできないことに気づきました。
前進：テスト戦略の構築
テストがない状態が明らかに持続不可能だったため、より良いものを構築する必要がありました—しかし、何を？課題は、特定のコンテキストに適したアプローチを見つけることでした。
テスト目標の設定
プロジェクトの現実に合わせてテスト戦略を調整することから始めました。
私たちの管理インターフェースは本質的に洗練されたUIレイヤーです。すべてのビジネスロジック、バリデーション、データ処理を処理する、よくテストされたバックエンドからAPIを消費します。私たちの仕事は：
- データを取得して正しく表示する
- ユーザーインタラクションとフォーム送信を処理する
- UI状態とナビゲーションを管理する
- 適切なスタイリングとコンポーネントを適用する
フロントエンドで複雑なアルゴリズムやビジネスルールを実装していないため、テストのニーズはフルスタックアプリケーションとは異なります。しかし、これは確立されたテスト原則を無視できるという意味ではありません。
私たちの目標は、"Unit Testing Principles, Practices, and Patterns"のようなリソースに見られる業界のベストプラクティスと一致しています。そのため、特定のコンテキストを適用するだけです。
もう一つの重要な制約 は、決められた締め切りがあること。完璧なテストスイートを構築する余裕はなかったため、開発者が迅速に実装でき、それでも価値を提供できる実用的なものが必要でした：
- テストは書きやすく保守しやすくなければならない - 複雑なセットアップや洗練されたルールなし
- テストはコンポーネントライブラリ移行を容易にすべき - 移行中の視覚的および動作の変更をキャッチ
- テストはリグレッションを防ぐべき - 開発者に変更が既存の機能を壊さないという自信を与える
出発点：スモークテストに全てを賭ける
締め切りを念頭に置いて、実用的な選択をする必要がありました。締切もあったため、最初はE2Eスモークテストを全面的に採用しました。
- 複数のコンポーネントと機能をカバーする1つのE2Eテストを書ける
- 経験していた本番障害をキャッチできる
- 1つのテストタイプは1セットのドキュメントとトレーニングを意味する
「テストがある」チェックボックスへの最速の道のように思えました。
包括的なスモークテストガイドラインを開発し、チームに展開しましたが、見えてきた現実は厳しいものでした。テストは：
- 不安定で信頼性がない（特に複雑なUIインタラクションで）
- ローカル環境で確実に実行するのが困難
- 開発者に実際のフィードバックを与えるには遅すぎる
バランスの発見：現在のテストスタック
幸いなことに、ここでakfmさんの記事"フロントエンドのユニットテスト観点を整理する"が私に必要なフレームワークを提供してくれました。
私たちは次のテストピラミッドに方向転換しました。これは従来のテストピラミッドとは異なります。ユニットテストを大規模な基盤とする代わりに、UI中心のアプリケーションで実際に価値を提供するもの—コンポーネントテスト—に基づいてレイヤーのサイズを決定しました：
- Storybookコンポーネントインタラクションテスト - より速く書け、即座に実行でき、構築しているものを正確にテスト
- ビジュアルリグレッションテスト - 開発者の追加作業なしに実行される自動スクリーンショットで、リグレッションをうまくキャッチ
- ユニットテスト - ユーティリティ関数と複雑なUIビジネスロジック用
- E2Eテスト - スモークテストにはまだ用途があると信じており、リリース前のステップとして残しましたが、もはや有効なものではありません
この組み合わせは、開発ワークフローと完璧に一致しました。開発者は、異なる状態やインタラクションを視覚化するためにコンポーネントを構築する際にStorybookストーリーを書きます。インタラクティブテストとVRTにより、これらの同じストーリーが動作と視覚的な外観に関する即座のフィードバックを提供することで、テストは、自然な開発プロセスの中の一部になりました。
目標の達成方法
書きやすく保守しやすい: 開発者は開発中に自然にStorybookストーリーを書きます。これらのストーリーは、最小限の追加作業でインタラクションテストとビジュアルテストに自動的になります。
コンポーネントライブラリ移行サポート: VRTは視覚的な変更を即座にキャッチします。コンポーネントインタラクションテストは、基礎となる実装を交換しても動作が一貫していることを保証します。
開発者の自信: Storybookテストからの即座のフィードバックにより、開発者はPRレビューや本番環境ではなく、開発中に問題をキャッチできます。焦点を絞ったピラミッドは、テストの作成時間を減らし、機能の出荷時間を増やすことを意味します。
締め切りフレンドリー (願わくば): 最も重要な場所（コンポーネントの動作）に努力を集中することで、大規模なユニットテストやE2Eスイートの保守という時間の浪費を避けながら、重要な場所で包括的なカバレッジを達成します。このトレードオフがうまくいくかどうか、今後の結果に期待しています。
まとめ
テストの歩みを振り返ると、限定的なカバレッジや本番環境での問題から、包括的なテスト戦略の確立へと至るまで、その変化は実に大きなものでした。「完璧な」テストアプローチは存在しないことを学びました。大切なのは、チームの特性、制約、そして目標に最も適した方法を見極めることです。
主な学び：
- 制約を受け入れる: 締め切りのプレッシャーは、実際にワークフローを改善した実用的な選択につながりました
- 適切なレベルでテストする: UI中心のアプリケーションでは、コンポーネントインタラクションテストが広範なユニットテストよりも価値を提供します
- テストを開発の一部にする: テストが開発者のワークフローに無理なく統合されている場合（Storybook のストーリーのように）、導入は自ずと進みます。
戦略の真の評価は、将来的に予定されているコンポーネントライブラリ移行の際に判明すると考えています。 VRTテストは移行の円滑化に寄与するのか。コンポーネントテストは動作のリグレッションを的確に検出できるのか。私たちは前向きに捉えていますが、結果は時間とともに明らかになります。
シリーズのまとめ
このテスト記事は、アーキテクチャ変革の概要に関する3部構成シリーズを完結させます。管理の観点、アーキテクチャの決定、そして今やすべてを持続可能にするテスト戦略をカバーしました。
ここから、チームメイトがアーキテクチャとテストの特定の側面について深く掘り下げ、今後の記事で専門知識を共有します。彼らの実践的な経験は、同様の戦略を実装するために必要な実用的な洞察を提供します。
この旅に参加していただきありがとうございます。今後の記事でお会いしましょう、そしてハッピーテスティング！
謝辞
この変革は、チームの信じられないほどの献身なしには不可能でした。このアーキテクチャを実現することに貢献してくれたすべての人に特別な感謝を、特にNext.jsのベストプラクティスに関する貴重な指導をしてくれたakfmに。技術的な方向性をサポートしてくれたチームリードのyoshifumi.kondo、データアクセスパターンとカスタムリンティング実装に大きく貢献してくれたマネージャーのyuki.tosaにも大きな感謝を。最後に、変化を受け入れ、日々の使用を通じてこれらのパターンを洗練するのを助けてくれたすべてのエンジニアに感謝します。
コミューンでは、私たちと一緒に働く仲間を募集しています！少しでもコミューンの開発組織や職場環境に興味をお持ちの方、ぜひカジュアル面談でお話ししましょう。
