効果的なフロントエンド テストへ

かなり長い間インタビューしてきました。この苦痛なプロセスで目立ったのは、テストに関する質問が少しでも持ち出された場合、面接は失敗する運命にあるということです。これは、私の経験は主にフロントエンド開発であり、私が滞在した 2 つの会社はフロントエンドのテストが非常に貧弱だったためです。

--- 直接ディスカッションに進みたい場合はスキップしてください ---

私の不足は、ある意味、業界文化の副産物でした。フロントエンド テストは常に行われてきましたが、10 年前の企業構造では、テストに関する懸念が開発プロセスから分離されていました。そのため、私たちは開発者のために E2E/自動テストを作成する専任の QA チームを設けました。そのため、テストは職務内容にも含まれていませんでした。また、小規模なスタートアップの残念な真実は、常にデリバリーが何よりも優先されるということです。そのため、テストは生産性を妨げるため、私たち開発者はテストをしませんでした。リポジトリにはテスト ライブラリ (Jasmine/Mocha/PhantomJS...) もインストールされていませんでした。

私は、はるかに大きな会社 (コンシューマー プラットフォーム チームには 150 人ほどの開発者がいた?) で 2 番目の仕事に就きました。しかし、本質的に言えばテストはありませんでした。各チーム (チェックアウト、ロイヤルティ、登録などの機能ごとに分けられたチーム) には、E2E テストを作成する専任の QA メンバーが配置されました。その文化が定着し、QA が予算から削減されると、それを学ぶ人がいなかったため、誰も QA を取り上げなくなりました。私たちのチームのために E2E テストをいくつか取り上げようとしましたが、残されたコードは機能すらしておらず、明らかなバグでいっぱいでした (すごいことがたくさんありました)。厳しい締め切りも重なって、テストは遅れてしまいました。人々がテストについて話したのは、ユーティリティ関数とカスタムの反応フックについてだけでした。

--- ディスカッション開始 ---

テストを行わない文化に悩まされているので、少なくとも面接中に抽象的にテストについて言えることを考え出さなければなりません。スタイルや実装をテストしないというよくあるくだらない話は省略します。

お気軽にディスカッションに追加してください。これは私の過去の同僚のうち少なくとも 300 人に影響を及ぼします。

1.) グローバル状態をテストします:
私の経験上、最も厄介な機能の 1 つは、「これが起こったら、自動的にこれを実行します」タイプの動作です。たとえば、私が持っていたアプリの 1 つは、高度に構成可能なグラフ視覚化ダッシュボードでした。 1 つの構成変更により、返されるデータの有無に応じて、他の構成も変更される可能性があります。構成の副作用の中には、単純なものではないものもあります。したがって、自動構成変更と、その状態が全体にわたって永続的であるか、変更されないか、一貫しているかどうかをテストする必要があります。したがって、この種の動作をテストする場合、PM、マネージャー、設計、QA チームと連携することが非常に重要です。

2.) UI 入力の整合性のテストに多くの時間を費やさないでください:
入力のテストについて説明しているチュートリアルがかなり多くあります。たとえば、検索バーに「taylor swift」と入力して Enter キーを押すと、検索機能が入力として taylor swift を取得します。

これはまったく役に立ちません。データ バインディングが壊れている場合は、開発中に自分で見つけるべきだったことが明らかであるか、検索バーの上にある非表示の div によりユーザーが検索に入力できないなど、機能を妨げるものがあったために自動的にテストできないかのどちらかになります。

ただし、コード行によって支払いを受けている場合は、先に進んでください:)

3.) 入力の副作用として入力をテストすることが望ましいですが:
2 番とは対照的に、ユーザー操作に対する完全な副作用である関数呼び出しをテストする必要があります。たとえば、ユーザーがボタンをクリックすると、データ分析のためにこのユーザー アクションを登録するリクエストを呼び出す必要があります。コア機能とは完全に切り離されたこの種の副作用は、意図しない変更によって不意を突かれないように、自動的にテストされる必要があります。コア以外の副作用は他のチームにとって不可欠なものになる可能性があります。私もそのような他のチームの 1 つに所属していました :D

では、これらのテスト要件をどのように設計するのでしょうか?
フロントエンド アーキテクチャである MVC を詳しく見てみましょう (MVVM であるかどうかは関係ありません)。

V - view (html/jsx): これは E2E/ヘッダーレス ブラウザのテストに最適で、業界標準です。

C - コントローラー (ビジネス ロジック): 関数が正しいことを確認するために時間をかけてください。たとえば、純粋な関数がある/抽象化されている場合、期待される入出力プロセスはそのまま残っていますか?ある程度の業界標準ですが、通常、ステートフル関数を純粋な関数にしてテストすることを気にする人はいません。

M - モデル (API 呼び出し/状態): これが最も注目したいことです。 (レンダリング以外の) 状態はグローバルであり、概念ごとにシングルトンである必要があります。基本的には Redux なので、新しいアイデアではありません。ただし、テスト目的では Flux である必要はありません。 jotai アトムを使用できますが、ラッパーをコーディングして、集中セッター関数をテスト用に公開できます。

API 呼び出しやサードパーティ ライブラリでも同様のことを行う必要があります。 「これを実行すると、アプリケーションでコア/非コア API 呼び出しが行われるか」を自信を持ってテストできるように、グローバルかつシングルトンである必要があります。私の限られた経験ではありますが、これはバックエンド アプリケーションで日常的に行われます。フロントエンド アプリケーションでも行う必要があります。

これはどう聞こえますか?すでに誰かがこれを行っていると思いますが、あなたの経験はどうですか？何が改善できるでしょうか？フロントエンド テストが E2E/ヘッドレス ブラウザや頭の悪い単純な単体テストを超えたものであるという意見をぜひ聞きたいです。

以上が効果的なフロントエンド テストへの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。