この投稿のトピックは、それ自体のテスト、およびクライアントアプリケーション（Angular.jsなどを使用するアプリケーションなど）のコンポーネントのUIテストに専念します。
現在、クライアントアプリケーションで最も一般的なテストの種類は何ですか？
- ユニット -基本、私も言うだろう-必須。 テストレベル。 コンポーネント、サービスなどのすべての基本機能が適切に動作し、タスクを実行することを検証するように設計されています。
- UI-アプリケーションインターフェイス自体、すべてのホイッスルおよび「バグではなく機能」をテストします。 それは、クリック、リンクのクリック、および同様のプランの他のアクション-ユーザーのアクションをシミュレートするという事実から成ります。 その意味は、コンポーネント間の相互作用をテストすることです。
- 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お時間をいただきありがとうございます！