UIテスト-それらは常に必要ですか？

この投稿のトピックは、それ自体のテスト、およびクライアントアプリケーション（Angular.jsなどを使用するアプリケーションなど）のコンポーネントのUIテストに専念します。

現在、クライアントアプリケーションで最も一般的なテストの種類は何ですか？

1. ユニット -基本、私も言うだろう-必須。 テストレベル。 コンポーネント、サービスなどのすべての基本機能が適切に動作し、タスクを実行することを検証するように設計されています。
2. UI-アプリケーションインターフェイス自体、すべてのホイッスルおよび「バグではなく機能」をテストします。 それは、クリック、リンクのクリック、および同様のプランの他のアクション-ユーザーのアクションをシミュレートするという事実から成ります。 その意味は、コンポーネント間の相互作用をテストすることです。
3. E2E -UIテストに似た機能を実行しますが、1つのBUTで、すべてのテストは実際のサービス、API、BEで駆動されます。

プログラマーにユニットテストまで書くように強制することはすでにSisypheanの仕事なので、プログラミングの世界のSpartansだけがUIとE2Eにアクセスできます。 さらに、小さなスタートアップと大企業の両方で、テストの欠如を見ました。

私自身は3種類のアプリケーションテストをすべてカバーしていましたが、かつて「ユニットテストと小さなテスト-E2Eだけでカバーすることは可能ですか？」と考えていました。 それを理解してみましょう。

UIテストの主な利点：

• ほとんどのユーザーアクションをカバーし、ユーザー側でアプリケーションに触れることができます。
• コンポーネントとサービスの相互作用を確認します。
• アプリケーションの信頼性が向上します。

UIテストの主な欠点：

• 巨大な、時には-信じられないほど巨大な、すべてのコンポーネントとサービスのモックに費やされた時間（ただし、単体テストのように）。
• ゲームはろうそくに値しないので、小規模なアプリケーションにはほとんど役に立ちません。
• 使用されるサービスの複雑さにより、テスト自体はUnitよりも長く実行されます。
• パイプラインでの自動化と統合のより複雑なプロセス（Jenkins、Travisなど）

最初の 、そして最も重要な質問は-アプリケーションのサイズを決定することです。 小規模または短期の場合-Unit + E2Eで十分なので、UIテストを船外に安全に置いておくことができます。

第二に 、より重要なことは、できるだけ細心の注意を払って確認するだけの巨大なモンスターがある場合はどうすればいいのでしょうか？ そして答えは-より多くの単体テストです！

実際、現実の世界では、すべてのアクションの背後で、アプリケーションまたはコンポーネントの状態に変化があります（機能的またはオブジェクト指向プログラミングなど）。 ユーザーアクションは何かで終わる必要があり、結果がなければなりません。 単体テストでは、アクションの結果をいつでも確認でき、E2Eではコンポーネントの相互作用を確認できます。

例：

• ユースケース：ユーザーはOAuthを介してログインし、Helloページに移動する必要があります。
• アプリ：

  LoginComponent: login: () => { let isLogged = oauth.login(); if (isLogged) { router.changeState('hello-board'); } else { showError(error); } } 

• テストケース：
  
  • 単体テスト ：login（）関数が呼び出されたかどうかを確認します。 「login（）」が呼び出され、ルーターが内部状態を「hello-board」に変更した場合、すべてが正常です。
  • E2Eテスト：同じ「ログイン」ボタンが押され、リクエストが実際にoauthに送信され、ユーザーが正しい「Hello」ページに移動したかどうかを、リクエスト後にユーザーのブラウザー行を確認して確認します。

PS Openはコメントをお待ちしており、大歓迎です！

PSSお時間をいただきありがとうございます！