효과적인 프론트엔드 테스트에 대하여

かなり長い間インタビューしてきました。この苦痛なプロセスで目立ったのは、テストに関する質問が少しでも持ち出された場合、面接は失敗する運命にあるということです。これは、私の経験は主にフロントエンド開発であり、私が滞在した 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 Atom을 가질 수 있지만 테스트를 위해 중앙 집중식 설정 기능을 노출할 수 있도록 래퍼를 코딩할 수 있습니다.

API 호출/타사 라이브러리에서도 비슷한 작업을 수행해야 합니다. "이 작업을 수행할 때 애플리케이션에서 수행된 코어/비코어 API 호출"을 자신있게 테스트할 수 있도록 전역 및 싱글톤이어야 합니다. 이것은 나의 제한된 경험인 백엔드 애플리케이션에서 일상적으로 수행됩니다. 이는 프런트엔드 애플리케이션에서도 수행되어야 합니다.

이게 어떻게 들리나요? 이미 누군가가 이 작업을 수행하고 있다고 확신합니다. 귀하의 경험은 어떻습니까? 무엇이 개선될 수 있나요? 프런트엔드 테스트가 E2E/헤드리스 브라우저를 뛰어넘어 두뇌 없는 간단한 단위 테스트를 수행하는 사람들의 의견을 듣고 싶습니다.

위 내용은 효과적인 프론트엔드 테스트에 대하여의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!