フィーチャーテストワーキンググループ

フィーチャーテストにおける Capybara の代替として、永続的な代替手段の信頼性を確立します。

属性

プロパティ
作成日2024-11-01
目標終了日2025-02-01
Slack#wg_feature-testing
Google Dochttps://docs.google.com/document/d/1ZS4L-vVVVqRAjdOmr4X8ENYD5YEyFxEV8wxuR1OtNvE/edit?tab=t.0
Epic
概要と状況終了基準を参照

コンテキスト

現在のフィーチャーテストのアプローチである RSpec と Capybara を使用する方法には、いくつかの問題点があります:

  • カバレッジの不足または隔離されたスペックの多さにより、フィーチャースイート全体としてコード変更に対する信頼性が低く、リグレッションを検出できていません。
  • 安定性の低さが、master ブランチが壊れる頻度の高さにつながっています。
  • デバッグツールが限られているため、安定したテストの作成やフレーキーなテストのデバッグが困難です。
  • Ruby で書かれたテストのメンテナンスは、この言語のスキルを持つかどうかに関わらず、フロントエンドエンジニアが担当することが多いです。

目標

このワーキンググループは以下の目標を持ちます:

  1. Capybara の代替として、JavaScript ベースのテストシステムである Playwright の信頼性を確立します。
  2. GitLab プラットフォームの一部を使用して Playwright の概念実証(PoC)を作成します。
  3. Playwright への移行戦略を含むアーキテクチャーブループリントを作成します。

終了基準

基準開始日完了日進捗DRI
CI/CD および環境のセットアップ2024-12-11Javiera Tapia
3 つの変換されたスペック例2024-12-11Natalia Tepluhina
移行計画

詳細

CI/CD および環境のセットアップ

GitLab のビルドプロセス内で Playwright サーバーを起動する方法を決定する必要があります。

3 つの変換されたスペック例

現在フレーキーなテストと同条件で比較するための完全な例:

以下のメトリクスを測定・比較する予定です:

  • 失敗した実行の割合
  • スペックの実行時間
  • デバッグのステップ数

移行計画

Playwright に段階的に移行するための戦略。

2025年1月22日のアップデート

現在の進捗と課題

Capybara を Playwright に置き換えるための概念実証に多大な努力を投じた結果、ワーキンググループはさらなる進捗を妨げる重大な課題に直面しました:

  • 認証の問題:既存の認証メカニズムと Playwright を統合することが複雑であることが判明しました。一見解決されたように見えますが、将来の問題をトラブルシュートすることが困難な形になっています。
  • 複雑性の増大:Playwright の PoC のトラブルシューティングを通じて、新しいテストフレームワークへの移行により、メンテナンスとデバッグが当初の予想より困難な複雑さの層が追加されることが明らかになりました。
  • リソースの制約:これらの障害を乗り越えるために必要な時間とリソースが多大であり、他の重要なテスト改善から注意が逸れています。

これらの障害を踏まえ、ワーキンググループは Capybara を Playwright に置き換える現在の実験を中断することを推奨します。

推奨事項

Playwright の実験の終了に伴い、ワーキンググループは解散しました。既存の Capybara/RSpec フレームワーク内でテストカバレッジを増やしてフレーキーさを減らすために、以下の推奨事項を提案します:

  1. テストカバレッジの向上:
  • ギャップの特定:テストカバレッジが不十分な領域を特定するための徹底的な分析を実施し、その領域へのテスト追加を優先します。
  • エンドツーエンド(E2E)テスト:重要なユーザーフローに対して E2E テストを段階的に導入し、フロントエンド/フルスタックエンジニアによるこれらの E2E テストの作成を奨励します。
  1. トレーニングと文書化:
  • スキル開発:テストの作成とメンテナンスを改善するために、Capybara と RSpec のベストプラクティスに関するエンジニア向けトレーニングセッションを提供します。
  1. 定期的なメンテナンスとレビュー:
  • フレーキーなテストの特定:テストスイートの信頼性を維持するために、フレーキーなテストを迅速に特定して対処するルーティンを確立します。
  • 継続的な改善:テスト実行からのフィードバックを定期的にテスト戦略の改善に活用する継続的改善の文化を育てます。

これらの推奨事項を実装することで、フィーチャーテストフレームワークを強化し、カバレッジを増やして、フレーキーさを大幅に削減し、全体的なコード品質と安定性を高めることを目指します。

役割と責任

ワーキンググループの役割人物役職
エグゼクティブスポンサーTim ZallmannVP of Engineering, Core Development
ファシリテーターDonald CookEngineering Manager, Plan:Project Management
機能リードNatalia TepluhinaPrincipal Engineer, Plan
機能リードKsenia KolpakovaEngineering Manager, Test Engineering
機能リードJaviera TapiaBackend Engineer, Create:Source Code
メンバーDésirée ChevalierSenior Software Engineer in Test, Plan
メンバーDoug StullStaff FullStack Engineer in Growth